GitHub depoların %99,99999'unu Azure'a taşıdı ve Git okumalarını object storage üzerinden ölçekleyecek

GitHub, platformundaki Git depolarının %99,99999'unun artık hem kendi veri merkezlerinde hem de Azure'da bulunduğunu açıkladı ve son, en yoğun direnen depoları taşımak ile okumaları object storage üzerinden bağımsız olarak ölçeklendirmek için gereken mühendislik çalışmasını ortaya koydu. GitHub Blog'daki bir mühendislik yazısında şirket, zamanlamanın agentic iş yüklerinden gelen hızla büyüyen trafik, veri merkezlerine ve çevredeki bölgeye sağlanabilecek elektrik gücündeki sert üst sınır ve tedarik zinciri kısıtlamaları tarafından belirlendiğini söyledi.

Şimdiye kadarki göç

GitHub Blog'a göre ilk depo kopyası Ağustos 2025'te Azure'un Central US bölgesine ulaştı. O zamandan beri göç kopya kopya ilerledi: depoların çoğu dayanıklılık, erişilebilirlik ve ölçek arasında denge kurmak için beş kopya tutuyor ve bu beş kopyadan ikisi şu anda tipik olarak Azure'da bulunuyor. Şirket, Azure'un bugün tüm Git trafiğinin yaklaşık yarısını karşıladığını ve göçün büyük bölümünde bulutun platform büyümesini absorbe ederken kendi veri merkezlerindeki yükün sabit kaldığını söyliyor.

GitHub'ın replikasyon sistemi Spokes, istekleri öncelikli olarak çağıranla aynı bölge ve availability zone içindeki bir kopyaya yönlendiriyor. Azure'a yerleşen her kopya, o deponun isteklerinin daha büyük bir kısmının orada yanıtlanmasını sağlıyor ve son kopya geldiğinde eski bölge o trafiği almayı bırakıyor. Git operasyonları GitHub'daki neredeyse her şeyin bağlı olduğu bir Tier 0 servisi olduğu için şirket çalışmayı bilinçli bir sırayla yürüttü: önce veriyi ve bağımlılıklarını taşı, ardından depolama mimarisini dönüştür.

Son depolar neden takılı kaldı

Geriye kalan %0,00001'lik depo dilimi platformdaki en yoğun depolar arasında ve engel ağ mesafesi: hedef Azure bölgesi GitHub'ın veri merkezlerinden yaklaşık 1.000 mil uzakta, her tur yaklaşık 25ms ekliyor ve tek bir write birkaç tur gerektiriyor.

GitHub'ın açıkladığı şekliyle daha derin sorun, write quorum'unun serileştirme biçiminde. Spokes'un bir write'ı commit etmek için yalnızca kopyaların çoğunluğuna ihtiyacı var, ama devam etmek için yine de sağlıklı her kopyanın yanıt vermesini bekliyor. Bu yüzden en yavaş kopya her write'ın gecikmesini belirliyor ve her write commit olana kadar depo genelinde bir kilit tuttuğundan, deponun throughput tavanını da o belirliyor. Bu tavana yakın çalışan bir depo, serileştirilmiş her write'a eklenen 25ms'yi absorbe edemez ve her push'ta daha da geride kalır.

Quorum'u tek bir reference'a daraltmak

GitHub'ın yanıtı, quorum'un kapsamını deponun tamamından tekil reference'lara — branch ve tag'lere — daraltmak. Git'in tutarlılık garantisi her reference'a ayrı ayrı uygulanır: sunucu bir güncellemeyi kabul ettiğinde, istemciler yalnızca o değeri ya da daha yeni birini görmelidir. Farklı reference'lara yapılan güncellemeler genellikle birbirinden bağımsızdır ve birbirlerini beklemeden ilerleyebilir.

Per-reference serileştirme altında yalnızca aynı reference için çekişen write'lar kuyruğa girer. Farklı branch'lere yapılan write'lar — örneğin agent'ların ve geliştiricilerin kendi branch'lerine push etmesi — her biri bölgeler arası gecikmeyi ödese bile aynı anda havada olabilir. Gerçekçi trafikle yapılan dahili testlerde GitHub, farklı reference'lara isabet eden write'lar için daha düşük gecikmede yaklaşık 3–4 kat daha yüksek throughput ölçtü ve bir deponun write tavanının aynı anda yazılan reference sayısıyla kabaca orantılı biçimde yükseldiğini söylüyor.

Sanal kopya olarak object storage

Aynı değişiklik ikinci aşamanın da temelini oluşturuyor: okumaları write'lardan ayırmak. Depolar ağır biçimde okuma ağırlıklı — GitHub bunu her write başına 100 ile 1.000 arası okuma olarak ifade ediyor — ama okumalar ve write'lar şu anda aynı kopyalara isabet ediyor ve aynı kaynaklar için yarışıyor, dolayısıyla ikisi de ayrı ayrı ölçeklenemiyor.

İlk adım, Azure Blob Storage'ı GitHub'ın ilk tamamen ephemeral node'u tarafından temsil edilen bir "sanal kopya" olarak write quorum'una üye yapıyor. Gelen write'ların akışını kabul ediyor ama hiçbir okuma trafiği hizmet vermiyor ve quorum'a üye olduğu için bir write, object storage'da kalıcı hale gelene dek onaylanmıyor. Node ayrıca ilgisiz reference'lara yapılan write'ları birlikte topluyor, böylece yoğun bir depo çok sayıda eşzamanlı write için write başına bir tur yerine object storage'a tek tur ödüyor. Şimdilik compaction'ı da üstleniyor ve okuma kopyaları compact edilmiş durumu devralıyor.

Bunun üzerine GitHub talep üzerine sanal okuma kopyaları başlatabiliyor. Her biri önbelleğini object storage'dan yüklüyor, quorum'a katılmadan okuma hizmeti vermeye başlıyor ve yerel durumunu arka planda object storage ile eşitliyor. Dahili yük testlerinde, mevcut mimaride düzenli olarak tavanları ortaya çıkaran dağıtık test aracı, sanal okuma kopyalarından önce kendi başlangıç kapasitesini tüketti.

Neden önemli

GitHub bu hamleyi koşulların zorunlu kıldığı şekilde tanımlıyor: agentic trafik büyümesi, tesislerindeki güç üst sınırı ve tedarik zinciri sınırları, bir Tier 0 servisinin yavaş bir göçüne yer bırakmıyordu. Yeniden tasarım ayrıca farklı bir trafik profilini öngörüyor: agent'lar ve geliştiricilerin aynı anda birçok ayrı reference'a push ettiği — per-reference quorum'ların doğrudan karşıladığı bir desen — bir profil, ayrıca object destekli okuma kopyaları okuma kapasitesinin write quorum'undan bağımsız büyümesine izin veriyor. Kullanıcılar için pratik sonuç, yoğun depolarda daha yüksek throughput tavanları ve artık write'larla yarışmayan okumalar; wider sektör için ise AI odaklı iş yüklerinin çekirdek altyapı tasarımını nasıl yeniden şekillendirdiğine somut bir örnek.