Cas Utilisateur

Comment Elasticsearch a permis à Orange de mettre en place leur moteur de recherche de sites Web

logo-orange.png

Jean-Pierre Paris assume le rôle de Tech Lead au sein du groupe Orange depuis 1996 (sauf pendant quatre ans, entre 2000 et 2004, période pendant laquelle il travaillait dans le domaine de l'analyse des données de trafic IP pour une start-up). En 2009, M. Paris a rejoint l'équipe française dédiée au moteur de recherche de sites Web pour le compte d'Orange. Depuis fin 2013, il travaille avec les produits Elastic, tout en s'attelant à une variété de tâches opérationnelles et de développement.

Un moteur de recherche de sites Web n'est pas une application monolithique. L'illustration ci-dessous présente les différents types de données qui contribuent à la création d'une page de réponses utile et attrayante, à l'aide entre autres d'une page d'actualités (a), d'une section « le saviez-vous » (b), de documents Web français (bleu) avec une sous-catégorie composée d'articles associés (rouge) (c), de vidéos (d), et du contenu viral (e). En plus de l'index de recherche Web, nous avons développé des « moteurs de recherche verticaux » spécifiques à chaque type de données, tels que la météo, les films récents ou les infos sportives. Chacun de ces moteurs verticaux travaille sur un corpus dédié dont la taille est bien inférieure à celle de la principale source française de documents sur le Web.

a)

b)

c)

d)

e)

Notre Histoire

Depuis ses débuts il y a plus de 15 ans, le moteur de recherche d’Orange a évolué en développant sa propre technologie ainsi qu'en intégrant  différents outils open source. En 2013, chaque moteur vertical était b asé sur des s olutions propriétaires ou l’une des version  du moteur de recherche Sphinx. En outre, chaque moteur de recherche vertical opérait à l'aide de son propre matériel et assurait sa redondance. Il s'agissait là d'une solution onéreuse difficile à gérer. Pire encore, tout déploiement d'un nouveau moteur de recherche vertical ou d'une nouvelle fonctionnalité était synonyme de complexité. Pour couronner le tout, la tâche de l'équipe chargée d'opérer ces moteurs devint de plus en plus complexe à cause de la variété de technologies utilisées  et du nombre de machines.  Après avoir fait l'expérience de cette complexité, nous avons réalisé qu'il nous fallait réduire le nombre de technologies et améliorer notre capacité à rapidement ajouter de nouvelles fonctionnalités.

Trouver un Nouveau Moteur de Recherche Universel Capable de Prendre en Charge Notre Plateforme de Recherche

La sélection d'une nouvelle technologie sur laquelle baser nos moteurs de recherche verticaux constituait un choix difficile mais important pour nous. Plusieurs de nos équipes ont développé les moteurs verticaux, et chacune d'entre elles a utilisé différentes technologies de recherche. Pour les encourager à passer à une solution différente, nous devions simplifier la migration et nous assurer que la technologie choisie puisse répondre aux nombreuses exigences techniques, telles qu'une grande disponibilité, un débit rapide et une latence faible.

Au cours de l'été 2013, nous avons évalué Elasticsearch et Solr. Notre choix s'est rapidement porté sur Elasticsearch, principalement grâce à son API fiable et complet, et au fait qu'il a été pensé, dès sa création, pour être, disons, élastique.

L'élasticité, c'est-à-dire la flexibilité horizontale, était l'une des exigences clés de notre migration. Même si le déploiement initial était prévu pour un moteur de recherche vertical unique, nous avions fait le choix d'une technologie à laquelle tous nos futurs moteurs de recherche verticaux, et toutes nos fonctionnalités, pourraient se rattacher. Ainsi, cette technologie se devait de pouvoir s'adapter pour prendre en charge de nouveaux moteurs verticaux, mais il fallait également qu'elle sache se développer avec notre base d'utilisateurs.

Le premier cluster Elasticsearch a été mis en ligne fin 2013, avec seulement 2 index et moins d'un million de documents. Aujourd'hui, nous avons 3 clusters : le plus gros d'entre eux regroupe 50 millions de documents sur 20 machines virtuelles (8 CPU, 20 Go de RAM et HDD de 100 Go). La taille primaire de ces index est de 150 Go, ce qui nous permet de traiter des centaines de demandes par seconde, avec une latence inférieure à 200 ms, tout en opérant sur des machines virtuelles plutôt que sur un équipement dédié.

L'interface Elasticsearch REST JSON a simplifié la migration de notre ancienne interface, puisque l'analyse syntaxique et les clients HTTP sont  aisés à développer dans presque toutes les langages. De plus, Elastic propose des bibliothèques de clients pour les principaux langages, simplifiant encore le développement de clients en masquant les interactions de bas niveau d’analyse syntaxique JSON et HTTP.

Grâce à ces bibliothèques simples, nos clients internes font désormais le choix d'Elasticsearch pour les moteurs verticaux. Puisque nous pouvons rapidement déployer les index et clusters Elasticsearch, la création de nouveaux moteurs de recherche verticaux, de nouvelles fonctionnalités et la gestion d'un plus grand nombre de données par nos équipes internes est largement facilitée.

Prenant en considération notre expérience à ce jour, nous sommes confiants de pouvoir opérer Elasticsearch dans un contexte exigeant. Nous nous reposons fortement sur Marvel, l'outil de suivi d'Elasticsearch, pour garder un oeil sur les clusters en service, avec un objectif d'indisponibilité nulle pour un cluster critique.

À ce jour, lorsque vous interrogez le moteur de recherche sur orange.fr, la plupart des résultats, qu'ils concernent les dernières infos sportives, un nouveau film ou les récentes éruptions volcaniques en Italie, proviennent des moteurs de recherche verticaux opérés par Elasticsearch.

Et après ?

Actuellement, nous testons Elasticsearch sur certains de nos outils internes.

Par exemple, nous sommes en cours de développement d'un outil capable d'analyser la lisibilité ou la « qualité » des 1,2 milliards d'URLs présents sur notre base de données Web française. Nous utilisons Kibana pour créer des tableaux de bord recueillant les informations relatives aux URLs pour un hôte ou un domaine spécifique (voir illustration ci-dessous).

Jean PierreNous pouvons ainsi rapidement déterminer si les URLs sont lisibles et juger la qualité générale du domaine ou de l'hôte. Nous utilisons également Logstash et Kibana pour tester l’aggrégation de logs pour notre cluster en production. Et je suis très impatient de découvrir Packetbeat qui me ramène plus de dix ans en arrière, lorsque je travaillais dans le domaine de l'analyse de trafic IP.Notre succès avec Elasticsearch nous pousse à expérimenter davantage les applications Elastic pour nos outils internes et sur des volumes bien supérieurs. Ainsi, j’espère que nous aurons de nouvelles histoires à raconter dans un avenir proche, lorsque certains outils seront en ligne. Donc, restez à l'écoute, prêts à entendre parler de nos dernières aventures avec Elasticsearch... (comme vous pouvez le voir, j'y travaille déjà :))