Le Défi
Comment faire pour répondre aux besoins de recherche des 4 millions d'utilisateurs de GitHub tout en fournissant simultanément des indicateurs opérationnels et tactiques permettant d'améliorer de manière itérative le service client ?
La Solution
Utiliser Elasticsearch pour indexer plus de 8 millions de dépôts de code ainsi que des données sur les événements critiques.
L’essentiel du cas d’utilisation
Fournir une indexation pratiquement en temps réel dès qu'un utilisateur charge de nouvelles données
- Se développer pour répondre aux besoins d'une base d'utilisateurs en pleine expansion, en migrant d'Apache Solr vers Elasticsearch
- Indexer et interroger pratiquement tous types de données accessibles publiquement
- Permettre des recherches programmatiques plus poussées pour les applications de développeurs
Exploiter les statistiques sur les données de recherche
- Démasquer les utilisateurs malveillants en interrogeant les données indexées de logging
- Déceler les bugs logiciels au sein de la plateforme GitHub en indexant la totalité des alertes, événements, logs et en surveillant la fréquence de certaines exceptions de code
- Effectuer des requêtes allant au-delà d'un SQL standard
Une recherche sophistiquée pour des utilisateurs sophistiqués
Elasticsearch permet d'exécuter des recherches sur GitHub, le plus grand système hébergé de gestion de versions au monde, fort d'une base client comportant plus de 4 millions d'utilisateurs techniques. GitHub fait appel à Elasticsearch pour indexer en continu les données d'un catalogue en pleine expansion, constitué de plus de 8 millions de dépôts de code et comportant plus de 2 milliards de documents. Grâce à Elasticsearch, GitHub est en mesure de permettre à ses utilisateurs de réaliser facilement des recherches au sein de ces données.
« La fonction de recherche est l'âme de GitHub, » explique Tim Pease, ingénieur d'exploitation chez GitHub. « En vous rendant sur GitHub.com/search, vous pouvez rechercher parmi des dépôts, des utilisateurs, des problèmes, des requêtes Pull et des codes source. »
L'un des objectifs de l'implémentation Elasticsearch de GitHub est d'indexer tout ce qui est disponible publiquement sur GitHub. com et de rendre ce contenu plus facile à trouver. Bien entendu, les recherches en texte intégral sont totalement prises en charge, mais il est également possible d'effectuer des recherches à partir de toutes sortes de critères, et ce en toute simplicité.
« Vous pouvez par exemple rechercher un projet qui utilise Clojure comme langage principal et qui a fait preuve d'activité au cours du dernier mois, et toutes ces fonctionnalités seront exécutées par Elasticsearch, » déclare M. Pease.
Le stockage flexible et les différents formats d'extraction d'Elasticsearch, qui permettent à la fois à des données extrêmement structurées ou très peu structurées de coexister au sein du même stockage de recherche, ainsi que le grand choix de primitives de recherche offertes par Elasticsearch, ont grandement facilité l'implémentation des recherches.
« Avec Elasticsearch, il est possible de lancer énormément de requêtes sur ces données qui ne seraient pas prises en charge par une base de données SQL standard, » souligne M. Pease.
Prendre en charge des indicateurs analytiques au-delà du pare-feu
GitHub utilise les capacités combinées d'Elasticsearch à indexer les recherches et à analyser les données pour exécuter de nombreux projets. Par exemple, GitHub s'est servi des capacités analytiques des requêtes d'Elasticsearch sur des données stockées d'audit et de logging afin de surveiller les activités des utilisateurs en termes de sécurité.
« Avec les requêtes d'Elasticsearch, il nous est possible d'obtenir rapidement un aperçu de toutes les actions réalisées par un utilisateur, » explique M. Pease. « C'est un moyen très pratique de vérifier si un compte a été usurpé ou piraté, ou bien si l'utilisateur s'en est servi à des fins malveillantes. »
Alors que GitHub cherchait un moyen de suivre et d'analyser les exceptions de code générées par les divers éléments logiciels qui alimentent GitHub.com, une base de données NoSQL populaire a été utilisée à l'origine. Les exceptions de code étaient stockées dans des indexes secondaires, et ses fonctionnalités analytiques étaient utilisées pour analyser les exceptions passées. Les résultats étaient ensuite également stockés dans la base de données.
« Pour nos cas d'utilisation, cela n'a pas très bien fonctionné, » se remémore Grant Rodgers, membre de l'équipe technique de GitHub. « Une fois que nous avons migré sous Elasticsearch et commencé à utiliser les recherches à facette d'histogramme, tout s'est arrangé. »
GitHub fait appel à la capacité de recherche à facette d'histogramme d'Elasticsearch, ainsi qu'aux autres facettes statistiques, pour surveiller les augmentations de fréquence de certains types d'exceptions de code. Ce procédé permet de révéler des bugs dans les systèmes logiciels. « La capacité de recherche à facette d'histogramme d'Elasticsearch est extrêmement performante. Nous cherchons à développer son utilisation pour cette application en particulier, » explique M. Rodgers
« Avec les requêtes d'Elasticsearch, il nous est possible d'obtenir rapidement un aperçu de toutes les actions réalisées par un uti-lisateur. C'est un moyen très pratique de vérifier si un compte a été usurpé ou piraté, ou bien si l'utilisateur s'en est servi à des fins malveillantes. »
Adaptabilité pour des millions d'utilisateurs
GitHub a commencé par utiliser Solr pour ses recherches, mais l'entreprise s'est aperçue que cette solution n'était pas aussi évolutive et se gérait bien moins facilement.
« Au fur et à mesure de l'augmentation du nombre d'utilisateurs de GitHub, nous avons rapidement dépassé le volume de stockage pouvant être géré par un cluster Solr et une instance Solr, » explique M. Pease.
Il est donc devenu nécessaire de choisir entre découper ses propres données sous Solr, afin de permettre la gestion de cette charge, ou migrer sous Elasticsearch. Le choix a été vite fait. « Nous avons décidé de passer à Elasticsearch, car nous avons pensé que cette solution permettrait un bien meilleur découpage des données, » poursuit M. Pease.
Elasticsearch offre un rééquilibrage automatique des shards afin d'améliorer ses performances et de gérer les conditions de basculement automatique. Les répliques des shards sont automatiquement distribuées sur de nouveaux nœuds au sein d'un cluster, et en cas de dysfonctionnement au niveau d'un nœud, les shards sont automatiquement déplacés depuis les nœuds défectueux vers des nœuds fonctionnels.
Un sharding avancé pour des performances optimales
Pour l'équipe GitHub, avec plus de 2 milliards de documents tous indexés par Elasticsearch, sans oublier des utilisateurs qui chargent et modifient du code en permanence, les performances de recherche sont essentielles. GitHub dessert en moyenne 300 requêtes de recherche chaque minute.
GitHub fait appel à Elasticsearch pour indexer le nouveau code dès que les utilisateurs le placent dans un dépôt sur GitHub. Il est possible d'effectuer une recherche parmi ces données peu de temps après, et les résultats de recherche sont renvoyés à la fois vers des dépôts publics et vers des dépôts privés auxquels peuvent accéder les utilisateurs connectés.
Afin d'optimiser l'accès aux données de recherche, GitHub utilise fréquemment le sharding. Le cluster Elasticsearch principal de GitHub comporte environ 128 shards, chacun ayant une capacité de stockage d'environ 120 gigaoctets.
Afin d'optimiser les recherches au sein d'un dépôt unique, GitHub fait appel au paramètre de routage d'Elasticsearch sur la base de l'identifiant du dépôt. « Cela nous permet de mettre tout le code source pour un dépôt unique dans un seul shard, » explique M. Pease. « Si vous êtes sur une seule page de dépôt, et si vous y faites une recherche, elle ne concernera en fait qu'un seul shard. Ces requêtes sont environ deux fois plus rapides que les recherches effectuées à partir de la page de recherche principale de GitHub. »
