The Pulse

GitHub afferma che la nuova architettura di storage Git ha supportato 5.000 agenti simultanei nei test interni

GitHub afferma che la sua nuova architettura di storage Git ha gestito 5.000 agenti simultanei e 7.200 push al secondo verso un unico repository nei test interni. Secondo GitHub, la progettazione consente allo storage dei dati, alla gestion

AI.info Team · Scritto con l’IA · verificato · 2026-11-05

GitHub afferma che la sua nuova architettura di storage Git ha supportato 5.000 agenti simultanei al lavoro su un unico repository, con 7.200 push al secondo e una latenza delle letture costantemente bassa durante i test interni. L’azienda ha pubblicato il resoconto della progettazione il 5 novembre, dopo aver annunciato l’architettura a GitHub Universe la settimana precedente. GitHub definisce il sistema la base per supportare lo sviluppo agentico e afferma di aver realizzato l’architettura alla base di GitHub mentre il servizio continuava a funzionare.

GitHub afferma che la maggior parte dei requisiti deriva dalla scalabilità all’interno di un singolo repository

GitHub suddivide la scalabilità della piattaforma in due assi: la scalabilità orizzontale tra molti repository e quella verticale all’interno di un singolo repository. L’azienda afferma che molti degli approcci attuali alla scalabilità orizzontale sono stati ampiamente collaudati e rimangono validi, tra cui la suddivisione dei tenant nell’infrastruttura, l’isolamento o l’applicazione di criteri di equità al traffico dei tenant e l’instradamento in base al carico. Afferma che la maggior parte dei requisiti è derivata dall’asse verticale e che si aspetta che i singoli repository diventino più grandi e più trafficati man mano che gli agenti scrivono più codice.

GitHub afferma che i suoi repository più trafficati ricevono attualmente al massimo decine di scritture al secondo, di norma in brevi picchi. Si aspetta che gli agenti che lavorano in parallelo 24 ore su 24 trasformino quei picchi in ritmi di scrittura sostenuti entro il prossimo anno. Ogni push provoca anche letture da parte dei sistemi di integrazione continua, dei sistemi di deployment e di altri agenti che recuperano il nuovo commit. In un repository, le richieste giornaliere sono passate da una media di 44 milioni a marzo a una media di 181 milioni a maggio 2026, circa quattro volte tanto.

Per un singolo repository, GitHub si è posta l’obiettivo di aumentare la scalabilità di almeno due ordini di grandezza. Tra i requisiti figurano l’accettazione di migliaia di scritture al secondo, il supporto di più nodi di scrittura, la riduzione al minimo della latenza dei commit e il contenimento del costo delle letture quando nulla è cambiato. La progettazione deve anche registrare in ordine le modifiche per ogni riferimento e consentire a ciascun componente di scalare indipendentemente.

GitHub afferma che Rubicon separa le repliche dai dati persistenti

GitHub ha iniziato a lavorare alla progettazione, denominata Project Rubicon, nel maggio 2026. Afferma che le richieste dei client Git, dell’API e dell’interfaccia web passano ancora attraverso Spokes, che gestisce l’instradamento, il bilanciamento del carico e l’allocazione dei tenant. Al di sotto di Spokes, afferma GitHub, le repliche virtuali forniscono capacità di calcolo temporanea per letture, scritture o entrambe; il disco locale di ogni replica funge da cache che può essere ricostruita.

GitHub afferma che l’architettura colloca gli oggetti Git, compresi i pack e i dati per accelerare le letture, in Azure Blob Storage. Un servizio di log replicato separato, Ref-CAS, memorizza i riferimenti e il manifesto dei pack del repository. Per una scrittura, una replica virtuale indicizza un pack in arrivo e lo carica su Blob Storage, quindi esegue il commit di una transazione Ref-CAS che elenca il pack e aggiorna i riferimenti. Per una lettura, la replica verifica la versione dei riferimenti in Ref-CAS e recupera i pack necessari da Blob Storage nella propria cache.

GitHub afferma che Ref-CAS gestisce gli aggiornamenti dei riferimenti, non gli oggetti Git

GitHub afferma che gli oggetti Git sono immutabili e denominati in base al loro contenuto, perciò chi scrive può memorizzarli senza coordinarsi con gli altri. Gli aggiornamenti dei riferimenti sono la parte di un push che richiede un accordo. Ref-CAS esegue il commit di ogni aggiornamento dei riferimenti tramite un quorum, bloccando solo i riferimenti coinvolti nella transazione.

Ogni commit di Ref-CAS riceve un numero di sequenza del log e la versione del repository è il numero associato al suo commit più recente. Una replica virtuale può verificare se il proprio stato dei riferimenti è aggiornato inviando la propria versione; se nulla è cambiato, Ref-CAS non restituisce alcun riferimento. GitHub afferma che la verifica di un repository invariato richiede un solo confronto, mentre le transazioni sullo stato dei riferimenti possono raggiungere decine di migliaia di operazioni al secondo.

GitHub ha testato due alternative che usano Blob Storage per gli aggiornamenti dei riferimenti. Un unico blob per il log dei riferimenti del repository limitava nella pratica le scritture a qualche centinaio al secondo, anche con il raggruppamento delle operazioni. La suddivisione dei riferimenti tra più blob ha innalzato il limite delle scritture, ma costringeva ogni lettura a controllare tutti i segmenti e ad attendere quello più lento.

GitHub afferma che la compattazione in background gestisce la crescita dei pack

Ogni push aggiunge un pack e GitHub afferma che le ricerche diventano leggermente più costose all’aumentare del numero di pack. Secondo GitHub, nella nuova architettura la compattazione viene eseguita in background su nodi separati che operano direttamente sullo storage persistente, e non sulle repliche che gestiscono il traffico. Questi nodi acquisiscono lease sugli shard dei repository, in modo che solo un nodo alla volta compatti uno shard.

Un nodo di compattazione raccoglie i pack in un segmento, lo chiude quando raggiunge un limite basato sul numero, sulle dimensioni o sull’età dei pack, e combina i pack. Prima di pubblicare il risultato, verifica che i nuovi pack contengano esattamente gli stessi oggetti di quelli in ingresso. GitHub afferma di aver dimostrato con costanza una curva di latenza piatta all’aumentare delle scritture; anche la garbage collection usa worker dedicati per rimuovere gli oggetti che non sono più referenziati.

GitHub elenca ulteriori interventi previsti, tra cui il recupero di un singolo oggetto senza scaricare l’intero pack, le repliche parziali e le repliche in qualsiasi regione. I piani dichiarati per le operazioni degli agenti includono la possibilità di lavorare senza un clone, un’API per commit atomici su modifiche a più file e flussi di eventi per reagire alle modifiche dei repository.