Jean-Louis Bergamo, LeBonCoin : « Ce qui a été fait maison est ultra performant »

Pour le second épisode de notre série très tech « Sous le capot », KMF poursuit son enquête sur les dessous de ce monde obscur et merveilleux : le CTO et son équipe technique. Peu friands des projecteurs, perfectionnistes, méticuleux et discrets, ces héros du quotidien pratiquent plus volontiers meetups techniques avec ses bières-pizzas tièdes que les cocktails d’investisseurs arrosés de champagne.

Après Nicolas Helleringer de Criteo, Stéphanie part à la rencontre de Jean-Louis Bergamo,

 

Jean-Louis, raconte-nous qui tu es !

Je m’appelle Jean-Louis Bergamo et ça va faire une vingtaine d’années que je bosse dans l’infrastructure. J’ai fait quelques sites qui parlent aux plus anciens tels que les SkyBlogs. Je suis arrivé chez SkyRock début 2007 quand l’audience était sur une pente très ascendante et j’ai assisté au déclin quand Facebook est arrivé en France et en Français. J’ai aussi travaillé chez le fournisseur d’accès Easynet puis j’ai fait de l’infrastructure chez Winamax avant d’atterrir dans le monde des petites annonces chez Figaro Classified (Cadremploi, Keljob).

 

Quel est le rôle pour lequel tu as été initialement embauché chez LeBonCoin ?

Je suis entré en tant que responsable infrastructure en 2013. C’est un poste que j’occupe toujours, sauf qu’on m’a donné une médaille en chocolat, enfin une promotion depuis (rires). Je suis maintenant Directeur Infrastructure, ce qui en impose bien plus, non ? Entre temps l’équipe s’est étoffée : au départ nous avions une seule équipe de sysadmin, à présent il y a 3 pôles d’une quinzaine de personnes:

  • une équipe SRE qui s’occupe d’assurer la disponibilité du site
  • une équipe Engineering Productivity qui s’occupe de toute la chaîne de delivery : du code jusqu’à la production, l’infrastructure de test et de packaging ainsi que l’outillage pour les devs au quotidien.
  • la dernière équipe s’occupe de l’infrastructure du bâtiment

 

Et côté dev ?

Ça bouge pas mal : on doit être aux alentours de 110/120 personnes. LeBonCoin est réparti sur plusieurs sites mais l’activité technique, marketing, produit, finance, est dans les locaux parisiens.

 

LeBonCoin, c’est Français ?

Contrairement à ce que beaucoup de gens pensent, pas vraiment ! On appartient à Schibsted,un groupe de presse Norvégien qui a racheté un site de petites annonces en Suède qui s’appelle Blocket, et qui l’a répliqué dans d’autres pays dont la France. C’est comme ça que LeBonCoin est né  ! Pour la petite anecdote, à la base cela devait s’appeler « Chez Georgette », en référence au prénom de la grand-mère du DG de l’époque (ndlr : qui était Olivier Aizac).

“La mission de LeBonCoin c’est de toucher tous les Français au moins 1 fois dans l’année et de faciliter la mise en relation entre les particuliers.”

Quels sont les produits proposés par LeBonCoin ?

C’est de la petite annonce : un seul produit avec plusieurs verticales. Néanmoins, depuis peu de temps, on fait de la croissance externe, mais toujours dans le domaine de la mise en relation entre particuliers. Le groupe LeBonCoin a ainsi racheté MB Diffusion, spécialisé dans matériel agricole et BTP d’occasion,  et on s’était aussi positionné pour racheter Viadeo.

 

Quels sont vos challenges techniques ?

La mission de LeBonCoin est de toucher tous les Français au moins 1 fois dans l’année et de faciliter la mise en relation entre les particuliers. Le défi, c’est d’être performant et disponible en permanence. On essaie de supprimer tous les goulots d’étranglement et SPOF (Single Point of Failure), mais il en reste toujours un peu et certains sont difficiles à éradiquer. C’est notamment le cas avec la base de données : si notre master tombe, il n’y a pas de bascule automatique. C’est volontaire car on veut éviter les bascules intempestives qui engendrent ensuite des problèmes de réconciliation de données.

“Plus le site est performant, plus on a de l’audience : on est aujourd’hui à un stade où la plateforme est très performante mais plus difficile à faire évoluer, notamment sur les fonctionnalités front”.

