GitHub a transféré sur Azure des copies de 99,99999 % de ses dépôts, tout en conservant des copies dans ses propres centres de données. Les dépôts restants comptent parmi les plus sollicités de la plateforme, et la latence réseau entre régions a rendu leur migration difficile. L’entreprise indique qu’une modification de la façon dont elle coordonne les écritures permettra de les transférer et accompagnera l’évolution vers une infrastructure conçue pour répondre au trafic croissant des développeurs et des agents d’IA.
La migration a débuté en août 2025, avec l’arrivée d’une copie d’un dépôt dans la région Central US d’Azure. La plupart des dépôts ont désormais deux de leurs cinq réplicas sur Azure, qui traite environ la moitié du trafic Git. GitHub a choisi de déplacer les données avant de modifier son architecture de stockage, en invoquant l’importance des opérations Git et les risques liés au changement simultané de la plateforme d’hébergement et de l’architecture.
Dans la conception actuelle, un quorum d’écriture attend la réponse de chaque réplica opérationnel, alors qu’une majorité suffit pour valider une écriture. Comme un verrou à l’échelle du dépôt reste en place jusqu’à la fin de l’écriture, le réplica le plus lent peut limiter à la fois la latence et le débit. Les réplicas Azure se trouvant à environ 1 000 miles des centres de données de GitHub, un aller-retour réseau prend environ 25 millisecondes, et les écritures nécessitent plusieurs allers-retours.
La modification proposée par GitHub consiste à coordonner les écritures par référence plutôt qu’à l’échelle de tout un dépôt. Les références incluent les pointeurs de branche, et l’entreprise affirme que les mises à jour de références différentes ne dépendent généralement pas les unes des autres. Avec la nouvelle approche, les écritures portant sur une même référence continuent de s’attendre mutuellement, tandis que celles visant des références distinctes peuvent se dérouler en parallèle. Lors de tests internes utilisant un trafic réaliste, GitHub fait état d’un débit d’écriture 3 à 4 fois supérieur pour les écritures visant des références différentes, avec une latence moindre.
Cette modification permet également de faire évoluer les lectures séparément. GitHub indique que les dépôts reçoivent généralement entre 100 et 1 000 lectures pour chaque écriture, mais qu’actuellement, les deux types de trafic utilisent les mêmes réplicas et se disputent les ressources. La prochaine étape consiste à intégrer Azure Blob Storage au quorum d’écriture par le biais d’un « réplica virtuel ». Ce nœud éphémère transmet en continu les écritures entrantes vers le stockage objet, et une écriture n’est confirmée qu’une fois qu’elle y est durablement enregistrée.
Le réplica virtuel d’écriture ne sert pas les lectures. À la place, GitHub peut créer des réplicas virtuels de lecture à la demande, réchauffer leurs caches à partir de Blob Storage et traiter le trafic de lecture sans les intégrer au quorum. Lors de tests de charge internes, GitHub indique que son système de test a atteint ses propres limites avant de trouver le plafond de ces réplicas. L’entreprise précise que la réconciliation en arrière-plan ne convient peut-être pas à toutes les charges de lecture et que d’autres améliorations sont nécessaires pour accroître le débit d’écriture au-delà des limites du quorum.
GitHub indique que le prochain défi consiste à ordonner le petit volume de données de dépôt qui nécessite une coordination, tout en stockant les objets Git immuables sans exiger d’accord entre les réplicas. L’entreprise prévoit de présenter l’architecture cible envisagée dans un prochain article et lors de GitHub Universe.
Sources: GitHub Blog.