DevOps : comment TheFork a assaini son process de déploiement

TheFork, au "point de rupture" après sa migration AWS ?

Laurent Chenay, ingénieur principal confirmé, emploie ces mots. Mais au sujet d'un élément précis : le process de déploiement. Il est revenu, à l'occasion de la conférence DevOps Rex, sur le frein que ce process en était venu à constituer... et sur sa modernisation, avec comme emblème un outil nommé Hyperloop.

Des soucis de calibrage en préprod

TheFork manipule aujourd'hui environ 160 projets. Sa stack de microservices en Node.js / Postgre est hébergée sur une centaine de noeuds Kubernetes en production (1600 CPU en pic de charge). Le tout pour gérer environ 22 000 requêtes par seconde.

Confrontée à des enjeux de scalabilité (pics de charge aux heures des repas, campagnes marketing synchronisées à travers l'Europe...), l'entreprise avait migré vers AWS. Une démarche achevée en 2021. Elle était allée, dans ce cadre, chercher du Kubernetes et du Terraform, entre autres. Tout en quittant le monde du bare metal pour "laisser un peu plus de liberté" à ses devs.

Laurent Chenay - photo : LinkedIn

"AWS était génial mais en préproduction, c'était assez instable, explique Laurent Chenay. On avait créé une infrastructure faite pour s'agrandir et rétrécir en fonction d'une charge. Or, en préproduction, il n'y a pas de trafic. On a donc eu beaucoup de mal à la stabiliser."

Un process générateur de tensions

"On avait une grosse pression pour livrer de nouvelles fonctionnalités", poursuit l'intéressé. D'autant plus que pour accompagner la migration AWS, l'ensemble des départements de la société avaient accepté de ralentir le cycle fonctionnel, 9 mois durant.

Dans ce contexte, "pendant des semaines voire des mois, on n'avait que des tests rouges." Il était alors demandé à chacun d'analyser les résultats à la main, en préprod comme en prod. Le tout dans le temps imparti, à savoir un créneau d'une heure réservé au préalable - là aussi à la main - dans un agenda Google partagé, en tenant compte des plages interdites (hors jours et heures ouvrés, au moment des repas et les veilles de jours fériés). S'y ajoutait la nature assez instable des tests fonctionnels (simulation du comportement utilisateur à travers une couche navigateur).

TheFork avait atteint ce que Laurent Chenay qualifie de "point de rupture". Y compris au sein des équipes. "Avec les divergences entre tests et produits, arrive un moment où on ne peut plus suivre et savoir qui attend quoi. [...] On n'arrive même plus à collaborer pour sortir de cette situation."

Lorsque des tests échouent, on peut se reposer sur des mécanismes de retry ou de timeout... qui font ralentir la procédure. Très vite, le créneau d'une heure ne suffit plus. On commence alors à le dépasser, en demandant ou pas. Avec les perturbations que cela entraîne. Puis on finit par décider de l'élargir à 2 heures, divisant donc par deux le nombre de créneaux disponibles. "On était déjà à trois jours d'attente pour passer en prod ; on est passé à plus d'une semaine", explique Laurent Chenay. Pour compenser, certains se sont dit qu'ils allaient livrer le sprint en entier ; fournir le travail de 5 ou 6 personnes, voire des autres équipes. D'autres, considérant le process comme défaillant, se sont mis à le contourner : déploiement sans tests, sans communication, sans préprod, voire les trois. Un comportement qui a engendré encore plus de tension vis-à-vis des collaborateurs qui respectaient le process.

Hyperloop pour "restaurer l'unicité"

À cette situation a répondu le projet Hyperloop. Objectif : un outil pour coordonner toutes les équipes, sur deux axes. D'une part, automatiser (garantie des processus et optimisation du temps collectif). De l'autre, restaurer l'unicité ("L'isolation des changements est le meilleur moyen d'avoir un lien de causalité.")

Pendant un mois, un prototype a couvert les six actions principales : déployer, lancer les tests et analyser, en préprod et en prod. "On a pris ce qu'on avait sous la main : du Jenkins qui était déjà central sur notre infrastructure, un peu de Groovy [langage JVM, NDLR] et, en frontal, une petite interface utilisateur sur Slack pour déclencher le processus."

Cet outil fut mis en production pour deux mois, avec adoption volontaire. Environ 90 % des utilisateurs ont migré. Pour le reste, "c'était compréhensible", selon Laurent Chenay. "On a des exceptions assumées. Nos front-end sont assez particuliers. On a des gros moteurs de recherche en Java qui ne sont pas du tout iso par rapport à d'autres microservices. Ces 10 % ont été un peu plus compliqués à chercher. On a dû avoir une petite conduite du changement, voire des négociations en termes de backlog."

S'est ensuivie, pendant un an, une phase de stabilisation. "On s'est mis à mesurer, dans Prometheus, l'intégralité des temps de tout le processus. Mais on est aussi allé gratter côté infra [et] côté QA. [Ainsi], on a pu mettre le doigt sur de petits irritants et fournir le bon feedback objectif à ce trio."

En coulisse, Jenkins a laissé place à TypeScript, langage de coeur chez TheFork. La partie orchestration a migré vers Temporal, avec Argo CD pour la couche sous-jacente côté Kubernetes. Et une stack d'observabilité avec Datadog.

Rollback automatique et mise en prod progressive

A suivi une phase d'expansion, avec un travail d'ergonomie sur Slack, pour aller vers un suivi en temps réel de l'intégralité des étapes. "Cela a permis à toute la communauté de venir voir par elle-même où étaient les irritants. [Un] thread Slack est devenu la source de vérité pour tout le monde." Une situation d'autant plus opportune que l'équipe SRE avait alors perdu "une grosse connaissance collective sur comment observer [ses] projets en prod" depuis Datadog. En parallèle, l'analyse a été automatisée sur les golden metrics. Une forme de moteur de rollback "élémentaire", Datadog permettant ensuite d'aller plus loin.

"À la migration, on était sur Argo et ça faisait longtemps que l'équipe infra voulait mettre en place la suite, comme Argo Rollouts, glisse Laurent Chenay. Mais ils ne savaient pas comment prendre cette décision de faire un rollout automatique au niveau de Kubernetes. Maintenant, on a connecté ce moteur de décision pour livrer en production par petits paliers de 10 % toutes les minutes, pour minimiser le risque d'impact. On n'est pas toujours en capacité d'intercepter une régression avant sa mise en prod, mais on peut minimiser son impact en n'exposant pas toute la communauté."

D'une semaine à 30 minutes de déploiement

L'équipe sécurité avait un pool de 6000 CVE ouverts, avec 300 journées/homme pour les corriger. Elle a fait la passerelle avec Hyperloop. Désormais, tous les matins, sans intervention humaine, un déploiement vient corriger les failles. Pas encore en temps réel, le backlog n'étant pas encore absorbé (restent 2000 CVE). "Mais d'ici quelques mois, on sera en temps réel à J+1 à corriger toutes nos failles de sécurité en production s'il y a une dépendance à mettre à jour facilement."

Dans le même esprit, le J+1 est visé pour la mise à jour des composants internes (notamment des surcouches pour des outils open source). Le front-end travaille sur des outils pour l'analyse côté navigateur. Le SEO a aussi manifesté son intérêt. Hyperloop "devient un outil assez central qui peut absorber beaucoup de fonctionnel", résume Laurent Chenay.

La commande Slack utilisée pour lancer Hyperloop embarque une gestion de versions sémantique légère. Elle donne aussi accès à une fast line ("Pour l'instant, il n'y a pas trop d'abus ; on est encore un peu en contrôle dessus").

TheFork en est dorénavant à 30 minutes de temps de déploiement. "Pas un énorme gain, mais pas mal si on considère qu'on a déjà 10 minutes de progressive reload", fait remarquer Laurent Chenay. Les tests sont stabilisés à 93 %. Le rythme atteint 180 déploiements par semaine - l'objectif étant de 2,5 par semaine pour chaque dev. Il arrive maintenant que les nouveaux embauchés livrent dès le premier jour. Auparavant, il fallait plutôt un mois et "c'était souvent leur équipe qui [...] déployait à leur place, avec ce que ça comporte en termes de déresponsabilisation."

Temporal gère aujourd'hu une cinquantaine de tâches Hyperloop. Si l'outil n'est pas codé nativement en Argo CD, c'est entre autres pour pouvoir absorber davantage de données que ce qu'il est possible d'observer côté Kubernetes pur. Par exemple, à travers Botify pour le SEO. Il est aussi prévu d'intégrer du RUM (Real-Time User Monitoring).
Pour ce qui est du trafic non réaliste en préprod, TheFork envisage de préchauffer l'environnement juste avant de lancer les tests. Une piste pas encore mise en pratique, les niveaux de stabilité obtenus ces derniers mois s'étant avérés "assez [satisfaisants]".

Illustration principale générée par IA