Est-ce voulu d’avoir une ergonomie un peu « roots » ?

Le site a quand même évolué l’année dernière : on est passé en mode responsive ! La volonté c’est de garder une ergonomie très simple car c’est ce qui a fait son succès : on dépose et on recherche les annonces très facilement. Au lancement, la tendance était aux enchères sur des biens vendus à l’autre bout du monde avec des commissions. LeBonCoin a pris son contre pied radical en proposant de trouver ce qu’il te faut au coin de la rue, gratuitement. Ce qui a joué, c’est la simplicité du produit, sans avoir des menus et des onglets dans tous les sens: c’est accessible et utilisable par tous.

 

Des sites comme Reddit gardent une forme ultra simpliste pour optimiser le temps de chargement des pages, est-ce également un de vos objectifs ?

Sur l’aspect design, la performance dépend essentiellement de la manière dont est développé le site. Tout le monde pense qu’on cache nos pages tant elles s’affichent rapidement mais en fait elles sont générées dynamiquement via un module en C intégré à Apache. Le revers de la médaille c’est qu’on a un langage de templating développé en interne qui n’est pas des plus user friendly, et donc les intégrateurs ne sont pas forcément à l’aise pour concevoir des pages qui clignotent dans tous les sens. C’est aussi une des raisons pour lesquelles le passage en responsive a pris plus de temps.

 

Ce mécanisme de génération de page à la volée, est-ce que vous le conservez volontairement pour les questions de performance ou simplement c’est du legacy, ça marche bien et vous avez d’autres priorités ?

Grosso modo, on le conserve pour la performance mais oui, c’est du legacy. On est né du rachat de Blocket par Schibsted qui a implanté cette plateforme dans chaque pays pour démarrer l’activité. A titre de comparaison, pour le même nombre de pages vues chez Skyrock en PHP, chez LeBonCoin on a 10 serveurs frontaux et chez SkyRock on en avait 150 !

On le sait : plus le site est performant, plus on a de l’audience. On arrive à un stade où l’on a une plateforme très performante mais qui est difficile à faire évoluer, ce qui nous ralentit dans l’évolution des fonctionnalités front qu’on peut proposer à nos utilisateur. On a un gros chantier pour passer sur des technos type react.js avec de l’interactivité, mais on va forcément retomber sur des questions de performance.

“Nous sommes hébergés dans des DCs publics en mode “salle blanche” : les 2 hébergeurs nous fournissent un espace vide, l’électricité, et la clim, et on gère nos baies, nos serveurs, le réseau.”

Justement, comment avez-vous résolu la question de la scalabilité ?

Dès les départ, que ce soit côté back ou front, on sait faire du scaling horizontal très facilement. L’enjeu est surtout présent côté base de données, car elle ne sait scaler que verticalement, comme toutes les bases relationnelles. C’est pour cela qu’on veut revoir l’architecture de nos services : c’est là que se situent nos plus gros problèmes de production.

 

LeBonCoin c’est 600 personnes dont 250 en région dans des centres de télévente, 350 au siège à Paris, 120 personnes dans les équipes techniques.

 

Sur quelles technologies est basée la solution ?

Tout est basé sur un middleware historique en C qui fait l’abstraction entre le front, le back et l’accès aux bases de données Postgresql et Redis. On est en phase de transformation d’une plateforme à une autre car l’existant est très monolithique et toutes les fonctionnalités sont un peu liées entre elles. Ça ne simplifie pas la mise en production et c’est pourquoi on voudrait découper ce middleware en domaines d’activité. Côté langages on a principalement du C, un peu de python, des scripts shell, des choses assez dépendantes de l’environnement et de l’OS. C’est pourquoi on a décidé de passer à Go où tout est linké statiquement, tout en conservant une syntaxe assez similaire au C.

 

Comment faites-vous la communication entre les différents services ?

Ce sont des appels d’API REST d’un service à un autre tout simplement. On passe aussi par des tables Postgresql qu’on utilise comme des queues. C’est géré par notre fameux middleware historique dans lequel nos processus vont pooler régulièrement une table pour connaître les tâches à traiter. Ce middleware est encore assez monolithique : on peut faire du scale-out néanmoins puisque la seule dépendance est la base de données. On est en train de le découper en tâches plus petites ce qui permettrait de les mettre plus facilement à jour sans risquer de casser ce qui se passe à côté mais aussi de faire du scaling plus ciblé. A ce jour, on peut scaler facilement la totalité mais si une fonction se met à engorger tous les slots de connexion, l’ensemble de nos serveurs sont saturés car ils sont bloqués par une fonction.

