GO et Kubernetes, les recettes du nouveau LeBonCoin
Comme tous les grands sites Web nés au début des années 2000, LeBonCoin a été développé d’un bloc, un monolithe de plusieurs millions de lignes de langage C bien difficile à faire évoluer. Une plateforme dont la modernisation a été lancée en 2017.
Avec neuf milliards de pages vues par mois et 800 000 annonces déposées chaque jour, LeBonCoin est un poids lourd de l’Internet français. Un site qui, développé en langage C est exploité sur une plateforme dédiée.
Ce champion de la petite annonce présente toujours d’excellentes performances mais son code méritait une sérieuse modernisation comme l’explique Jean-Louis Bergamo, Directeur de l’infrastructure du site LeBonCoin « De multiples éléments ont été à l’origine de ce grand projet de refonte. Comme bon nombre d’entreprise, nous avions fini par créer un énorme applicatif monolithique de plusieurs millions de lignes de code. Faire évoluer un élément de ce monolithe impliquait de multiples dépendances, ce qui ne facilitait pas le travail d’équipes distribuées. »
Cette problématique de plateforme monolithique devient d’autant plus importante, car le site mène une réorganisation de ses équipes sous forme de « Feature Teams ».
Sur un effectif total de 800 personnes, environ 150 personnes sont dédiées à l’IT et l’essentiel de ces effectifs est composé d’équipes de développement, soit 120 à 130 développeurs. Cette problématique de plateforme monolithique devient d’autant plus importante, car le site mène une réorganisation de ses équipes sous forme de « Feature Teams », chacune d’entre-elles ayant la responsabilité d’une partie du code.
Pour que cette réorganisation prenne tout son sens, ces équipes agiles doivent pouvoir mener leurs développements de la manière la plus indépendante possible, sans qu’il soit nécessaire pour elles de synchroniser leurs développements en permanence les unes avec les autres. Chacune doit pouvoir se développer à son rythme, pousser en production leurs développements au fur et à mesure que ceux-ci sont prêts, ce qui est bien évidemment très compliqué lorsqu’il s’agit d’une application monolithique.
Une plateforme logicielle performante, mais obsolète
Une autre raison de cette refonte est que l’applicatif est principalement écrit en langage C, un langage simple mais de moins en moins en vogue auprès des jeunes développeurs. En outre, LeBonCoin s’appuie sur un framework interne, développé par la maison mère de LeBonCoin, ce qui bridait les ambitions des développeurs français à vouloir le modifier.
« Nous n’avions pas de problème de performances avec le C. Pour preuve, tout le monde tend à penser que les annonces sont affichées au moyen de caches sur LeBonCoin car l’affichage d’une annonce semble identique d’un utilisateur à l’autre, or il n’en est rien. Toutes les pages d’annonces étaient générées dynamiquement avec un module Apache écrit en C spécifique à ce framework. Si nous n’avions pas de problématique de performance avec cet applicatif, nous étions arrivés à nous demander si nous devions rester jusqu’au-boutiste de la performance et maintenir cette plateforme sur laquelle nous avions de plus en plus de mal à recruter des développeurs car des compétences de pointe en C sont de moins en moins fréquentes sur le marché et nous avions du mal à faire évoluer toutes les briques de ce framework applicatif. »
C’était notamment le cas du moteur de recherche, une fonctionnalité clé sur un site de petites annonces mais qui faisait partie du framework et qu’il était difficile de faire évoluer.
Afin d’éviter de se lancer dans un grand projet de type "Big Bang" portant sur un redéveloppement complet du site, projet dont la date de fin est toujours la grande inconnue, LeBonCoin a privilégié un basculement progressif vers une infrastructure plus moderne : « L’une des possibilités qui s’offraient à nous était de commencer à découper le monolithe en sortant peu à peu des fonctionnalités sous forme de microservices. C’était une approche que nous avons jugée moins risquée que réaliser un Big Bang qui n’était clairement pas une approche envisageable, car on sait quand commence un tel projet et on ne sait jamais quand il s’achève. »
Le langage C laisse la place au GO
Pour ce développement de microservices, LeBonCoin a fait le choix du langage GO, notamment du fait de la simplicité de sa syntaxe, relativement proche du C, ce qui allait faciliter la transition des développeurs en place.
Autre atout du langage créé par Google, les binaires n’embarquent aucune dépendance, une particularité particulièrement précieuse dans le déploiement de multiples microservices et qui permet d’éviter les conflits de versions de librairies de microservices tournant sur une même machine.
Plutôt qu’une roadmap de migration totalement planifiée de l’ensemble des fonctions de la plateforme, LeBonCoin a opté pour une migration opportuniste, c’est-à-dire au fur et à mesure des demandes d’évolution. Les fonctions n’évoluent donc plus dans le monolithe, mais sont à cette occasion re-développées en GO afin de donner naissance à un nouveau microservice.
« C’est un chantier qui fut au départ assez périlleux car il nous fallait continuer à faire évoluer le monolithe en parallèle à la création des premiers microservices. Aujourd’hui, la liste des microservices s’est allongée et approche maintenant la centaine. Nous maîtrisons beaucoup mieux le périmètre des modifications à apporter pour attaquer tel ou tel nouveau microservice », raconte le directeur de l’infrastructure du site.
Tout le volet moteur de recherche a maintenant été migré, de même que les fonctionnalités liées à la gestion des comptes utilisateur, du paiement et de la messagerie. Reste aux équipes du BonCoin à migrer la fonction certainement la plus importante du site, c’est-à-dire le dépôt d’annonce.
« Cela s’annonce être un gros chantier pour nos équipes car ce dépôt sollicite de nombreuses fonctions qui sont encore dans le monolithe et le travail mobilisera les développeurs tout le premier semestre 2019 pour parvenir à extraire du monolithe toutes ces fonctions liées au dépôt d’annonces » précise Jean-Louis Bergamo. Tous ces microservices communiquent entre eux via API REST.
La migration vers la version 3 de cet orchestrateur permettra à LeBonCoin de se passer totalement de Jenkins.
Parmi les difficultés rencontrées depuis le lancement du projet, le manque de documentation des fonctions et les effets de bord inattendus sur d’autres fonctions du site. En parallèle, LeBonCoin a fait évoluer sa chaîne d’intégration continue. « Notre plateforme d’intégration continue, est passée d’une chaîne où beaucoup d’étapes nécessitaient encore des interventions humaines avant d’arriver en production, à une plateforme où nous sommes en déploiement continu sur l’ensemble de nos microservices. Le tout avec des développeurs qui sont maintenant autonomes, afin de pousser les microservices en production, sans intervention d’un opérateur, d’un exploitant. » C’est pour atteindre cet objectif d’automatisation que LeBonCoin délaisse de plus en plus Jenkins pour aller vers un outil de l’écosystème OpenStack, Xuul. La migration vers la version 3 de cet orchestrateur permettra à LeBonCoin de se passer totalement de Jenkins.
La solution des containers s’est imposée d’elle-même
Afin d’éviter toute mauvaise surprise, Jean-Louis Bergamo a joué la sécurité pour la mise en production des premiers microservices : « Au début, nous avons lancé nos premiers microservices en mode VM, c’est-à-dire une machine virtuelle qui ne faisait tourner qu’un seul microservice. Nous savions que cette approche était assez lourde et nous n’avions pas encore de retour d’expérience sur les ressources machine qui allaient être nécessaires pour faire tourner nos microservices. Extraire ainsi une fonction parmi tant d’autres sur des serveurs multitâches ne nous donnait pas d’indications précises quant au dimensionnement de la plateforme cible. Parfois, nous surdimensionnions la plateforme en allouant vingt VM pour une fonctionnalité qui n’en nécessitait finalement que 2 et à l’inverse il nous est arrivé de devoir passer de 20 à 30 puis à 50 pour faire face à la demande. »
L’approche était assez empirique et ce scaling "manuel" de la plateforme était très consommateur de temps. Disposer d’un orchestrateur qui provisionne automatiquement les ressources sur les nœuds disponibles était une solution extrêmement intéressante pour LeBonCoin et c’est naturellement vers les containers et Kubernetes que LeBonCoin s’est tourné.
« Créer des VM avec un système d’exploitation pour ne faire tourner qu’un seul binaire était loin d’être une approche optimale et c’est ce qui nous a naturellement poussés à nous intéresser aux containers. L’approche qui nous semblait bien répondre à notre besoin d’exécuter des microservices et la présence d’un orchestrateur tel que Kubernetes allait nous permettre de moduler la charge et automatiser le lancement des containers, en fonction de la demande en microservices de la plateforme. »
Cette optimisation des ressources est d’autant plus importante que LeBonCoin exploite encore ses propres serveurs en datacenter et n’a mis que quelques services dans le cloud public. Le site s’appuie sur ses propres ressources matérielles, des ressources qui sont bien évidemment contraintes.
Jean-Louis Bergamo commente le tout début de cette migration : « Etonnamment, je le reconnais, la migration vers les containers s’est plutôt bien passée vis-à-vis de la plateforme d’exécution. Venant moi-même du monde de l’infrastructure, nous avons plutôt une approche prudente et on privilégie les solutions éprouvées. Cela faisait plusieurs années que nous entendions parler des containers et tout le monde ne fait pas encore tourner des containers en production à large échelle. Nous étions un peu prudents sur la question. »
Le directeur infrastructure a privilégié une approche prudente, déployant le cluster Kubernetes tout en conservant en parallèle ses VM. « En cas de soucis sur le cluster Kubernetes, nous pouvions toujours le désactiver, la partie VM assurant la charge. Mais contrairement aux craintes que nous pouvions avoir, la migration vers les containers s’est plutôt bien passée et nous n’avons pas connu de panne majeure sur cette nouvelle infrastructure. »
L’API Gateway, le chantier 2019 de LeBonCoin
Tous les containers développés par LeBonCoin sont « stateless », ceux-ci n’ont pas besoin de stocker des données localement, ce qui simplifie énormément le fonctionnement de la plateforme. Toutes les données sont stockées en bases de données ou dans des caches Redis. Les bases de données continuent pour leur part de fonctionner sur de grosses machines « bare metal » dédiées à cela et si certaines entreprises déploient leurs bases de données en containers, Jean-Louis Bergamo ne considère pas suivre cette voie à court terme.
« Les développeurs ont été moins bousculés que nous, à l’infrastructure, par l’arrivée des containers. »
Jean-Louis BergamoDirecteur de l’infrastructure LeBonCoin
Pour les développeurs, ce passage aux containers n’avait rien d’une nouveauté. Ceux-ci utilisaient déjà des containers dans leur environnement de développement local afin de recréer la plateforme d’exécution du site sur leur ordinateur portable. « Les développeurs ont, sans doute, été moins bousculés que nous, à l’infrastructure, par l’arrivée des containers. Désormais, ils sont totalement autonomes pour pousser des services en production, le gain de temps et de confort pour eux est indéniable. Côté "Ops", il reste encore quelques tâches de configuration notamment pour les load balancers afin d’aiguiller correctement le trafic vers les microservices. Cette partie est encore manuelle mais notre objectif est d’aller vers une API Gateway qui puisse faire cela de manière automatique. »
Le Directeur Infrastructure évalue notamment l’Ingress pour Kubernetes afin d’automatiser ce paramétrage, par contre c’est tout le routage de nos API qui devrait pouvoir s’alimenter d’Ingress afin de réaliser ce routage depuis l’extérieur. « Nous étions partis sur Kong et actuellement beaucoup de nos microservices sont derrière Kong, mais cela ne nous satisfait pas totalement. Nous cherchons actuellement d’autres solutions pour réaliser une configuration totalement automatisée de nos nouveaux microservices. »
