GitHub Git depolama mimarisi neden değişiyor?
GitHub Git depolama mimarisi, platformun yazılım ajanlarıyla değişen çalışma yüküne verdiği altyapı yanıtını anlatıyor. Şirketin açıklamasına göre yeni tasarım, binlerce ajanın aynı depoya aynı anda gönderim yapabildiği bir senaryo için kuruldu. Amaç, çok sayıda yazma işlemini karşılayabilmek ve okuma trafiğini ihtiyaç oldukça ölçekleyebilmek.
GitHub’ın vurguladığı sorun, yalnızca platformdaki toplam kullanıcı ya da ajan sayısı değil. Asıl zorlayıcı alan, çok sayıda geliştirici ve ajanın tek bir depo üzerinde paralel çalışması. Ajanların daha fazla kod yazmasıyla, tekil depoların hem büyümesi hem de daha yoğun kullanılması bekleniyor. Bu yoğunlukta her yeni gönderim, sonraki sistem hareketlerini de artırıyor.
İki ölçek sorunu: depolar arasında ve tek depoda
GitHub, altyapı ölçeğini iki ayrı eksende ele alıyor. Yatay ölçek, çok sayıda depo genelinde kaç geliştirici ve ajanın çalışabildiğiyle ilgili. Şirket; altyapı üzerinde kiracıların bölümlenmesi, kiracı trafiğinin yalıtılması veya adalet kurallarının uygulanması ve yük farkındalıklı yönlendirme gibi mevcut yöntemleri yeni mimaride de kullanıyor.
Dikey ölçek ise tek bir depo içinde kaç geliştirici ve ajanın birlikte çalışabildiğini ifade ediyor. GitHub’a göre bugünün en yoğun depoları, genellikle kısa süreli sıçramalar hâlinde, bir saniye içinde en fazla onlarca yazma işlemi alıyor. Şirket, paralel ve gün boyu çalışabilen ajanlarla birlikte bu kısa sıçramaların daha kalıcı bir hıza dönüşmesini bekliyor.
Yazma işlemlerinin tamamı aynı türde değil
Yeni tasarımın dayandığı ana fikir, bir Git gönderimindeki her verinin aynı düzeyde eşgüdüm gerektirmemesi. Git nesneleri değiştirilemez; ayrıca içeriklerine göre adlandırılır. GitHub’ın açıklamasına göre bu durum, iki farklı yazıcının nesneleri aynı anda depolayabilmesini sağlıyor; bunun için önceden ortak bir karara varmaları gerekmiyor.
Buna karşılık, gönderim sürecindeki referans güncellemesi uzlaşma gerektiriyor. GitHub, referans güncellemesinin veri boyutu bakımından küçük olduğunu belirtiyor. Mimari de bu ayrımdan hareket ediyor: sıralı anlaşma gerektiren dar kısmı hedefliyor; veri depolama, istekleri yanıtlama ve depoları sürdürme gibi önceden daha sıkı bağlı işlevlerin bağımsız ölçeklenebilmesine zemin hazırlıyor.
GitHub Git depolama mimarisi hangi parçaları ayırıyor?
GitHub, önceki geçiş çalışmalarında depoların yüzde 99,99999’unu Azure’a taşıdığını, yazma uzlaşmasını tek tek referanslarla sınırladığını ve Azure Blob Storage ile desteklenen sanal kopyaları devreye aldığını söylüyor. Sanal kopyalar, depoların yeni mimariye alınmasında ilk aşama olarak kullanılmış.
Bu yaklaşımda depolama, istek sunma ve depo bakımı aynı ölçekte büyümek zorunda değil. Başka bir ifadeyle, sistemin bütününü tek bir darboğaza bağlamak yerine, uzlaşma gerektiren referans güncellemesi ile başka işlemleri birbirinden ayırmayı hedefliyor. GitHub’ın anlattığı mimarinin teknik mantığı, bu küçük fakat sıralanması gereken işlemi daha geniş veri akışından ayıklamak.
Yazmalar neden daha fazla okumaya yol açıyor?
Bir depoya yapılan her gönderim, yalnızca yeni verinin yazılması anlamına gelmiyor. GitHub’a göre bu gönderimi CI çalıştırmaları izleyebiliyor; dağıtım sistemleri yeni commit’i çekebiliyor ve diğer ajanlar bağlam edinmek için onu getirebiliyor. Böylece bir yazma işlemi, çok sayıda okuma isteğine dönüşebiliyor.
Bu okuma yayılımı, toplam trafiği yazma sayısıyla birlikte büyüten bir çarpan etkisi yaratıyor. GitHub, yüksek trafik alan depolarda bu eğilimi şimdiden gözlemlediğini belirtiyor. Şirketin Mart ile Mayıs arasındaki günlük istek verileriyle örneklediği bir depoda trafik yaklaşık dört kat arttı; GitHub, bu büyümenin daha sonra da üstel bir seyir izlediğini ifade ediyor.
Test sonuçları ve geliştiriciye yansıyan taraf
GitHub’ın iç testlerinde yeni mimari, aynı depoda çalışan 5.000 eş zamanlı ajanı ve saniyede 7.200 gönderimi destekledi. Şirket, bu sırada okuma trafiğinin tutarlı biçimde düşük gecikmeyle sunulduğunu bildiriyor. Duyuruda mimarinin saniyede binlerce yazmayı ele alabildiği ve okumaların talebe göre ölçeklenebildiği de belirtiliyor.
Kullanıcı tarafında ise Git’in çalışma biçiminin değişmemesi hedefleniyor. GitHub’a göre geliştiriciler gönderim yapmaya, veri çekmeye ve dal oluşturmaya aynı şekilde devam edecek; mevcut korumalar da yerinde kalacak. Bu nedenle değişiklik, geliştiricinin günlük Git komutlarından çok, bu komutların arkasındaki depolama ve trafik yönetimi katmanında gerçekleşiyor.
Bu mimariyi anlamak neden önemli?
Ajanlarla yapılan geliştirme, tek bir depodaki eş zamanlı işlem sayısını artırma potansiyeli taşıyor. GitHub’ın yaklaşımı, bu durumu Git’in tüm verileri için tek tip bir senkronizasyon problemi olarak ele almıyor. Bunun yerine, hangi işlemlerin gerçekten ortak karar gerektirdiğini ayırıyor ve geri kalan alanların bağımsız büyümesine odaklanıyor.
Şirket, yeni mimariyi yüz milyonlarca geliştirici için ajan odaklı geliştirmeyi destekleyecek bir temel olarak tanımlıyor. Şimdilik açıklanan çerçeve; referans güncellemelerindeki uzlaşma ihtiyacı, Azure tabanlı geçiş ve sanal kopyalar üzerinden, yoğun yazma trafiği ile onu izleyen okuma dalgasının nasıl yönetilmeye çalışıldığını ortaya koyuyor.
Bir içerik, dört format.
Okumaya vaktin yoksa özetle; paylaşacaksan platforma göre yeniden düzenle.
GitHub, tek bir depoda eş zamanlı çalışan binlerce yazılım ajanının oluşturabileceği yazma ve okuma trafiği için yeni bir Git depolama mimarisi geliştirdi. Tasarımın temelinde, yalnızca referans güncellemelerinin sıralı uzlaşma gerektirdiği tespiti yer alıyor. • GitHub Git depolama mimarisi neden değişiyor? • İki ölçek sorunu: depolar arasında ve tek depoda • Yazma işlemlerinin tamamı aynı türde değil
Bu önizleme yalnızca sayfadaki editoryal veriyi yeniden biçimlendirir. Gerçek yapay zekâ üretimi Core tarafında güvenli bir sunucu endpoint’iyle bağlanacak.
