GitHub ha trasferito su Azure copie del 99,99999% dei suoi repository, mantenendone al contempo copie nei propri data center. I repository rimanenti sono tra i più trafficati della piattaforma e la latenza di rete tra regioni ha reso difficile migrarli. L’azienda afferma che cambiare il modo in cui coordina le scritture aiuterà a trasferirli e sosterrà il passaggio a un’infrastruttura progettata per gestire il traffico crescente di sviluppatori e agenti IA.
La migrazione è iniziata con l’arrivo di una copia di un repository nella regione Central US di Azure nell’agosto 2025. La maggior parte dei repository ha ora due delle proprie cinque repliche su Azure, che gestisce circa la metà del traffico Git. GitHub ha scelto di spostare i dati prima di cambiare l’architettura di archiviazione, sottolineando l’importanza delle operazioni Git e i rischi di modificare contemporaneamente sia la piattaforma di hosting sia l’architettura.
Nel modello attuale, un quorum di scrittura attende la risposta di tutte le repliche integre, anche se per completare una scrittura è sufficiente la maggioranza. Poiché un blocco a livello di repository resta attivo fino al completamento della scrittura, la replica più lenta può limitare sia la latenza sia il throughput. Con le repliche Azure a circa 1.000 miglia dai data center di GitHub, un viaggio di andata e ritorno sulla rete richiede circa 25 millisecondi e le scritture richiedono più passaggi.
La modifica proposta da GitHub consiste nel coordinare le scritture per riferimento anziché sull’intero repository. I riferimenti includono i puntatori ai branch e, secondo l’azienda, gli aggiornamenti a riferimenti diversi di solito non dipendono l’uno dall’altro. Con il nuovo approccio, le scritture sullo stesso riferimento continuano ad attendersi a vicenda, mentre quelle su riferimenti distinti possono procedere in parallelo. Nei test interni basati su traffico realistico, GitHub riferisce un throughput da 3 a 4 volte superiore per le scritture su riferimenti diversi, con una latenza inferiore.
La modifica supporta inoltre un percorso di scalabilità separato per le letture. GitHub afferma che i repository ricevono in genere tra 100 e 1.000 letture per ogni scrittura, ma attualmente entrambi i tipi di traffico utilizzano le stesse repliche e si contendono le risorse. Il passo successivo consiste nell’integrare Azure Blob Storage nel quorum di scrittura tramite una «replica virtuale». Questo nodo effimero trasmette le scritture in arrivo all’archiviazione a oggetti e una scrittura viene confermata solo dopo essere stata resa persistente.
La replica virtuale di scrittura non gestisce le letture. GitHub può invece creare repliche virtuali di lettura su richiesta, riscaldandone le cache a partire da Blob Storage e servendo il traffico di lettura senza farle partecipare al quorum. Nei test interni di carico, GitHub afferma che il proprio sistema di test ha raggiunto i suoi limiti prima di individuare un limite per queste repliche. L’azienda osserva che la riconciliazione in background potrebbe non essere adatta a tutti i carichi di lettura e che sono necessari ulteriori miglioramenti per aumentare il throughput di scrittura oltre i limiti del quorum.
GitHub afferma che la prossima sfida consiste nel coordinare la piccola quantità di dati del repository che richiede coordinamento, archiviando al contempo gli oggetti Git immutabili senza richiedere un accordo tra le repliche. L’azienda prevede di descrivere l’architettura finale a cui mira in un prossimo post e a GitHub Universe.
Fonti: GitHub Blog.