Retex : comment LeBonCoin a migré ses 500 serveurs vers AWS

Avec 29 millions d’utilisateurs et 51 millions d’annonces en ligne, LeBonCoin est un poids lourd du Web français. Comme beaucoup d’entreprises Internet, son infrastructure s’est bâtie dans une approche « on-premise » (sur site).

Plus de 500 serveurs étaient en ligne pour assurer le service, avec un délai de plus de trois mois entre l’achat d’un nouveau serveur, sa configuration, puis la mise en ligne. Après la plateforme data en 2015, la décision est prise de migrer cette infrastructure de production sur le Cloud d’Amazon Web Services.

Guillaume Chenuet, alors Infrastructure Engineering Manager chez LeBonCoin détaille ce projet qui devait être mené en douze mois maximum : « Pour être sûrs de migrer, nous avons envoyé un courrier à nos hébergeurs pour mettre fin aux contrats en cours dans douze mois. L’autre choix important fut de faire du Lift and Shift, migrer tels quels nos serveurs on-premise vers AWS. Nos applications n’étaient pas véritablement compatibles avec le Cloud, mais c’était un moyen d’être sûrs de migrer et d’être prêts à temps. »

Impliquer tous les Ops dans le projet

Un plan de migration a été soigneusement élaboré, avec un rétroplanning pour chaque composant logiciel, chaque environnement et un comité de pilotage de migration chaque semaine, pour vérifier l’avancement du programme, et un budget de migration a été fixé.

Les choix techniques sont rapidement établis et doivent s’appliquer à l’ensemble des équipes. Une autre règle de base a été de rester collé aux bonnes pratiques définies par AWS : « Le but
était vraiment de ne pas tordre les design patterns d’AWS, car nous allions modifier nos applica-
tions dans un second temps », précise Guillaume Chenuet.

Point très important pour le responsable, l’aspect humain du « Move to Cloud ». Comme les Ops (administrateurs des infrastructures) sont répartis dans les tribus des « Feature Teams » (équipes pluridisciplinaires), une guilde infrastructure a été créé. Tous les Ops se réunissaient chaque semaine afin de partager de la connaissance et former des groupes de travail pour trancher dans les choix de solutions, des ateliers.

Enfin, chose qui n’avait pas été anticipée dans le plan initial, la migration s’est menée pendant le Covid-19 et le premier confinement. « Cela ne nous a pas empêché de migrer, nous n’avons pas eu de problèmes de communication et de partage d’information car nous avions des ateliers et
nos comités de pilotage répartis tout au long de la Semaine, et cela a fonctionné comme si nous étions au bureau et ça fonctionne encore aujourd’hui », indique-t-il.

Une approche   »Infrastructure as code »

Du point de vue outillage, cette migration a poussé les équipes vers l’approche « Infrastructure as code » : « Nous déployions nos services dans nos data centers avec Puppet et nous avions une gestion de data center pour bootstrapper les serveurs physiques. Nous n’avions pas d’outillage pour faire de la « VM as a service ». Or nous ne voulions pas utiliser la console AWS manuellement, mais travailler dans une approche « As Code ». Nous sommes donc partis sur l’ »Infra as code » pour démarrer les services RDS, EC2 et CloudFront, c’était un moyen de faire du Lift and Shift sans que nos applications ne soient modifiées. »

Les six premiers mois du programme  » Lift and Shift » ont porté sur la migration des environnements de test (QA) et de pré-production (staging), puis ce fut au tour de la production en trois mois. « Par rapport au mode de fonctionnement on-premise, l’infrastructure coûte plus cher, mais cela nous apporte une scalabilité et une capacité de sortir de nouveaux services bien plus forte. »

Depuis, le FinOps a permis d’abaisser les coûts initiaux de la plateforme, notamment grâce au Scale Up/Scale Down de l’infrastructure EKS.

Pour aller plus loin sur le même sujet :

Comment Nexity a engagé sa transformation cloud

Migrer ses applications dans le cloud : quelle méthode choisir ?

Image :  © LeBonCoin