Julien Lemoine, CTO d’Algolia : “on optimise dans un ordre de grandeur de la milliseconde”

La croissance vertigineuse d’Algolia impressionne et fait rêver…sans parler de leurs locaux sublimes flambants neufs sur 4 étages en plein Paris et leur terrasse panoramique – « la nôtre profite réellement à nos employés : nul besoin de monter à l’étage de Direction » me souffle Julien Lemoine leur CTO et co-fondateur. Qui se cache derrière une solution qui a su faire sa place dans le monde impitoyable du search ? Quelles sont les clés de leur succès ? Quelle architecture se cache derrière leur niveau de performance imbattable ? Si vous êtes utilisateur d’Elastic Search et que vous ne connaissez pas Algolia, attention, la lecture de cet article risque de faire battre votre petit coeur de dev.

 

Julien, peux-tu te présenter et nous parler de ton parcours ?

Je suis Julien Lemoine, CTO d’Algolia depuis 6 ans. Après avoir suivi une formation d’ingénieur à Epita, j’ai intégré le labo de recherche d’un grand groupe français : Thales. A l’époque l’objectif de ce labo était essentiellement de déposer des brevets. J’ai commencé ma carrière en bossant sur des algorithmes de data mining et text mining qui à l’époque étaient un peu des gros mots car très peu utilisés par-rapport à aujourd’hui. A ce moment-là Thales a racheté la société Arisem qui faisait de l’analyse sémantique de texte où j’ai rencontré Nicolas qui est devenu mon associé chez Algolia. C’était une opportunité pour moi de mettre en application sur des produits plutôt que juste déposer un brevet pour faire incrémenter un compteur global chez Thales. On a refait ensemble toute la stack technique en mettant notre recherche en application pour Arisem qui n’avait pas investi de ce côté là depuis un moment. Les grands groupes et les process n’étaient pas vraiment ce que j’avais en tête. J’attendais aussi autre chose de la recherche : j’en avais une vision assez idéaliste au départ où j’imaginais une communauté avec beaucoup d’entraide. J’ai découvert les guerres de chapelles, les co-citations, les recherches à la subvention… J’ai eu envie d’aller dans une startup, voir des choses différentes : quand je suis sorti c’était après l’explosion de la bulle où tout le monde rejoignait des grands groupes. Mais l’économie repartant et ayant envie de vivre une aventure plus pêchue, j’ai rejoint Exalead où l’équipe était encore petite.  Je suis arrivé en même temps que Clément Sténac (CTO de Dataiku, cf son interview #souslecapot) et ensemble on a très vite eu de gros challenges techniques autour de la scalabilité et notamment le passage de mono à multi machines et process.

« la culture d’entreprise est vitale pour avoir un impact »

Et puis le monde de la sémantique est arrivé et Exalead ne faisant rien dans ce domaine, j’ai créé une équipe sur le sujet pour améliorer le moteur de recherche qui était fait pour l’entreprise. L’équipe a grossi et on est entré dans le giron de Dassault Systèmes qui nous a rachetés en 2010. Là j’ai trouvé un autre type de culture encore très différent de Thales et qui ne me correspondait pas du tout

Différent de Thales ? C’est-à-dire ?

Je pense que c’est le stéréotype des sociétés tech où les gens ont pris des postes de management pour de mauvaises raisons : c’était pour eux la seule manière de progresser dans l’organisation. J’ai été impressionné par le nombre de personnes qui étaient de très bon contributeurs individuels et qui sont devenus de mauvais managers frustrés. Une des principales résultantes est d’avoir une culture de la terreur. A côté de ça, les résultats sont bons et la boite marche mais la culture ne me correspondait vraiment pas. La techno c’est ce que j’aime et c’est mon métier mais selon moi la culture d’entreprise est vitale pour avoir un impact.

Du coup j’ai rejoint une autre startup qui travaillait dans l’IA depuis longtemps : masa group. Il y avait un prisme Serious game pour le secteur militaire et un autre plutôt gaming. L’orthogonalité était trop grande pour une boite de 50 personnes : ce sont 2 aventures qui n’ont rien à voir. Au final mon job tournait plus autour plus de la stratégie que de la tech. J’ai commencé à faire du consulting en plus pour des startups américaines, c’était en 2012, pour réutiliser le skillset sur l’archi et les moteur de recherche. Le problème du search n’était toujours pas résolu et Elastic Search était déjà très populaire. C’est là qu’on s’est dit qu’on voulait avoir un impact sur l’industrie et aider les devs à résoudre les problématiques de search. J’ai re-discuté avec Nicolas et on s’est lancé avec Algolia en parlant beaucoup beaucoup de culture. Une majorité pensaient qu’on était un peu fous de partir sur ce marché du search où tout était déjà fait. Mais ce qui nous animait c’était la culture d’entreprise qu’on voulait avoir, savoir attirer les talents et les garder. On ne montait pas une startup pour la revendre mais vraiment être là sur le long terme. Cela fait 6 ans maintenant.

« c’est bien la perf qui a fait notre succès »

 

En quoi consiste la solution Algolia ?

On fournit un moteur de recherche hébergé pour les développeurs : aussi bien les débutants que les experts en search qui veulent pouvoir tout contrôler. On leur permet de se focaliser sur leur cœur de métier en gérant toutes les parties painful pour eux.

Quand tu dis « hébergé », tu penses « as a service » ?

Oui, c’est en SaaS : les machines et les données sont chez nous. L’indexation et le search se fait par un simple appel d’API. On fournit tous les aspects qui vont autour d’un moteur de recherche comme la personnalisation, l’analytique, le tracking des clics, comment on améliore le search….

On ne fournit pas juste la techno mais bien toute l’expérience de search du développeur, y compris la documentation qui prend énormément de temps.

Comme Apple s’est focalisé sur l’expérience utilisateur, on l’a fait pour l’expérience de search pour le dev. J’insiste sur le focus dev pour qui il existait 2 solutions extrêmes. D’abord Elastic Search qui nécessite de comprendre les internals, voir le code source et d’un autre côté des solution très packagées que les devs n’aiment pas parce que ce sont des boîtes noires. On est entre les deux : on peut avoir une solution qui tourne en quelques minutes et aussi aller très loin pour tuner le moteur en étant entièrement transparent sur la manière dont cela fonctionne.

 

« Sémantique c’est un grand mot, un peut comme IA »

 

En terme d’implémentation, quels ont été vos choix ?

On a pris des partis forts dès le début : la performance est clé. En 2012 beaucoup pensaient que la performance n’était plus vraiment un sujet avec les évolutions et améliorations du hardware. Nous avons pris le pari inverse et notre MVP était très bas niveau, entièrement axé sur la perf. On voulait prouver qu’en développant tout en C et C++ on gagnait en valeur pour le end-user.

Vous avez tout re-développé from scratch ?

Notre premier produit fait pour le mobile nous avait forcés à partir from scratch car les contraintes hardware nous l’imposaient : on ne pouvait pas partir d’un framework ou d’une solution élaborée pour un serveur. A l’époque on l’avait développé en C pour iOS, Android et Windows Phone exposé avec des bindings de haut niveau. Ce premier produit a été un succès tech mais pas en terme de marché.

On a gardé la tech qui marchait bien et on l’a appliqué au marché bien plus gros des hosted APIs.

Toutes les contraintes que l’on a eues sur mobiles ont été un avantage sur serveur : c’est bien la perf qui a fait notre succès et qui a convaincu nos premiers clients.

Aujourd’hui, êtes-vous toujours sur les mêmes techno, C et C++ uniquement ?

Notre moteur est toujours très bas niveau et notre code est embarqué directement sur Nginx. Quand la requête arrive elle est traitée directement sans sortir du process : on optimise dans un ordre de grandeur de la milliseconde. On va même tuner le kernel.

A côté des APIs de search on utilise plein de technos. Par-exemple : pour l’analytics on récupère et analyse tous les API calls en Go, notre dashboard est développé en ruby on rails, notre monitoring est codé en scala et utilise la solution SaaS Wavefront, …

Comment la donnée est-elle chargée ? Quelles sont les interactions ?

On a une API d’indexation : le client peut indexer la data en batch et envoyer tous les records ou le faire en incrémental chaque fois qu’une donnée change pour un usage plus orienté temps réel. Notre structure de donnée est un format binaire propriétaire. Notre seule dépendance est la libc du système et nginx. On re-développe la structure de données ainsi que la manière d’indexer et de faire des requêtes pour avoir ce gros différenciateur sur la performance, renforcé par l’utilisation de machines bare metal. A l’époque on utilisait des CPU haute fréquence qui n’étaient pas du tout disponibles chez les cloud providers et on commence à faire un peu de HPC aujourd’hui. On a 400 clusters de 3 machines minimum à travers le monde qui hébergent un ou plusieurs clients selon leur taille ou la volonté de celui-ci. Depuis on a ajouté beaucoup de fonctionnalités comme l’API d’analytics et de monitoring. Le dashboard utilisateur est développé en Ruby On Rails et hébergé chez AWS.

Est-ce que vous avez mis à profit certains des brevets que tu avais déposés ?

Pas du tout car les technologies évoluent trop vite. A l’époque d’Exalead, c’était le début du « as you type » et on pensait que c’était du gadget alors que c’est ce que tout le monde attend aujourd’hui. Aujourd’hui le search part vers la voix et on investit beaucoup pour faire évoluer le produit en ce sens.

« Nous sommes très transparents sur notre fonctionnement »

Tu penses au “Speech To Text” ?

On prend la requête après la conversion en Speech to Text mais par contre la recherche sera très différente : à l’écrit on fonctionne beaucoup par keyword alors qu’à la voix ce sont des phrases avec des verbes conjugués et des petits mots qui peuvent changer complètement le sens de la phrase. L’utilisateur a été éduqué pour s’adapter à la techno et utilise des mots-clés alors qu’à la voix on interagit de manière naturelle et c’est la techno qui doit s’adapter à l’utilisateur.

Faites-vous de l’analyse sémantique ?

Sémantique c’est un grand mot, un peut comme IA : qu’est-ce qu’on met derrière ce terme finalement ? On a effectivement un module qui permet d’analyser la requête avec un moteur de règles par-exemple. Un dev peut utiliser un algo de machine learning, générer un set de règles qui va définir comment j’interprète mes requêtes. Ainsi l’utilisateur tape « je recherche un jean de couleur rouge » : le rouge va être interprété en filtre plutôt qu’en requête full texte. C’est encore différent de la détection d’intention qu’on peut retrouver dans les bots par-exemple, où l’on ne recherche pas d’information dans une base de connaissance mais bien à comprendre ce que cherche à faire l’utilisateur.

SI je reviens à votre cœur de métier et notamment le fait d’avoir une latence très faible pour obtenir un résultat de recherche, quels concepts avez-vous choisi de mettre en œuvre ? Du cache par-exemple ?

Nous sommes très transparents sur notre fonctionnement et avons publié pas mal d’articles là dessus. De manière générale il y a une grande diversité dans les requêtes sauf sur certains use cases précis. Par-exemple pour nos utilisateurs de Twitch on remarque que la même requête arrive massivement au même moment pour des raisons sociales et ça ferait sens de la cacher mais on ne le fait pas encore. Par-contre dans les structures de données on a du cache persisté : on stocke des pré-calculs qu’on met en place à l’indexation, notamment des préfixes puisqu’on fait du real-time. Par exemple si l’utilisateur tape la lettre ‘A’ et qu’il faut faire le calcul de tout ce qui commence par ‘A’ c’est beaucoup trop coûteux donc on utilise des données pré-calculé à l’indexation pour cela. On maintient la cohérence des caches pré-calculés de manière incrémentale, chaque fois que la donnée change ce qui n’est pas très coûteux.

Tu peux faire des modifications en même temps que de la lecture, comment maintenez-vous la cohérence du système ?

Comme sur tous les systèmes distribués on a des compromis à faire : on est eventually consistent c’est à dire que toutes nos machines replicas peuvent avoir un état différent de la donnée à un instant T et on privilégie la performance. Une des grosses raisons de ce choix de design c’est la scalabilité des écritures et la volonté de distribuer le search à l’international. Nous disposons de 16 régions et lorsqu’un job d’indexation se présente, on le duplique proactivement sur celles-ci. Ce n’est pas comme un CDN où une requête déclenche un fetch qui recharge la donnée source. Pour un client donné comme Twitch, on a un consensus de 3 machines dans une région “principale”, qui va prendre un job d’indexation en lui donnant une séquence d’entier unique et une manière unique d’exécuter les jobs. Puis on réplique les jobs de manière asynchrone partout. Ainsi, si une région a une bande passante moins importante ou si la latence explose, elle sera en retard mais continuera d’indexer jusqu’à ce qu’elle arrive au même résultat.

« On fait partie de ceux qui ont poussé le SLA le plus fort : 99,999% »

Quel composant de votre architecture a la responsabilité de répliquer le job d’indexation ?

Le serveur d’API est hosté sur les 3 machines du cluster principal, dans la même région, sur des datacenters différent et des autonomous systems différents. Le client fait un appel d’API d’indexation sur l’une des 3 machines, on lui ACK un identifiant. L’iD est stocké et traité sur les 3 machines localement. De manière asynchrone, on réplique le job sur les autres régions en passant par des API internes, en crypté sur TCP. On considère que tous les réseaux sont unsecure donc on crypte tous les échanges.

Tu communiques directement par APIs entre les serveurs des différentes régions sans bus de messages intermédiaire ? Comment gères-tu les ruptures de communication ?

On persiste les jobs à effectuer sous la forme de fichiers sur les serveurs principaux. Il y a un fichier par job. Une fois les jobs acquittés sur les régions “replica”, ils sont supprimés.

Pourquoi avoir recréee ce système et ne pas avoir utilisé des technos existantes pour cela ?

La raison c’est le scaling international. On est dans un contexte où l’on a un besoin double : de la réplication locale dans un datacenter avec une latence faible et aussi de réplication asynchrone dans des régions avec des latences potentiellement élevées. On n’a pas trouvé de solution technique déjà existante pour répondre à cela. Ce système scale très bien et utiliser un mécanisme de messaging intermédiaire et autonome introduirait un Single Point Of Failure (SPFO) qui fait qu’en cas de souci, tout tombe. Dans notre cas, on peut avoir des failures mais ça n’impacte qu’une petite partie de nos utilisateurs. On fait partie de ceux qui ont poussé le SLA le plus fort : 99,999% c’est-à-dire 30 secondes de downtime maximum dans le mois. Pour 1 minute de panne on rembourse 1000 minutes et pour 4h c’est 5 mois ce qui représente un engagement très fort de notre part. Pour les traitements à froid comme l’analytics, on revient à des systèmes plus standards car c’est moins critique.

« Dans le search il y a 2 écoles dont ceux qui pensent que le machine learning va faire toute la pertinence et que tout sera automatique. Personnellement je n’y crois pas »

Sur quelles technos reposez-vous pour la partie analytique et traitement à froid ?

On est entièrement sur GCP et les services PubSub, Dataflow, BigTable et Citus qui est un postgreSQL shardé.

Utilisez-vous Hadoop/Spark ? Un datalake ? Du schema-less ?

Pas trop. On reste sur des données structurées. On traite 160 milliards d’API calls par mois et garder tout cela a un coût. Il y a aussi toutes les problématiques de GDPR et on est assez paranos côté privacy. On a plutôt tendance à traiter la donnée, faire les calculs de stat nécessaires et la détruire dans la foulée, à part une toute petite période de conservation qui nous permet d’assurer la qualité de service.

C’est pourtant assez à la mode aujourd’hui de conserver la donnée pour pouvoir l’exploiter et la croiser plus tard pour des scénarios d’usage à venir ?

Avec la privacy ce n’est pas le sens de l’histoire. Il vaut mieux faire un traitement smart de la donnée sur une durée de rétention courte, plutôt que la garder des années.

La donnée historique peut aussi servir à entraîner des modèles prédictifs ?

Dans le search il y a 2 écoles dont ceux qui pensent que le machine learning va faire toute la pertinence et que tout sera automatique. Personnellement je n’y crois pas et je ne le vois pas venir car il y a encore beaucoup de spécifique, de manuel, de campagnes de merchandising et l’humain qui intervient dans les moteurs de recherche.

Par contre il y a des endroits où l’on peut vraiment mettre en oeuvre du Machine Learning. Je pense à la configuration du moteur qu’il est très compliqué de configurer de manière parfaite. On sait extraire tous les metadatas de la configuration et les croiser avec ceux de la performance. Avec près de 5000 users en production, on peut corréler et proposer proactivement une amélioration des settings. Gagner en pertinence de cette manière là, c’est déjà une valeur énorme sur le marché. C’est aussi pour cela qu’on a développé des fonctionnalités d’A/B testing.

Certains de vos développements sont-il disponibles en open source ?

Tout le moteur est close source car cela demande beaucoup d’énergie de gérer une communauté open source et donc une perte de focus énorme pour nous. Néanmoins on explique ouvertement et publiquement tout le fonctionnement, il n’y a aucun secret autour de cela. C’est notre soft qu’on opère et pas un soft qu’on explique comment opérer : c’est une différence énorme. Par exemple le monitoring est complètement built-in dans le soft : il est fait pour notre plateforme de monitoring. Tout ce qui est autour du moteur est open source en licence MIT qui est très libératoire : les APIs clientes, les intégrations avec Magento, Shopify, Zendesk, … Pour les devs, c’est important d’avoir la big picture du fonctionnement de ce qu’ils intègrent dans leur code.

Peux-tu m’en dire plus sur l’infrastructure qui supporte votre moteur ? Conteneurs ou pas ? Les outils de déploiement ?

On n’a pas de conteneurs et pas de virtualisation. On utilise Chef côté automation donc toutes les machines sont déployées avec exactement la même config, le même hardware, les mêmes images et le même soft d’automation.

Côté déploiement  on a un mix entre une approche classique et custom : on est basé sur un CDN car on a beaucoup de machines et les pushs des binaires représentent des Go de trafic. Les CDNs nous permettent de le faire dans un temps réaliste. Notre binaire est directement dans nginx et on utilise leur mécanisme d’update de binaire : nginx se suicide une fois que les requêtes en cours sont traitées et c’est le nouveau process qui prend la suite. Un mécanisme automatique de détection d’erreur permet de faire un rollback en cas de souci.

C’est assez simple en fait : on a 3 process sur la machine : Nginx, Redis, et notre builder.

Nginx reçoit les calls d’APIs, Redis contient les 1000 derniers logs et des rate limits.

Combien d’environnements gérez-vous ?

Un environnement de build et de test automatiques (unitaires et fonctionnels), un environnement interne qui nous permet de jouer avec le produit, un environnement pour des sites communautaires comme HackerNews avec plus de latitude. Dans tous les cas on ne déploie jamais sur les 3 machines du cluster en même temps mais à quelques jours d’intervalle car on n’est jamais à l’abri des bugs. Cela nous est arrivé à une époque où l’on déployait comme des cow-boys sur toutes les machines : on a eu un downtime de 8 minutes, sachant qu’à l’époque on n’avait pas de rollback automatique.

« On ne fait aucun compromis sur la culture que l’on valide en entretien »

Comment gères-tu la cohérence des interfaces et des formats puisque plusieurs versions peuvent co-exister ?

On a toujours un déploiement en plusieurs étapes. Imaginons que l’on change le format d’un binaire : on envoie d’abord le code qui sait lire le nouveau format, partout à l’international. Si tout va bien, au déploiement suivant, on active un feature flag qui déclenche les écritures au nouveau format. Donc pour changer un format binaire cela ne se fait pas en 1 jour !

Du coup tu fais une upgrade des fichiers cibles ou tu gardes les 2 versions ?

On a de la backward compatibility : nos binaires savent lire les vieilles versions mais de temps en temps on force à re-générer toutes les structures pour éviter de laisser trop grossir notre base de code.

Comment fonctionnez-vous en terme d’équipe, de collaboration et de process ?

On fonctionne en squad c’est-à-dire des équipes par expertise technique : le dashboard, l’API de search, l’analytics, l’intégration e-commerce…

Nous avons des profils devops, SRE avec une petite particularité : les équipes sont responsables et on-call 24×7 sur leur produit donc on a fait un gros investissement sur le monitoring de la production.

Nos 230 employés sont répartis sur 5 bureaux dans le monde sachant que 99% de l’engineering est à Paris. Nous sommes multi-culturels avec une vingtaine de nationalités dans le bureau. On parle uniquement en Anglais pour être inclusifs et faciliter l’intégration de tous.

Comment recrutez-vous ?

Nous avons une équipe de recrutement interne. C’est le jour et la nuit avec un recruteur externe en terme de qualité car ils ne connaissent que très partiellement la société. On ne fait aucun compromis sur la culture que l’on valide en entretien.

Vos enjeux tech majeurs ?

Nos challenges technique portent notamment sur la voix ou encore la détection des intentions. L’état de l’art est balbutiant et il y a d’énormes opportunités car personne n’a encore craqué le modèle. Je pense aussi au conversational search qui n’existe pas aujourd’hui. Dans le voice search, tout se fait à la voix donc on recherche complètement différemment et il n’existe rien à ce jour alors que le marché va dans ce sens.

Que considères-tu comme le plus compliqué à gérer pour toi aujourd’hui ?

A notre stade, c’est de ne pas ralentir notre vitesse d’exécution et d’innovation tout en ayant une équipe qui grossit. Notre organisation n’est peut-être pas la meilleure pour scaler.

Et me concernant c’est de trouver comment faire le meilleur usage de mon temps : quels sont les sujets sur les lesquels j’ai plus intérêt à m’impliquer, où ai-je le plus de valeur et où mettre le curseur ? Je ne code plus et ça ne me pose aucun souci : je suis plus attaché au résultat et au fait qu’on s’améliore dans le temps.

Un fail à partager ?

J’en ai plein…mais le plus gros c’est quand on a introduit la high availability du DNS fin 2014. Notre infra est pensée haute dispo mais on avait un seul fournisseur de DNS qui est hosté ce qui est un gros SPOF. Evidemment on avait fait des tests manuels et automatiques avant de faire la bascule le jour J quand j’ai moi-même appuyé sur le bouton. Cela ne s’est pas passé comme prévu pour une raison qu’on n’avait pas anticipé : nos clients qui utilisaient IPv6. Sur ce point nos fournisseurs DNS avaient un comportement différent. On a eu l’idée « géniale » de faire un rollback et on est entré dans cycle infernal car on ne l’avait jamais testé ! On a vécu un enfer entre les caches DNS ou les providers comme free qui ne respecte pas les standards avec des TTL d’1h. Ca a duré 24h avec des pannes intermittentes et on a été obligés de donner à nos clients un workaround à mettre dans leur code. On a tout un post mortem là-dessus et on a aussi partagé un document avec nos failures dont celle-ci.

Comment te vois-tu dans 5 ans, 10 ans ?

Toujours chez Algolia qui serait devenue publique, cotée en bourse avec un quotidien qui n’aurait rien à voir avec celui que je vis aujourd’hui. De toute manière, ça change déjà tous les 6 mois pour moi : j’apprécie d’avoir l’occasion de me renouveler en permanence.

De quelle startup souhaiterais-tu découvrir l’architecture et les dessous techniques ?

Sqreen.io qui est une startup focalisée sur la sécurité et qui s’installe sur des stacks essentiellement Ruby On Rails. Ils ont des sujets autour de la volumétrie et la performance.

Payfit qui a des challenges de confidentialité et de scalabilité. Ils commencent aussi leur move multi-produit très tôt : je suis curieux de savoir comment ils vont gérer cela.

BlaBlaCar qui était assez monolithique au départ, a beaucoup grossi et complètement ré-architecturé sa solution. A une époque ils ont fait pas mal de développement custom pour leurs besoins de type Chef : je me demande s’ils ont continué à réinventer d’autres choses ou s’ils sont restés plus raisonnables…

Les commentaires sont fermés.

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

Retour en haut ↑