“Dans le Cloud, tu peux scaler à l’infini alors que dans nos datacenters on est borné.”

A quoi est lié ce goulot d’étranglement ?

Il faut savoir que le site LeBonCoin est séparé en deux : une partie lecture et une partie écriture. Côté lecture, on utilise un moteur d’indexation maison et ça enlève une grosse charge à la base de données. Le site est rarement indisponible pour la partie consultation des annonces. La modification, elle, repose sur le middleware cité plus haut. Il peut y avoir des blocages sur l’accès à la BDD ou au stockage. En fait, le souci, c’est le ralentissement, pas le plantage. C’est lié au niveau de ressources allouées sur le serveur : ces serveurs font du spooling de connexion mais au niveau des clients, ils vont accepter des milliers voir des millions de connexion qui vont passer en attente.

 

Vous avez un cluster Postgresql ? Quel est votre mode de réplication ?

Effectivement, on est en master/slave. La BDD est hébergée chez nous : on a 4 serveurs physiques HP DL980 avec 160 cœurs dans chaque machine, 2To de RAM et 10 To de stockage Flash. Nous sommes hébergés dans des DCs publics, chez 2 hébergeurs traditionnels en région parisienne en mode “salle blanche” : ils nous fournissent un espace vide, l’électricité, et la clim, et on gère nos baies, nos serveurs, le réseau. On utilise aussi du cloud public AWS pour des projets qui ont besoin d’élasticité : typiquement pour la data quand on a besoin de retraiter le plan de données.

 

Pour la partie analytique de la data, qu’utilisez-vous ?

On fait surtout du log d’activité. Côté back, la collecte des données se fait avec Kafka. Ça part vers un data warehouse Redshift pour analyser les usages a posteriori. Le traitement batch se fait avec Spark, il me semble qu’on ne fait pas de streaming. Le résultat du traitement est utilisé à des fins de reporting pour les équipes métier, pour cela on utilise des dashboards dans Tableau.

“Avec les conteneurs, le dev peut utiliser sa propre machine dans son coin et le conteneur pourra ensuite être poussé jusqu’en production tout en restant dans un environnement qui lui est propre et restreint.”

Et côté monitoring technique ?

On a principalement des données de monitoring et des indicateurs d’activité du site assez classiques, comme le nombre de requêtes ou d’insertions par seconde. On utilise un outillage historique; le descendant de big brother : Xymon surtout pour la partie monitoring matériel et bas niveau. Pour faire des dashboards, on a un mix entre Grafana et Kibana qui vient avec notre stack ELK. D’ailleurs, j’aime l’appeler ELKK, car on le couple à Kafka pour récupérer l’ensemble des logs systèmes et les injecter dans Elastic Search. On utilise aussi du Datadog côté Cloud.

 

Vous utilisez donc Elastic Search uniquement côté monitoring infra ?

En fait pour la partie recherche du site web, on a fait le même constat que le pour le front : ce qui a été fait maison est ultra performant. Donc certes on n’a pas toutes les fonctionnalités d’Elastic Search, loin de là mais pour de la recherche de petites annonces, qui nous est très spécifique, c’est ultra performant et ça défonce Elastic Search avec un facteur 100 !

 

 

Quels sont vos outils d’industrialisation ?

On utilise Puppet : à la base, on s’est surtout concentré sur la partie infra où tout a été bien automatisé. Puis on s’est tourné vers les équipes de dev pour voir comment on peut uniformiser tout ça. On s’est aperçu que Puppet n’était pas spécialement pratique pour faire du déploiement. Donc on a commencé à regarder d’autres outils comme Ansible ou les conteneurs qui permettent d’avoir du packaging et un environnement d’exécution qui est le même du dev jusqu’à la production, ce qui résout beaucoup de problèmes. En effet, ce que les dev exécutent sur leur poste ne correspond pas vraiment à ce qui arrive en production : on se prenait les pieds dans le tapis à cause de différences de versions de librairies par-exemple. Avec les conteneurs, le dev peut utiliser sa propre machine dans son coin et le conteneur pourra ensuite être poussé jusqu’en production tout en restant dans un environnement qui lui est propre et restreint. On ne les utilise pas encore en production mais on y réfléchit très sérieusement.

