BlaBlaCar met son infrastructure en containers pour gagner en vitesse
Dans le but de répondre toujours plus vite aux nouvelles demandes du marché, BlaBlaCar a revu intégralement le fonctionnement de son SI. Ici, ni Cloud, ni machine virtuelle. Tous les services fonctionnent en containers.
Provisionner plus vite des instances de ses services pour mieux répondre aux pics d’activité comme aux nouveaux besoins, en exécutant ses applications et ses bases de données dans des containers plutôt que dans des machines virtuelles. Tel a été, depuis 2014, le parti pris de BlaBlaCar, la marque française de covoiturage qui compte désormais 40 millions de membres dans 22 pays (principalement en Europe et en Asie).
« Malgré notre succès, nous sommes toujours une start-up qui cherche à devenir rentable. Cela signifie que nous devons aller vite pour lancer ou modifier des produits quand la demande du marché évolue. C’est cette quête d’agilité qui nous a poussés à adopter les containers », lance Simon Lallemand, ingénieur système chez BlablaCar.
Les containers, popularisés par des logiciels Open source comme les moteurs Docker et Rkt, ou encore les orchestrateurs Kubernetes, Docker Swarm et autres Apache Mesos, sont des sortes de machines virtuelles sans système d’exploitation. Chaque container ne contient qu‘une application et le fonctionnement de chacune d’elle est assuré par le système d’exploitation sous-jacent (Linux, généralement) qui exécute les containers.
L’enjeu de trouver moins cher que le Cloud ou les VM
L’histoire de ce projet commence en 2014. A l’époque, BlablaCar a 150 serveurs en production, certains physiques (pour les bases de données, avec SAN externe) et d’autres virtuels (instances de l’application principale, frontaux PHP, etc.).
« Le problème de cette configuration est que nous devions acheter du matériel à chaque fois qu’il fallait mettre en production une nouvelle base de données, c’est-à-dire attendre des semaines avant que l’on nous livre l’équipement nécessaire et ensuite passer encore du temps à installer/tester dessus nos logiciels. Les délais étaient devenus intenables au regard de notre besoin de réactivité et il nous fallait trouver une alternative », raconte Simon Lallemand.
Il rejette l’option classique de faire héberger son SI dans un Cloud public, avec des infrastructures débrayables à la demande, car les applications de BlaBlaCar sont difficiles à migrer vers ce format.
Les ressources louées dans le cloud lui reviendraient à terme bien plus cher que les serveurs physiques
De plus, note-t-il d’après une simulation, les ressources louées dans le cloud lui reviendraient à terme bien plus cher que les serveurs physiques qu’il achète une bonne fois pour toutes.
L’idée de constituer un Cloud privé à partir d’un réservoir de serveurs génériques, avec stockage intégré plutôt que SAN externe, est plus séduisante. Mais la couche VMware pour le faire coûte cher et, surtout, n’élimine pas plus la corvée de configurer l’OS et les logiciels de chaque nouvelle VM.
« C’est alors que nous avons entendu parler des containers. Google, Facebook et consort les utilisaient pour déployer plus facilement leurs services et consommer un minimum de puissance de calcul, beaucoup moins qu’avec des machines virtuelles. Nous avions la conviction qu’il s’agissait d’une technologie d’avenir. Tout le monde a trouvé cela plus excitant que d’aller configurer des VM », ajoute Simon Lallemand.
Les solutions de containers sont livrées avec un outillage assez frustre. Qu’importe : « puisque nous n’avions pas de quoi mettre des containers en production, nous avons demandé à nos développeurs d’écrire ce qu’il nous manquait », lance l’ingénieur système.
C’est ainsi que nait Dgr (prononcer « Digger »), un utilitaire en ligne de commande qui configure des images de containers (format ACI) et les déploie sur les serveurs.
D’abord écrit comme un script Bash, puis en langage Go, Dgr est une surcouche de la commande Fleet de CoreOS qui distribue des configurations systèmes, ici selon des modèles définis dans un fichier au format YAML.
L’ensemble est opérationnel fin 2015.
A ce moment, BlaBlaCar bascule 80% de son SI (applications et bases de données comprises) en containers, sur une nouvelle flotte de serveurs, tous identiques et infogérés par un hébergeur de la région parisienne.
« Le bénéfice a été immédiat ; nous avons tout de suite observé que nos services répondaient bien plus rapidement. Ce n’est pas tant à cause des nouvelles machines, plus puissantes que les précédentes. C’est surtout que nous pouvions désormais supporter la moindre montée en charge en tapant une seule commande pour passer de 10 frontaux PHP à 15 par exemple. Auparavant, un tel ajustement nous demandait une journée entière de configuration », dit Simon Lallemand.
Quant aux bases de données - auparavant tributaires de l’achat, de la livraison, puis de l’installation de nouveaux matériels - elles se déploient désormais en moins de dix minutes.
« Nous avions pris la mauvaise habitude de surcharger les bases existantes pour éviter les délais. Ce qui débouchait sur de la complexité et des baisses de performances. Ne plus être obligé de le faire est une véritable avancée », se satisfait Simon Lallemand.
Il note toutefois que, ne pouvant plus profiter de la réplication des données intégrée aux SANs, il a fallu adapter les applications de BlaBlaCar pour qu’elles créent elles-mêmes des copies de secours.
Un SI 15 fois plus performant
Depuis la bascule du SI vers des containers, BlaBlaCar n’a rencontré qu’un seul problème : des crashs des serveurs physiques à cause d’un bug dans leur firmware.
Nous sommes graduellement passés de notre outil maison Dgr à Kubernetes
Simon Lallemand, BlablaCar
« Ce problème n’a rien à voir avec le choix des containers. En revanche, nous avons mis un bon mois à le résoudre. Pendant ce délai, nous avons pu tester la capacité de nos containers à maintenir notre SI en fonctionnement malgré les crashs aléatoires », commente Simon Lallemand.
Autre événement marquant, en juin 2016, l’orchestrateur de containers Kubernetes est devenu compatible avec la technologie Rkt, de CoreOS.
« Toutes les fonctions possibles ne sont pas encore intégrées. Néanmoins, nous sommes graduellement passés de notre outil maison Dgr à Kubernetes car ce dernier permet de déployer automatiquement les containers au bon endroit de notre cluster de serveurs physiques. Sans lui, c’est un humain qui doit taper la commande de déploiement en choisissant arbitrairement un serveur physique » explique l’ingénieur système.
« Découvrir que Rkt était plus adapté que Docker, créer un outil de déploiement ou encore résoudre la réplication des données sont des complexités que nous aurions pu confier à un intégrateur. Nous ne l’avons pas fait car cette prestation coûte cher pour une start-up telle que la nôtre. Et notre culture est plutôt de valoriser notre expertise interne », conclut-il.
En tout, BlaBlaCar dispose aujourd’hui de 2200 Pods en production (un Pod correspondant au container d’une application ou d’une base de données, plus des containers accessoires, par exemple celui qui assure le monitoring). Soit 15 fois plus d’instances qu’en 2015.
