Migration d’un hébergement classique à une infra cloud PaaS, retour d'expérience

Beaucoup d’hébergements sont encore à base de serveur dédié car c'est ce que tout le monde fait et que c'est souvent le meilleur rapport puissance / prix. Et on peut aussi faire ce que l'on veut dessus.

Mais cette liberté a un coût : c'est à nous de gérer beaucoup de choses : sécurité, migration de version, log, monitoring. Comme c'est un métier à part entière, on le fait souvent mal ou on le délègue, perdant ainsi pas mal de souplesse et de réactivité.

Cette conférence est un retour d'expérience d'une migration vers un hébergement Platform as a Service (PaaS) avec plein de conseils sur la performance et sur le process d'arriver à un hébergement de qualité clair et reproductible.

Vous ne verrez plus votre hébergement du même œil !

Transcript

1. Retour d’expérience Migration d’un hébergement classique à une infra cloud PaaS Bastien Jaillot, architecte @JoliCode – @bastnic
3. « Les nuits blanches passées sur le site planté nous empêchaient d'envisager toute croissance car le serveur ne tiendrait pas »
4. Bastien, cofondateur et architecte logiciel
5. (Du coup on m’appelle pour des situations qui puent 💩) Les situations complexes sont mon dada
6. On s’adresse à qui ? - À ceux qui subissent leurs hébergements - À ceux qui veulent scaler “facilement” leur application. - À ceux qui connaissent déjà ces galères et sont là pour écouter une bonne histoire. - Plus généralement à tous ceux qui déploient un site en production.
7. Bonjour, je voudrais un hébergement pour mon site PHP / MySQL Ça va me coûter combien ?
8. Ce que l’on vous demande Version de PHP ? MySQL ? Combien de CPU / RAM / Espace disque ?
9. Ce que l’on DEVRAIT vous demander - Je dois mettre à jour X pour des raisons de sécurité, quand puis-je le faire pour éviter un downtime ? - Quelle stratégie de backup / restore ? - Comment ça se passe si besoin de plus de puissance ? - On sait que l’on va devoir mettre à jour les versions logicielles, comment on planifie ça ? - Comment déployer ? - Comment rollback ? - Comment ajouter un worker ? - Comment configurer un cron ? - Comment ajouter une dépendance ?
10. Ce que l’on DEVRAIT vous demander - Je dois mettre à jour XX pour des raisons de sécurité, quand puis-je le faire pour éviter un downtime - Quelle stratégie de backup / restore ? - Comment ça se passe si besoin de plus de puissance ? - On sait que l’on va devoir mettre à jour les versions logicielles, comment on planifie ça ? - Comment déployer ? - Comment rollback ? - Comment ajouter un worker ? - Comment configurer un cron ? - Comment ajouter une dépendance ? - Comment améliorer le process de build ? - Comment gérer les environnements ? - Où sont les logs ? - Tu veux un APM ? - Tu as pensé à faire un tir de charge pour que l’on finetune les process et la mémoire ? - Comment on rotate les logs ? - Combien de releases on garde - Quelles sondes poser ? - Qui gère quoi quand ça plante ? HNO ? - …
11. Observabilité ? Je dois auditer mais ??? - SSH bloqué => il faut que l’ancien administrateur système m’ajoute - Aucune documentation - Script custom pour déployer - Instances Docker mais routing custom - Ni LOG ni APM, les développeurs sont aveugles de fait - RIEN DE STANDARD ouaip, non, on ne va PAS toucher à ça
12. Serveur qui n’en peut plus
13. API www Clients apps BDD cache local des réponses API Tout sur un serveur Users Contributors backoffice cache local des réponses API
14. Architecture du code ? - API / BO : code bien legacy et très très très très très très très lent - FRONT : Symfony nickel mais un énorme cache fichier de l’API (??) - Applications mobiles et tierces ne bénéficient pas du cache calculé par le front - la performance n’a jamais été prise en compte à la base, ce sont des rustines pour que le front ne tombe pas => c’est propre, on va pouvoir bosser !
15. Le cache HTTP vous connaissez ?
16. Cache HTTP (avec Varnish) - Ça s’interpose entre le client et le site PHP - Ça répond en <1ms, et consomme 0,0000001% CPU - Ça se configure via des en-têtes HTTP - Ça se scripte via du VCL - C’est bon, mangez-en ! J’ai déjà bloggé sur le sujet : https://jolicode.com/blog/scaling-the-symfony-demo-app-to-the-extreme-with-varnish
17. API www Clients apps BDD Tout sur un serveur Users Contributors backoffice Proxy cache
18. On va proxifier l’API de l’extérieur Il nous faut donc un nouvel hébergement : - aucune idée des futures performances de la plateforme - le trafic n’étant pas lisse, on veut du scaling - j’ai 0 temps et le client n’a pas un énorme budget - le site est planté très régulièrement, on va pouvoir prendre nos gros sabots - plein de solutions (cluster kubernetes, plusieurs serveurs dédiés, lambdas, …) (si vous partez sur Kubernetes pour cette taille de site, on se rappelle quand vous aurez échoué)
19. PaaS ? Platform as a Service
20. PaaS chez Clever Cloud ? - on décrit ce que l’on veut (une application PHP 8.1 liée à un MySQL 8.0) - c’est tout - ah si, on paie à la ressource consommée. - tout se configure via des variables d’environnement documentées - beaucoup plus cher à CPU égal par rapport à un dédié et plus de latence - mais ça va nous permettre d’optimiser donc ce sera PEUT-ÊTRE dans le même range de prix => pour le moment on n’en sait rien - Clever Cloud = ils sont Français et sympas, pourquoi pas ?
21. API www Clients apps BDD Tout sur un serveur Users Contributors backoffice Proxy cache Infrastructure Clever Cloud
22. On récupère tout - Clever Cloud : création de l'organisation par le client, ajout des comptes admin - New Relic : création par le client d’un compte gratuit - DNS : accès à la config ("oui oui il faut bien saisir le point à la fin") => TTL à 300s - GitHub : accès à tous les repositories de code - Backups : accès aux sauvegardes de bases de données et des fichiers statiques
23. 1. Proxy
24. # Proxy tentative 1, Varnish appelle le legacy mkdir -p proxy-varnish/clevercloud && cd proxy-varnish touch clevercloud/varnish.vcl # avec du code VCL pas sympa git init && git add . && git commit -m 'Proxy: add varnish config' clever create -t php "proxy-varnish" -o "Conf AFUP" clever deploy clever open # ouvre l’url en cleverapps.io dans votre navigateur
25. 2022-01-18T22:04:05+01:00 VCL compilation failed 2022-01-18T22:04:05+01:00 #######------------ 2022-01-18T22:04:05+01:00 Only one IPv4 and one IPv6 are allowed. 2022-01-18T22:04:05+01:00 **Backend host "api.XXX.com": resolves to too many addresses**.
26. # on n’oublie pas de nettoyer # derrière nous #boyscoutRule clever delete
27. # Proxy tentative 2, Varnish appelle une app PHP mkdir -p proxy-php/clevercloud && cd proxy-php touch clevercloud/varnish.vcl # avec du code VCL pas sympa symfony create <...> git init && git add . && git commit -m 'Proxy: add code' clever create -t php "proxy-php" -o "Conf AFUP" clever deploy clever open # ouvre l’url en cleverapps.io dans votre navigateur
28. clever env set CC_PHP_VERSION 8.1 clever env set APP_ENV prod
29. # nginx != apache, .htaccess… 🤦 composer require symfony/apache-pack git add . git commit -m "Fix apache config" clever deploy
30. C’est en prod ! En DEUX minutes nous avons une application PHP en production et accessible. Sans AUCUNE compétence en administration système !
31. #[Route('/{anything}', name: 'proxy', requirements: ['anything' => '.+'])] public function index(Request $request, HttpClientInterface $httpClient): Response { $originResponse = $httpClient->request($request->getMethod(), $request->getRequestUri()); return new Response( $originResponse->getContent(false), $originResponse->getStatusCode(false), [ 'content-type' => $originResponse->getHeaders(false)['content-type'], ] ); }
32. # ça proxifie, maintenant, ajoutons du monitoring clever env set NEWRELIC_APPNAME "prod - api proxy php" clever env set NEWRELIC_LICENSE xxxxx
33. HEIN ?
34. # imaginez la discussion avec l'infogérant pour # lui dire de downgrade PHP. Mieux comme ça non ? clever env set CC_PHP_VERSION 8.0 clever restart
35. // on n'oublie pas les tests, pas grand chose, mais on itérera au besoin public function testProxyGet() { $client = static::createClient(); $crawler = $client->request('GET', '/secretUrl'); $response = $client->getResponse(); $data = json_decode($response->getContent()); $headers = $response->headers; $this->assertIsArray($data); $this->assertTrue($response->isCacheable()); }
36. TEST EN ÉCHEC
37. public function index(Request $request, HttpClientInterface $httpClient): Response { // ... $response->setPublic(); $response->setSharedMaxAge(3600); return $response; }
38. Et le build ??? Clever Cloud lance tout seul un composer install s’il détecte un composer.json
39. // le code n'étant pas structuré (une action répond à 100% des appels), New Relic // regroupe toutes les transactions sous /index.php, on corrige ça $action = parse_url($request->getRequestUri(), PHP_URL_PATH); if (extension_loaded('newrelic')) { newrelic_name_transaction($action . ' - ' . $request->query->get('client')); }
42. On modifie les apps clientes pour utiliser le proxy…
43. # Hit rate trop faible vu avec varnishstat -1 | grep MAIN.n_lru_nuked # on augmente sa taille allouée (1go par défaut) # cette variable d'environnement a été créée exprès pour moi, merci Clever <3 clever env set CC_VARNISH_STORAGE_SIZE "13G" # fuite mémoire car métadonnées sur un trop grand nombre d'objets # on passe d'une instance nano (512M) à S (2go) clever scale --flavor S
44. 2. Front
45. API www Clients apps BDD Tout sur un serveur Users Contributors backoffice Proxy cache Infrastructure Clever Cloud
46. # Mise en ligne du site front git clone git@github.com:pouet.git clever create -t php "front" -o "Conf AFUP" clever env set CC_PHP_VERSION 8.0 clever env set APP_ENV prod clever env set NEWRELIC_APPNAME "prod - front php" clever env set NEWRELIC_LICENSE xxxxx clever env set API_URL https://... clever domain add www.j-ai-signé-un-nda.com clever deploy
47. # nginx != apache, .htaccess… 🤦 composer require symfony/apache-pack git add . git commit -m "Fix apache config" clever deploy
48. # application/config/packages/monolog.yaml when@prod: monolog: handler: # ... nested: - type: stream - path: php://stderr + type: error_log
49. DEUX minutes pour générer le menu ?
50. # ESI (Edge Side Include), merci Varnish {# base.html.twig #} {{ render_esi( controller( 'App\\Controller\\MenuController::index', {'_locale': app.request.get('_locale')} ) ) }}
51. /** * @Cache(smaxage="3600", public=true) */ class MenuController extends AbstractController { public function index() { // les gros calculs étaient dans du routing return $this->render('_menu.html.twig'); } }
52. Prêt pour une mise en prod via migration DNS ?
54. Rollback après 30s Pas merci les médias en absolute qui ont masqué le souci.
55. /** * @Route("/media/{anything}", name="media_proxy", methods={"GET"}, requirements={"anything":".+"}) */ public function proxy(Request $request, HttpClientInterface $httpClient): Response { $originalResponse = $httpClient->request($request->getMethod(), $request->getRequestUri()); $response = new Response( $originalResponse->getContent(), $originalResponse->getStatusCode(), ['content-type' => $originalResponse->getHeaders()['content-type']] ); $response->setPublic(); $response->setSharedMaxAge(3600); return $response; }
56. Re MEP… OK ! 🎉 (on s’occupera de synchroniser les fichiers hein ⌛⌛⌛)
57. 3. API & BO
58. API www Clients apps BDD Un serveur Users Contributors backoffice Proxy cache Infrastructure Clever Cloud BDD jetable API test
59. # nginx != apache, .htaccess… 🤦 composer require symfony/apache-pack (et non, legacy…) touch .htaccess git add . git commit -m "Fix apache config" clever deploy
60. Performance SQL ? - Malgré des ajouts d’index… Performances horribles comparées au legacy - Dans notre bonheur, j’étais passé direct de MySQL 5.7 à MySQL 8, mais PERTE DES QUERY CACHE. - Legacy qui fait 500x la même requête SQL dans une boucle => on va éviter de fixer le code, on fixe MySQL - => on jette l’instance v8 et on lance v5.7
61. www Clients apps One server Users Contributors backoffice Proxy cache Infrastructure Clever Cloud BDD API KTHXBYE Uploaded data
62. Bug marrant 1/2 Constat : des énormes pics bases de données sans cause visible dans l’APM API. Que faut-il faire ? augmenter la puissance BDD ? Sont nuls ces serveurs, on va repasser sur un dédié
63. Bug marrant 2/2 On regardait la mauvaise application… Un contributeur ouvrait 40 onglets d’un coup 404 favicon.ico => chargement par défaut de la page d'accueil du BO Page d’accueil avec plein de métriques, plein de calculs : écroulement de la BDD Solution : ajouter un favicon 🙄
64. 1 2 3 4 5 6
65. 4. Mais encore
66. PaaS : gestion des fichiers contribués Pas de stockage local sur du cloud, car les machines meurent 💀. Deux solutions : stockage objet “S3” (cellar) ou point de montage distant “NFS” (fsbucket)
67. PaaS : gestion des mails - SMTP local ne fonctionne évidemment pas - On peut utiliser un SMTP distant en configurant des variables d'environnement (mais ça ne fonctionne pas) - On utilise symfony/mailer
68. PaaS : gestion des crontab C’est documenté https://www.clever-cloud.com/doc/administrate/cron/
69. PaaS : gestion des workers C’est documenté https://www.clever-cloud.com/doc/develop/workers/
70. PaaS : gestion des logs C’est documenté https://www.clever-cloud.com/doc/administrate/log-management/
71. PaaS : et si on veut quand même scripter ? C’est documenté https://www.clever-cloud.com/doc/develop/build-hooks/ - hooks sur le déploiement : Avant / après build, avant lancement, lancement ok, lancement planté - déclaration par… variable d’environnement
72. www Clients apps Users Contributors backoffice Proxy cache Infrastructure Clever Cloud BDD API 7.4 API 8.1 Uploaded data
73. DivisionByZeroErro r
74. Différence sur le déploiement ? Avant ? - SSH sur la machine - Lancement commande inconnue - Pull du code - Composer install - Npm build - Pendant ce temps là le site est down Après ? $ clever deploy Une nouvelle instance se lance quand le build est prêt. 0 downtime, 0 code custom
75. Mais est-ce que ça scale vraiment ? Horizontalement ET/OU Verticalement
76. Clients apps Users Contributors backoffice Proxy cache Infrastructure Clever Cloud BDD API API API API API API www www www www
77. Tout n’est pas magique : pas libre de tout faire… - RabbitMQ, Cassandra ? => demander au support - Extension Apache ou PHP exotique ? => demander au support - Réplication SQL ? => demander au support - DataDog à la place New Relic ? ben non ! Mais tu peux tester Elastic APM - https://redirection.io/ ? ben non (enfin si, en hackant beaucoup, article à venir) - Un mauvais signal : zone New Yorkaise qui ferme 10j après que je l’utilise
78. Tout n’est pas magique :( - Pas de support d’HTTP/2 => faut demander un accès béta un comble quand on sait que le CEO en parlait en conférence en 2014 - Pas de réseau privé par organisation (ça arrive) - Pas de healthcheck applicatif (je fais du lobying) - Vim a le mouse support activé. Mais qui fait ça ?
79. Cependant <3… rétrospective - Soucis de version de PHP : changer une variable d’environnement - Soucis de MySQL trop lent : lancer les deux versions et comparer - Vous avez souvent eu ce degré de liberté / réactivité avec vos scripts ansible / bash / infogérant ? - Grande agilité => on peut TESTER des choses sans un gros investissement
80. - Le client a la main sur tout : il peut vous donner les mêmes accès que moi - Depuis la console PaaS : identifier 4 applications PHP, une base MySQL et 2 dossiers partagés (fsbucket). - Dans chaque app : identifier les contrats (les variables d'environnements) - Déployer: clever deploy - Ça ralentit ou ça plante ? regarder New Relic ou clever logs C’est bon vous pouvez me virer
81. C’en est tellement simple que ça en serait presque ennuyeux (et c’est tant mieux) #boringTech
82. > Quelques bons chiffres pour vous illustrer les avancées toujours positives de notre projet. > +70% par rapport à la même période l'année précédente > et le tout SANS NUITS BLANCHES liées aux serveurs !
83. Agilité dans l’infogérance Observabilité
84. Conclusion - Architecture moins chère, scalable et évolutive. - Déploiement standardisé et sans code custom. - Applications bien cloisonnées sans container ni VM à gérer. - Pas nécessaire d’avoir de connaissances en administration système. - C’est souvent plus simple et moins coûteux de se faire accompagner par un expert. - J’ai mis plus de temps à préparer cette présentation qu’à effectuer cette migration
85. Commentaires ? Feedbacks ? https://openfeedback.io/forumphp2022/ https://joind.in/event/forum-php-2022
86. Merci. ForumPHP 2022 – Bastien Jaillot – @bastnic