Comment BlaBlaCar a automatisé sa production IT

Multiplier le nombre de serveurs par près de 10 sans changer la taille de ses équipes d’architectes et d’admin. C’est le défi relevé par BlaBlaCar, grâce à une automatisation de ses infrastructures. Sans pour autant céder à la mode du tout Cloud ou même d’une virtualisation totale.

Concevoir une infrastructure suffisamment automatisée pour accompagner la croissance explosive de la start-up sans accroître significativement les effectifs. C’est à ce défi que s’est attelée l’équipe architecture de BlaBlaCar, qui gère aujourd’hui 242 serveurs physiques et 109 machines virtuelles tournant dans deux datacenters que la société opère, auxquels s’ajoutent 110 instances Amazon EC2 venant renforcer le socle d’infrastructure. « En environ un an, c’est une croissance spectaculaire. Et, pour l’encaisser, nous avons tout automatisé », raconte Nicolas Blanc, responsable de la plateforme architecture team chez Blablacar, qui présentait cette industrialisation de l’infrastructure de la start-up lors de la première édition du TIAD (The Incredible Automation Day), événement organisé par la SSII D2SI et centré sur le thème de l’automatisation IT.

De facto, l’infrastructure en place avant la transformation aurait été incapable d’encaisser la progression du spécialiste du covoiturage (qui compte aujourd’hui quelque 10 millions d’abonnés). Il y a seulement 2 ans environ, BlaBlaCar alignait 3 racks renfermant chacun 12 serveurs dans un unique datacenter, avec 20 configurations différentes. Le recours au Cloud public était alors limité aux tests. « Nous avons commencé par automatiser les configurations, dès 2012 », se remémore Nicolas Blanc. L’équipe architecture évalue alors les outils CFEngine, Puppet et Chef, hésite entre les deux derniers et opte finalement pour Chef du fait de la puissance de sa communauté. « Puis, nous avons commencé à travailler sur le serveur Web front », afin d’harmoniser les configurations dans Chef. Un processus ensuite étendu à l’ensemble de l’infrastructure logicielle.

Des VM… mais aussi des serveurs physiques

« Il restait encore à industrialiser la partie matérielle, raconte Nicolas Blanc. Auparavant, nous avions une configuration de serveurs différente pour chaque service. C’était difficile à designer et à mettre à jour ». C’est ce qui a notamment poussé BlaBlaCar à mettre en place une plate-forme virtualisée. Une architecture basée sur VMware « pour des questions de stabilité ». Mais la start-up a fait le choix de conserver des serveurs physiques notamment pour des applications exigeantes en matière de performances en entrées/sorties. Si la société française a aussi recours à AWS, le Cloud d’Amazon, pour des besoins ponctuels (mailings, tests ou autres tâches temporaires), un usage plus généralisé du nuage a été écarté pour plusieurs raisons : « des questions relatives à la confidentialité des données, un besoin d’élasticité limité dans une société qui ne fait que croître, des problématiques de coûts et la culture interne de l’entreprise », énumère l’architecte.

[A lire notre dossier : 10 outils Open Source indispensables pour maîtriser le Cloud]

Les serveurs eux-mêmes ont aussi été standardisés. « Tous les services peuvent maintenant fonctionner sur des machines standards, embarquant 2 processeurs, 12 cœurs et 128 Go de RAM. Seule la configuration disque change, passant de deux disques SSD à des capacités bien plus importantes pour les applications Hadoop ou MariaDB », précise Nicolas Blanc. Cette standardisation a aussi permis d’automatiser la mise en service des serveurs physiques dans les datacenters. Un passage obligé alors que la société s’internationalise et déploie ses infrastructures un peu partout dans le monde. « Cette tâche peut demander beaucoup de temps et les datacenters peuvent être très loin désormais », note Nicolas Blanc. BlaBlaCar s’approvisionne désormais en racks pleins et a externalisé leur installation sur la base d’une procédure standardisée où, avec l’appui des outils d’automatisation, les équipes de la start-up peuvent notamment tester de façon automatique la quasi-totalité de la pile logicielle installée sur le serveur. « Un rack est ainsi installé en moins d’une journée », assure l’architecte.

Peu d’ops, beaucoup de serveurs

Car, en parallèle, l’équipe chargée de la production informatique a travaillé à l’automatisation de l’installation des couches logicielles sur les serveurs. Pour ce faire, la start-up a retenu Preseed (pour la configuration de sa distribution Debian sur les serveurs physiques ou les VM) et Foreman, outil de gestion du cycle de vie des serveurs utilisé surtout par BlaBlaCar pour le provisioning (la solution appelle ensuite Chef). Cette galaxie d’outils Open Source est complétée par Collins, qui gère l’inventaire matériel et se connecte à Foreman.

Nicolas Blanc 2Mais « il ne faut pas trop s’attacher aux outils », prévient Nicolas Blanc. Démarré voici 3 ans, le processus d’automatisation nécessite surtout, selon lui, « l’implication de toute l’entreprise. Quand nous avons mis Chef en production, pendant un mois, nous ne pouvions pas délivrer des services aussi rapidement qu’habituellement. Il faut que ce soit compris et admis », résume l’architecte. Qui milite également pour préserver l’esprit qui prévaut dans une petite équipe. Chez BlaBlaCar, l’équipe de 7 architectes chargés du design des infrastructures et de l’administration n’a pas grossi en un an. Malgré l’explosion du nombre de serveurs. « Quelques ‘ops’ peuvent prendre en charge de grandes quantités de serveurs », dit Nicolas Blanc. Au total, l’équipe technique de BlaBlaCar regroupe une cinquantaine de personnes.

Mises en production : no limit

L’automatisation de la production (la partie ‘ops’) est à mettre en regard de celle qui existe également côté développement (le ‘dev’ de devops). Chez BlaBlaCar, l’équipe de développement est responsabilisée jusqu’à la mise en production. « Elle est en mesure de pousser 10 versions différentes de notre principale application par jour. En réalité, il n’y a pas de limite », dit Nicolas Blanc. L’intégration continue est prise en charge par un outil appelé Bamboo, offrant des fonctions similaires à celles de Jenkins, et facilitée par une forte automatisation des tests. « Même si une mise en production se passe mal, nous sommes en mesure de revenir en arrière en 10 ou 15 minutes, assure Régis Allegre, vice-président engineering de BlaBlaCar. Avec le déploiement progressif, la plupart des utilisateurs ne s’aperçoivent de rien. »

Dans les mois qui viennent, les équipes de production devront gérer l’ouverture de nouveaux datacenters (une troisième implantation en France, et des ouvertures en Amérique latine et à Singapour), devrait se pencher sur la migration de ses bases vers Cassandra ou une technologie similaire et prévoit de migrer vers les conteneurs pour certaines applications. « Certains services, comme Redis ou Memcache, n’utilisent pas la capacité pleine d’un serveur », note Nicolas Blanc, qui voient dans les conteneurs Docker ou Rocket une technologie prometteuse pour gravir cette marche supplémentaire en matière d’optimisation de l’infrastructure. Et peut-être pour remplacer l’infrastructure virtualisée VMware sur la partie Linux.

A lire aussi :

Docker : déjà bon pour le service ?
Big Data : Blablacar copilote sa BI avec HP, Tableau et Dataiku
Open Source : Chef donne ses recettes pour administrer le Cloud