Contexte et objectifs

Lors de GitHub Universe, l’entreprise a présenté une refonte de son stockage Git, baptisée « Rubicon ». Les tests internes montrent la prise en charge de 5 000 agents concurrents sur un même dépôt, avec 7 200 pushes par seconde tout en maintenant une latence de lecture constante. Cette capacité répond à la montée en puissance des agents automatisés qui génèrent des écritures continues et un fort trafic de lecture, notamment pour les pipelines CI/CD et les déploiements.

Principes de conception

Deux règles guident l’architecture : minimiser la coordination et séparer le stockage du calcul. Les objets Git sont immuables et identifiés par leur contenu, ce qui permet à plusieurs écrivains de les stocker simultanément sans accord préalable. Seule la mise à jour de référence nécessite un consensus, et cette opération représente une fraction du volume total d’un push. En limitant la coordination à la référence, le système peut répartir les tâches de traitement (indexation, vérification de connectivité) sur plusieurs nœuds, évitant ainsi le goulet d’étranglement d’un seul serveur.

Architecture Rubicon

Les requêtes Git, l’API et l’interface web arrivent d’abord aux Spokes, qui assurent le routage, l’équilibrage de charge et la partition des locataires. Chaque dépôt est associé à un groupe restreint de répliques virtuelles, des instances éphémères disposant d’un cache local reconstruit à la volée. Les répliques servent les lectures et les écritures, mais le stockage persistant des objets Git et des métadonnées de référence réside dans Azure Blob Storage. Un pool de nœuds de compaction travaille en arrière‑plan directement sur le blob, fusionnant les packs et éliminant les objets orphelins, ce qui libère les ressources CPU et mémoire des répliques virtuelles pour le service client.

Implications et limites

Cette séparation permet d’ajouter ou de retirer des répliques virtuelles sans impacter la cohérence, améliorant la tolérance aux pannes et le temps de récupération. Le modèle cible une augmentation d’au moins deux ordres de grandeur par rapport aux capacités précédentes, soit plusieurs milliers d’écritures simultanées sur un même dépôt. Cependant, la dépendance à Azure Blob Storage introduit une latence réseau inhérente aux opérations de lecture/écriture sur le cloud, et la gestion du cache local reste critique pour éviter des « cold starts ». Enfin, la solution repose sur la capacité du système à linéariser les mises à jour de référence, ce qui nécessite un mécanisme fiable de quorum au niveau des références uniquement.