Contexte et contraintes

Depuis plus d’un an, le trafic Git de GitHub a connu une croissance exponentielle. Aujourd’hui, 99,99999 % des dépôts sont répliqués simultanément dans les data‑centers internes et dans Azure, tandis que les 0,00001 % restants restent critiques à cause d’un temps de trajet réseau d’environ 25 ms entre les deux sites. Chaque dépôt possède cinq répliques pour garantir durabilité et disponibilité. Le premier transfert vers Azure Central US a eu lieu en août 2025, et la moitié du trafic Git transite désormais depuis Azure.

Dans l’architecture précédente, le quorum de validation des écritures attendait la réponse de toutes les répliques saines, même si une majorité suffisait pour valider. Cette attente synchronisée imposait que le réplica le plus lent fixe la latence de chaque écriture, limitant ainsi le débit de poussées sur les dépôts déjà proches de leur plafond.

Réduction de la coordination par quorum par référence

Git impose la cohérence au niveau de chaque référence (branche, tag). En exploitant ce fait, GitHub a modifié la portée du quorum : au lieu de verrouiller l’ensemble du dépôt, le verrouillage s’applique désormais à chaque référence individuellement. Ainsi, les écritures qui ne partagent pas la même référence ne se bloquent plus mutuellement. Dans les tests internes, cette granularité a permis d’augmenter le débit d’écriture de 3 à 4 fois tout en réduisant la latence, car plusieurs écritures peuvent être en vol simultanément, chacune subissant le même round‑trip de 25 ms mais sans s’encombrer d’une file d’attente unique.

Réplique virtuelle et découplage stockage/compute

Le deuxième levier d’optimisation consiste à séparer le stockage persistant du calcul. Les objets Git sont désormais stockés de façon durable dans Azure Blob Storage. Un nouveau type de nœud, la réplique virtuelle d’écriture, agit comme un intermédiaire éphémère : il reçoit les écritures, les consigne dans le blob, puis confirme le quorum. Cette réplique ne sert aucune lecture, ce qui évite la compétition entre opérations de lecture et d’écriture sur les mêmes ressources matérielles.

En regroupant les transactions sur des références distinctes, la réplique virtuelle réalise un unique aller‑retour réseau pour plusieurs écritures simultanées, réduisant ainsi le nombre d’I/O vers le stockage. Le modèle actuel conserve entre 100 et 1 000 lectures pour chaque écriture, mais les lectures sont désormais dirigées vers des répliques dédiées, pouvant être dotées de caches en mémoire plus importants sans impacter les performances d’écriture.

Résultats et perspectives

Le passage au quorum par référence et l’introduction de la réplique virtuelle ont permis de dépasser le plafond de débit imposé par le réplica le plus lent, tout en maintenant la cohérence attendue par les clients Git. Les dépôts les plus actifs, qui étaient auparavant bloqués par le temps de trajet de 25 ms, peuvent maintenant être migrés intégralement vers Azure sans perte de performance. Cette approche ouvre également la voie à des répliques purement éphémères, capables de se créer et se détruire à la volée, ce qui pourrait réduire davantage la consommation d’énergie des data‑centers internes.

À moyen terme, GitHub envisage d’étendre le modèle de réplica virtuelle aux lectures, afin de dissocier complètement les charges de travail et d’exploiter pleinement les capacités d’auto‑scalabilité du cloud Azure.