“On n’est pas encore dans de la livraison continue, mais c’est notre objectif.”

Il y a aussi une volonté d’arriver à faire tourner les conteneurs de la même manière qu’on soit dans le Cloud public ou dans nos propres datacenters. Même si effectivement dans le Cloud, tu peux scaler à l’infini alors que dans nos datacenters on est borné… Il faut savoir que chez LeBonCoin on ne va plus faire x10 en restant franco-français : on a déjà couvert tout le marché.

 

Comment communiquez-vous entre les équipes dev et ops ?

Il n’y a pas de clivage car l’équipe est splitée en mode devops. C’est-à-dire qu’on a 3 équipes backend, 1 équipe frontend, 1 équipe backoffice et 1 équipe data. Chacun des SRE est réparti dans ces équipes, y compris physiquement sur le même pôle.

 

Comment faites-vous l’intégration et la mise en production ?

C’est un travail conjoint avec l’équipe engineering productivity qui tend à automatiser le plus possible tout ce qui est merge de branche et compagnie, pour packager et livrer ensuite côté production. On est dans une phase où l’on accélère le processus de mise en prod. On n’est pas encore dans de la livraison continue, mais c’est notre objectif. Jusqu’à très récemment on ne faisait qu’une seule mise en prod par semaine et maintenant on en fait minimum quatre. A terme on voudrait qu’un commit déclenche une mise en production si on passe toutes les étapes de validation automatique.

 

Avez-vous des outils spécifiques pour l’étape de validation ?

Surtout sur les environnements mobiles pour l’enregistrement des tests : nos équipes utilisent un logiciel à base de Raspberry Pi et de caméras qu’ils ont adapté pour faire des tests sur le mobile. Ils filment l’écran du smartphone pour avoir le cheminement et les étapes jusqu’au crash et pouvoir ainsi revenir dessus. Sur la diversité des devices, autant sur iOS c’est simple, autant sur Android, c’est la jungle.

“Côté validation, on utilise des robots et des solutions « maison » pour analyser les annonces et ça remonte si besoin auprès d’une équipe qui fait du manuel a posteriori.”

Vous faites des tests de charge, des tests auto ?

Pour les tests de charge automatiques, on n’est pas encore vraiment outillé. On les fait ponctuellement sur de nouveaux services qu’on veut passer en production.

 

Vous prévoyez donc de nouvelles fonctionnalités pour LeBonCoin ?

Oui ! Certaines fonctionnalités ne se voient pas directement sur le site. Par exemple on essaie d’avoir les même fonctionnalités entre les différents devices d’un utilisateur, pour qu’il puisse commencer une recherche sur son mobile et la continuer devant sa tablette, sur le Web.  Par contre nous avons d’autres fonctionnalités qui vont arriver dans les mois à venir, comme la messagerie intégrée au site, pour les échanges entre acheteur et vendeur. C’est un gros changement dans notre workflow de la vie de l’annonce et nécessite beaucoup de travail de toutes nos equipes, dont on se rend pas forcement compte vu de l’extérieur.

 

Vous gérez essentiellement des photos ainsi que des descriptions en langage naturel : comment se fait la validation des annonces ?

Pour la description de l’annonce que ce soit côté photo ou texte, il y a une partie automatique mais aussi beaucoup de modération manuelle a posteriori. On utilise des robots et des solutions « maison » pour analyser les annonces et ça remonte auprès d’une équipe de modération si besoin. Je ne saurais pas rentrer dans le détail car c’est moins mon domaine de compétences mais je sais que côté infra ils utilisent un cluster Mesos pour répartir les calculs et les tâches des différents modules de cet outil de modération. C’est l’équipe de modération qui a fait le choix de Mesos quand il était encore en bêta.

 

Côté sécurité, Web Application Firewall ?

On n’a pas de firewall en frontal ce qui en étonne certains. On a des load balancers type HA-Proxy qui vont faire office de firewall. On utilise beaucoup Modsec dans Apache pour faire un semblant de WAF. On a la chance d’appartenir à Schibsted qui a une équipe de sécurité et qui fait des pentests régulièrement en complément de ceux réalisés par une société indépendante. On corrige les alertes qu’ils remontent et au quotidien, on est plutôt dans l’analyse a posteriori de nos logs.

 

