Dev.to yazısı GitHub'ın binlerce eşzamanlı AI ajanı için Git depolama yeniden tasarımını ayrıntılarıyla anlatıyor

6 Kasım'da yayımlanan bir dev.to yazısı, GitHub'ın Git depolama katmanının, orijinal sistemin hiç öngörmediği bir iş yükü için — tek bir depoya aynı anda push yapan binlerce AI kodlama ajanı — baştan tasarlanmasını anlatıyor. Aşağıdaki tüm teknik ayrıntılar, rakamlar ve yayına geçme iddiaları bu yazıdan geliyor ve yazı, bu haberin tek kaynağı.

Ajanlar Git'in varsayımlarını kırıyor

Yazıya göre geleneksel Git barındırma, insana biçilmiş bir modele dayanıyor: bir geliştirici ara sıra push yapar, bir dalda çalışır, bir pull request açar ve inceleme bekler. Yazma işlemleri depodaki dosya tabanlı kilitlerle korunur; push'lar birkaç dakikada bir geldiğinde bu yeterlidir.

Yazıya göre ajanlar bu varsayımların hepsini aynı anda ihlal ediyor. Birkaç saatte bir değil birkaç saniyede bir push yapıyorlar, aynı dala — genellikle main'e — toplanıyorlar ve aralarında hiçbir koordinasyon olmadan çakışan dosyaları düzenliyorlar. Yazıda alıntılanan GitHub verilerine göre sonuç, insan iş yüklerine kıyasla yaklaşık 100 kat daha fazla kilit çekişmesi. Eski tasarım bir depoya yapılan her push'u seri hale getirdiği için bu çekişme, bir depoya karşı çalışabilecek ajan sayısının katı bir üst sınırı haline geldi.

Tek kilin yerini üç alt sistem alıyor

Yeniden tasarım, depolamayı üç bağımsız parçaya bölüyor.

Nesne deposu blob, tree ve commit'leri yönetiyor. Git nesneleri değişmez ve içerik adresli olduğu için buradaki yazma işlemleri hiçbir kilit gerektirmiyor: aynı blob'u üreten iki ajan aynı hash'i oluşturuyor; sistem nesnenin zaten var olup olmadığını kontrol ediyor, yenilerini dağıtık depolamaya yazıyor ve hemen geri dönüyor. Yazı bunu ana darboğazın ortadan kaldırılması olarak nitelendiriyor.

Ref'ler — değiştirilebilir dal ve etiket işaretçileri — daha zorlu sorun. Yazı bir compare-and-swap protokolünü anlatıyor: mevcut ref değeri okunuyor, başka bir ajan onu çoktan taşımışsa çakışmayla başarısız olunuyor, aksi halde yeni commit atomik olarak takas ediliyor; başarısızlık durumunda taze değer üzerinde üstel geri çekilmeyle yeniden deneniyor. Binlerce ajan eşzamanlı güncelleme deneyebilir; her döngüde biri kazanır, kalanlar yeni temele rebase olur.

Başarısız push'lar artık ajanı bir pull-rebase-retry döngüsüne sokmuyor; yazıya göre bu, ajan trafiğinde thundering herd etkisi yaratırdı. Bunun yerine push'lar asenkron bir öncelik kuyruğuna düşüyor: önce fast-forward push'lar, sonra değişiklikleri çakışmayan ve otomatik birleştirilebilen push'lar, en son insan incelemesi gerektirenler.

Zayıf halka çözümleyici

Bu iş yükleri için GitHub'ın üç metrik açığa çıkardığı belirtiliyor — kilit çekişme oranı, çakışma çözüm gecikmesi ve kuyruk derinliği — ve yazı üç başarısızlık moduna dikkat çekiyor: yeniden denemeler çözümleyiciyi geçtiğinde livelock, sürekli yüksek öncelikli trafik düşük öncelikli push'ları bitiremediğinde açlık, ve büyük bir push tüm kuyruğu tıkadığında zincirleme başarısızlık. Tavsiyesi, ajan başına push hız sınırlarının üstel geri çekilme ve jitter ile birleştirilmesi.

Yazının teknik değerlendirmesi çakışma çözümleyicisini mimarinin zayıf noktası olarak işaretliyor. Tasarım push'ların çoğunun sorunsuz otomatik birleştiğini varsayıyor; ajanlar gerçekten aynı satırları düzenlerse kuyruk, işçilerin boşaltabileceğinden hızlı büyüyor ve koordinasyon, Git'e hiçbir şey ulaşmadan önce bir orkestrasyon katmanında yapılmalı.

Altyapı, yayına geçiş ve yeni saldırı yüzeyleri

Yeni katmanın GitHub'ın mevcut altyapısında üç ek ile çalıştığı belirtiliyor: hızlı nesne varlık kontrolü için bir Redis kümesi, ref sıralaması ve yeniden oynatma için transaction log görevi gören bir Kafka topic'i ve kuyruk derinliğiyle ölçeklenen Kubernetes'te barındırılan çözümleyici pod'ları. Anlatılan yayına geçiş kademeli — ilk hafta depoların yüzde 1'i, dördüncü hafta yüzde 10'u, sekizinci hafta gerçek ajan yükü altında yüzde 50'si ve on ikinci hafta tam geçiş.

Ajan trafiği, yazıya göre GitHub'ın ele almak zorunda kaldığı güvenlik sorunlarını da açıyor: kaynakları tüketmek için kuyruğu çakışma yüklü push'larla doldurma, ref zehirlenmesi yoluyla dal geçmişinin üzerine yazma ve çöp nesnelerle depolama maliyetlerini şişirme. Listelenen önlemler, IP adresi yerine ajan kimliğine bağlı hız sınırları, anomali tespitli ref denetim kayıtları ve nesnelerin yaşa dayalı çöp toplanması.

Neden önemli

Anlatılanlar doğruysa bu, ajan iş yüklerinin insanlardan farklı bir altyapı gerektirdiğinin ve Git'in özgün eşzamanlılık modelinin makine ölçeğindeki push trafiğine dayanamadığının kayda değer kamusal bir itirafı. Temel hamle — nesneleri değişmez, içerik adresli veri olarak ele alırken dal işaretçilerinin seri hale gelmek yerine yakınsamasına izin vermek — çok sayıda commit atan ajan çalıştıran her ekibin muhtemelen ihtiyaç duyacağı bir kalıp; yazı, çekişmenin yaklaşık 50 eşzamanlı ajan civarında can sıkıcı hale geldiğini, olağan kilitlemenin ise kabaca 10'un altında daha basit kaldığını öne sürüyor. Önümüzdeki uyarı kaynak güvenilirliği: yukarıdaki her şey birincil bir GitHub belgesi değil, tek bir topluluk yazısına dayanıyor; o yüzden spesifik rakamlara göre yaklaşın.