La plateforme GitHub fait face à une croissance sans précédent de l'intensité des opérations sur le système Git, stimulée par la propagation des logiciels et agents d'IA (AI Agents) qui génèrent des flux intenses et continus de modifications et de mises à jour. Pour faire face aux contraintes physiques de capacité énergétique dans les centres de données traditionnels et les chaînes d'approvisionnement, l'entreprise a dévoilé un plan architectural qui a permis jusqu'à présent de migrer des répliques de 99,99999 % de ses dépôts pour qu'ils soient hébergés conjointement entre ses propres centres de données et le nuage Microsoft Azure.
L'obstacle de la latence et du verrouillage complet du dépôt
GitHub a expliqué que les dépôts les plus utilisés et modifiés sur la plateforme — qui représentent le faible pourcentage restant (0,00001 %) — se heurtaient à un obstacle technique lié au temps de réponse du réseau. Lors du transfert de données vers la région Azure Central US, située à environ mille milles des centres de données de la plateforme, chaque connexion réseau ajoute un temps de latence d'environ 25 millisecondes pour un aller-retour.
Dans l'ancienne architecture du système de synchronisation et de consensus « Spokes », toute nouvelle opération d'écriture nécessitait l'application d'un verrouillage global à l'échelle de l'ensemble du dépôt (Repository-wide lock) jusqu'à ce que les répliques (Replicas) répondent. En raison de la détention du verrou global, la réplique réseau la plus lente déterminait le temps de réponse et le plafond maximal du débit de l'ensemble du dépôt, provoquant des goulots d'étranglement pour les dépôts actifs recevant des envois de code fréquents de la part des développeurs et des agents d'IA.
Le consensus basé sur les références individuelles
Pour surmonter ce goulot d'étranglement, GitHub a reformulé le mécanisme de consensus en appliquant son premier principe architectural : « Réduire la coordination et éliminer le verrouillage inutile ». Au lieu de verrouiller l'ensemble du dépôt lors d'une mise à jour, la portée du consensus et du verrouillage s'applique désormais exclusivement aux références individuelles (Per-reference serialization), telles que les branches (Branches) ou les étiquettes (Tags).
Comme la plupart des opérations d'écriture simultanées effectuées par les développeurs ou les agents d'IA ciblent des branches différentes, les modifications n'attendent plus les unes après les autres dans une seule file d'attente. Les tests internes réalisés par l'entreprise sous des charges réelles ont montré une augmentation de la capacité d'absorption des opérations d'écriture de 3 à 4 fois, avec une réduction notable de la latence.
Découplage du stockage et du calcul et généralisation du stockage d'objets
La seconde phase comprend l'application du deuxième principe architectural : « Découplage du stockage et des capacités de calcul » (Decoupling storage from compute). La plupart des dépôts Git se caractérisent par une forte densité d'opérations de lecture par rapport à l'écriture, avec un ratio allant de 100 à 1 000 opérations de lecture pour une seule opération d'écriture. Dans l'ancienne architecture, la lecture et l'écriture se disputaient les mêmes ressources et la même mémoire.
Pour résoudre ce problème, GitHub a intégré le stockage d'objets (Azure Blob Storage) en tant que membre virtuel du conseil de consensus nommé « réplique d'écriture virtuelle » (Virtual Write Replica). Cette réplique agit comme une chaîne transitoire qui regroupe les transactions et achemine durablement les modifications vers le stockage dans le nuage. Une fois le stockage confirmé, la plateforme peut lancer un nombre illimité de répliques de lecture virtuelles (Virtual Read Replicas) extensibles à la demande, ces répliques mettant à jour leur mémoire cache en arrière-plan sans affecter la vitesse d'écriture des données ou la synchronisation.
Qu'est-ce qui change concrètement pour l'architecture du développement logiciel ?
Cette transformation d'ingénierie chez GitHub reflète la manière dont les systèmes distribués de grande envergure sont repensés pour supporter la nature du travail automatisé basé sur l'intelligence artificielle. Les principaux impacts pratiques peuvent être résumés comme suit :
- Augmentation du plafond de débit : Permettre aux agents d'IA et aux développeurs d'effectuer des envois simultanés intenses sans provoquer de verrouillage (Lock) sur les grands dépôts.
- Flexibilité de la mise à l'échelle de la lecture : Possibilité d'augmenter les serveurs de lecture et d'allouer leur mémoire cache de manière indépendante, sans devoir passer par des procédures de consensus lourdes.
- Pérennité du système de base : Mise à jour des composants internes du système « Spokes », qui exécute plus de 100 milliards d'opérations par jour, sans nécessiter d'interruption de service ni compromettre l'intégrité des données.