La prochaine techno que tu voudrais essayer ?

A titre perso, kubernetes, car ce que mes équipes m’ont montré m’a vraiment impressionné : je voudrais vérifier si c’est vraiment aussi sexy que ça en a l’air en production. On va commencer à jouer avec cela très prochainement sur nos propres serveurs avant de faire ça dans le Cloud. On préfère toujours commencer à tester chez nous car on a le contrôle total du contexte. En cas de souci on peut ainsi vérifier et pointer du doigt si cela provient du cluster kubernetes ou d’autres choses qui ne s’adaptent pas.

“Je suis manager depuis 10 ans maintenant, et LeBonCoin est la seule société à m’avoir proposé une formation de management.”

Le plus compliqué à gérer pour toi ?

C’est difficile d’être sur tous les fronts, et comme je suis tech à la base j’aime bien comprendre les choses mais j’ai du mal à tout suivre. Ca me frustre un peu : l’exemple de kubernetes est typique.

Sinon de manière générale : l’humain… et d’ailleurs je me rends compte que je préfère parler de technique que de parler de moi (rires) ! Plus sérieusement, au niveau management, quand on a des difficultés, on se dit que c’est plus facile de dire à une machine ce qu’elle doit faire ! Avec un humain, c’est plus compliqué, il y a des sentiments, des émotions, du relationnel et ça change tout.

 

As-tu suivi une formation pour t’aider à passer dans le management ? Est-ce que cela t’a aidé ?

Oui ! Je suis manager depuis 10 ans maintenant, et LeBonCoin est la seule société à m’avoir proposé une formation de management. Le contenu est conçu spécifiquement pour LeBonCoin, avec la même base et les mêmes codes pour tous. J’ai trouvé ça vraiment super (c’est la société Solar Management qui le propose). Il y a une part de Process Com qui consiste à se connaître d’abord soi-même. Comprendre comment on fonctionne permet d’anticiper comment tu vas réagir avec les autres et inversement, ce qui permet d’améliorer grandement la communication entre les personnes.

 

Aurais-tu un fail à partager ?

J’ai déjà planté LeBonCoin ! J’ai fait une erreur dans la configuration de haproxy et puppet l’a propagé bien comme il faut sur tous les load balancers. Tu les vois tomber les uns après les autres et comme tu viens de pousser une modification de configuration, tu sais bien que c’est à cause de toi ! Reste à trouver rapidement d’où ça vient.

 

Avez-vous un environnement de pré-prod ?

Oui, on a des environnements de dev/qa(quality assurance)/pré-prod/prod. Mais typiquement c’est le genre d’erreur qu’on a du mal à détecter avant la prod : c’était lié à la mauvaise orthographe d’une IP qui est forcément inhérente à l’environnement de prod.

 

Le truc dont tu es le plus fier ?

Je suis partagé entre une fierté technique et une fierté managériale. Depuis que je suis là, une seule personne a quitté l’équipe et je suppose que dans une certaine mesure, c’est aussi lié au manager.

 

Quels sont les profils que vous cherchez à recruter en priorité ?

On recrute dans tous les domaines et notamment des sysadmin (on cherche un DBA Postgresql par-exemple) et le développement mobile natif Android et iOS, des développeurs Go et front.

 

Est-ce que tu dors bien la nuit ?

Oui ! On a une équipe d’astreinte dont je fais toujours partie. Ca permet de garder le contact avec l’opérationnel.

 

Comment t’imagines-tu dans 10 ans ?

J’ai 44 ans, je m’imagine de moins en moins technique car les petits jeunes apprennent plus vite que moi, donc j’irai certainement vers du management de plus haut niveau. Ensuite, peut-être quitter la région parisienne pour être plus proche de la mer.

 

Une bonne résolution ?

Faire confiance aux conteneurs pour la production !

 

Peux-tu citer d’autres startups dont tu voudrais découvrir l’architecture ?

Datadog pour mon côté infrastructure et aussi VentePrivee, car je pense qu’il y a vraiment des choses à apprendre.

Les commentaires sont fermés.

Fièrement propulsé par WordPress | Thème : Baskerville 2 par Anders Noren.

Retour en haut ↑