GitHub hat Kopien von 99,99999 % seiner Repositories nach Azure verlagert und behält gleichzeitig Kopien in den eigenen Rechenzentren. Die verbleibenden Repositories gehören zu den meistgenutzten der Plattform, und die Netzwerklatenz zwischen den Regionen hat ihre Migration erschwert. Das Unternehmen erklärt, eine Änderung der Koordination von Schreibvorgängen werde dabei helfen, auch diese Repositories zu verlagern und den Übergang zu einer Infrastruktur zu unterstützen, die auf den zunehmenden Datenverkehr durch Entwickler und KI-Agenten ausgelegt ist.
Die Migration begann im August 2025 mit einer Kopie eines Repositorys in der Azure-Region „Central US“. Die meisten Repositories haben inzwischen zwei ihrer fünf Replikate in Azure, wo etwa die Hälfte des Git-Datenverkehrs abgewickelt wird. GitHub entschied sich dafür, die Daten vor einer Änderung der Speicherarchitektur zu verlagern. Als Gründe nannte das Unternehmen die Bedeutung von Git-Vorgängen und die Risiken, Hosting-Plattform und Architektur gleichzeitig zu ändern.
Beim aktuellen Design wartet ein Schreibquorum auf die Antwort jedes fehlerfreien Replikats, obwohl eine Mehrheit ausreicht, um einen Schreibvorgang zu bestätigen. Da eine repositoryweite Sperre bestehen bleibt, bis der Schreibvorgang abgeschlossen ist, kann das langsamste Replikat sowohl die Latenz als auch den Durchsatz begrenzen. Die Azure-Replikate liegen etwa 1.000 Meilen von den Rechenzentren von GitHub entfernt. Ein Netzwerk-Roundtrip dauert rund 25 Millisekunden, und Schreibvorgänge erfordern mehrere solcher Übertragungen.
GitHub schlägt vor, Schreibvorgänge künftig pro Referenz statt für ein gesamtes Repository zu koordinieren. Zu den Referenzen gehören Branch-Zeiger, und nach Angaben des Unternehmens sind Aktualisierungen verschiedener Referenzen in der Regel nicht voneinander abhängig. Beim neuen Ansatz warten Schreibvorgänge für dieselbe Referenz weiterhin aufeinander, während Schreibvorgänge für getrennte Referenzen parallel ablaufen können. In internen Tests mit realistischem Datenverkehr erzielte GitHub nach eigenen Angaben bei Schreibvorgängen auf unterschiedliche Referenzen einen drei- bis viermal höheren Durchsatz und eine geringere Latenz.
Die Änderung ermöglicht außerdem einen separaten Skalierungspfad für Lesevorgänge. GitHub zufolge entfallen auf jeden Schreibvorgang typischerweise zwischen 100 und 1.000 Lesevorgänge. Derzeit nutzen beide Arten von Datenverkehr jedoch dieselben Replikate und konkurrieren um Ressourcen. Als nächsten Schritt will das Unternehmen Azure Blob Storage über ein „virtuelles Replikat“ in das Schreibquorum einbinden. Dieser kurzlebige Knoten streamt eingehende Schreibvorgänge in den Objektspeicher. Ein Schreibvorgang wird erst bestätigt, wenn er dort dauerhaft gespeichert ist.
Das virtuelle Schreibreplikat stellt keine Daten für Lesevorgänge bereit. Stattdessen kann GitHub bei Bedarf virtuelle Lesereplikate erstellen, deren Caches aus Blob Storage gefüllt werden und die Lesedatenverkehr abwickeln, ohne dem Quorum beizutreten. In internen Lasttests stieß GitHub nach eigenen Angaben zuerst an die Grenzen seines Testsystems, bevor eine Obergrenze für diese Replikate erreicht wurde. Das Unternehmen weist darauf hin, dass sich eine Hintergrundabstimmung nicht für jede Leseauslastung eignet und weitere Verbesserungen nötig sind, um den Schreibdurchsatz über die Grenzen des Quorums hinaus zu erhöhen.
Die nächste Herausforderung besteht laut GitHub darin, die geringe Datenmenge eines Repositorys zu ordnen, die koordiniert werden muss, und gleichzeitig unveränderliche Git-Objekte zu speichern, ohne eine Einigung zwischen den Replikaten zu erfordern. Das Unternehmen plant, seine angestrebte Zielarchitektur in einem künftigen Beitrag und auf der GitHub Universe vorzustellen.
Quellen: GitHub Blog.