Google Search, le moteur de recherche le plus utilisé au monde, repose sur une infrastructure complexe et des environnements de développement sur mesure. Nous vous proposons de découvrir ces systèmes aux noms parfois explicites, souvent fantaisistes, en s’appuyant sur des informations provenant de diverses sources, le leak de l’API Content Warehouse bien sûr, mais aussi les pièces à conviction des procès antitrust, des présentations publiques d’ingénieurs Google ou des témoignages d’anciens employés (CV, profils LinkedIn, blogs, forums HackerNews, etc.).
Disclaimer : Nous n’avons donc pas bénéficié d’informations d’insiders pour réaliser cet article. Ne prenez pas pour argent comptant tout ce qui est écrit ici. Nous avons sûrement fait de nombreuses approximations et interprétations de notre compréhension du fonctionnement de Google. Tout ce qui n’est pas clairement documenté et recoupé par des sources est potentiellement faux.
L’environnement de développement Google
Softwares et logiciels internes
Parmi les premiers outils que l’on s’attendait à retrouver dans le leak, on a bien sûr le version control system (VCS) maison de Google, Piper, que l’on pourrait comparer à Git. On trouve également quelques mentions de l’outil de production utilisé en interne : Blaze, rendu open source en 2015 sous le nom de Bazel – mais aucune trace du système de test, Forge. On trouve également quelques traces de l’outil de production de la team SRE (Site Reliability Engineering) : Boq et son système de nodes – voir ci-dessous un exemple d’exploitation pour les Complexe Queries Rewrite (réécriture des requêtes complexes) :
Côté langages, bien que Google soit connu pour avoir développé le Go, le C++ reste prédominant. On trouve aussi un peu de Java et, dans une moindre mesure, du Python. Les fichiers les plus couramment rencontrés ont les extensions suivantes :
- .cc et .h pour le C++
- .java pour Java
- .proto pour les Protocol Buffers (protobuf)
Les services de Google communiquent via une infrastructure d’appel de procédure à distance (RPC – Remote Procedure Call) nommée Stubby, dont il existe là aussi une version open source, gRPC.
Les données sont encodées et transférées entre les différents systèmes du moteur via des « protocol buffers » (protobuf), une techno développée par Google supposée plus efficaces que JSON : plus simples, plus petits, plus rapides et moins ambigus.
Côté softwares qui s’occupent du “management des machines”, stockage et bases de données, aucune mention de Colossus, mais on a bien des occurrences de Spanner, Bigtable, SSTable, Blobstore, Borg ou Chubby qui travaillent de pair avec Colossus. Pour rappel Colossus est un système de fichiers au niveau du cluster, successeur du Google File System (GFS).
Percolator est également absent du leak (et à fortiori Caffeine). On trouve quelques mentions de MapReduced bien que Google ait annoncé l’avoir remplacé par Dataflow – avec l’aide de Flume et Millwheel que l’on ne trouve pas non plus dans l’API du Leak.
Le Monorepo Google3
Au cœur de l’environnement de développement de Google se trouve un concept clé : le monorepo, un repository qui héberge le code de la majorité des produits Google (sauf Chrome et Android qui sont gérés à part). On trouve dans ce dépôt de code source le moteur de recherche, Youtube, Map, Assistant, Lens… Son nom interne est Google3 et presque tous les ingénieurs de Google y ont accès. Cette approche, bien que non conventionnelle pour une entreprise de cette taille, présente plusieurs avantages :
- Facilité de collaboration entre équipes
- Uniformité des outils et des processus
- Possibilité de refactoriser à grande échelle
Seul un faible pourcentage du code (environ 0,1%) est isolé pour des raisons de confidentialité, principalement ce qui concerne la lutte anti-spam. La petite partie réservée à quelques équipes serait appelée HIP pour “High-value Intellectual Property”, c’est là que l’on devrait trouver par exemple le code de Nsr ou de PageRankNS.
Le nombre de références au repository est important dans le leak, et permet de mieux comprendre à la fois la structure globale du code et donne des indices sur l’appartenance de tel ou tel composant à un environnement spécifique.
Nous avons extrait et compilé du leak Google la branche qualité du monorepo google3 :
Et voici un échantillon de ce qu’on peut trouve dans les autres branches :
Les bonnes pratiques internes imposent de documenter le code dans le wiki maison accessible via les liens go/xxx que l’on retrouve également en nombre dans le leak. Malheureusement, pour pouvoir y accéder, il faut être ingénieur chez Google ^^
En 2015, le monorepo Google3 pesait déjà 86TB pour deux milliards de lignes de code, avec un graphe de dépendances extrêmement complexe. Les 25 000 ingénieurs du groupe réalisaient 40 000 commits par jour ! Si vous souhaitez creuser cette partie nous vous recommandons fortement la lecture de ce document : Why Google Stores Billions of Lines of Code in a Single Repository (PDF)
Autant dire que le leak auquel nous avons accès ne représente qu’une infime partie du code Google… Mais cela reste vraiment exclusif de voir cette petite fenêtre ouverte sur la structure de ce repository.
Intéressons-nous maintenant aux nombreux autres systèmes découverts grâce au Google leak de mai 2024 qui permettent au moteur de délivrer ses fameuses pages de résultats. Nous allons partir de la phase de crawl pour arriver à la requête utilisateur, en passant par les principaux systèmes intermédiaires.
Les systèmes de Google Search en une infographie
Plusieurs propositions de schématisation de l’infrastructure de Google Search ont déjà été réalisées par des SEO, dont deux particulièrement travaillées :
Une première publiée par Mario Fischer sur Search Engine Land
Une seconde publiée par Natzir Turrado sur son site personnel
Nous vous proposons une nouvelle représentation, cette fois organisée en deux parties :
- En partie haute : ce qui est mis en œuvre off line (crawl time) notamment tout ce qui concerne la découverte, extraction, parsing, annotation et indexation de la donnée.
- En partie basse : ce qui est activé au moment de la requête (query time), particulièrement l’interprétation de la requête, la génération de la page de résultats, et l’analyse du comportement des utilisateurs à des fins de reranking et d’entrainement.
- Entre les deux se trouvent les mecanismes de « merging / information retrieval » qui font la jonction entre d’une part les données agrégées au niveau de l’indexation et d’autre part la phase de serving déclenchée à chaque requête utilisateur.
Notez que nous avons exclu de ce schéma les dispositifs concernant Youtube, Assistant, Map, Lens, etc. pour ne garder que le Search, par soucis de simplification. Vous pouvez cliquer sur une partie du schéma afin d’acéder directement à l’explication correspondante.