etcd ile Asya-Pasifik Video Trafiğini Yönlendirmek

Sekiz Asya-Pasifik pazarına hizmet veren bir video akış platformu, bölgeye özel yapılandırmaları etcd'ye taşıyarak tekrarlanan bir yönlendirme hatasını durdurdu. Yönlendirme değişikliklerinin yayılma süresi yaklaşık bir saniyeye düştü. Editörler artık koda dokunmadan bir müzik havuzunu birkaç saatliğine öne çıkarabiliyor ve platform Güney Koreli izleyicilere Tokyo akışını göndermeyi bıraktı.

Eski yaklaşım neden çöktü

Her yönlendirici her istek için üç değer okuyordu: trend havuzu, dile özgü tokenizer ve bir fallback (yedekleme) zinciri. Bu değerleri kod değişiklikleri değil; yeni bir sanatçıyı öne çıkarmak, bölgesel bir kesintiye tepki vermek veya bir öneri algoritmasını test etmek gibi iş kararları yönlendiriyordu.

Başlangıçta her dağıtım (deployment), yönlendirme tablosunu içeren bir JSON dosyasıyla birlikte geliyordu. Bir olay sırasında, nöbetçi mühendis trafiği bir yedek havuzuna yönlendirmek için tek bir düğümdeki (node) dosyayı düzenledi ancak diğer yedi düğümü güncellemedi. Yapılandırma sapması (config drift) ortaya çıktı: sekiz ülke farklı tablolar çalıştırıyordu ve "gerçeği" doğrulayan tek bir kaynak yoktu. Seul'deki izleyicileri Tokyo'ya gönderen hata, kod aynı kaldığı için devam etti; sadece gizli yapılandırma farklılık gösteriyordu.

Tek doğruluk kaynağı olarak etcd'yi seçmek

Ekip üç seçeneği karşılaştırdı:

  • SQLite/MySQL – her yönlendiriciyi bir veritabanını sorgulamaya (poll) zorlayacak, bu da gecikmeye neden olacak veya sorgu yağmuruna tutacaktı.
  • Consul – sağlam bir servis keşif (service-discovery) aracı, ancak platformun tüm mesh özelliklerine ihtiyacı yoktu.
  • etcd – bir anahtar değiştiği anda istemcileri bilgilendiren bir watch (izleme) primitifine sahip, güçlü tutarlılığa (strongly consistent) sahip bir anahtar-değer deposu.

Watch özelliği dengeyi değiştirdi. Her yönlendiricinin sürekli "bir şey değişti mi?" diye sorması yerine, yönlendiriciler etcd bir güncelleme gönderene kadar boşta bekledi. Gereksiz ağ trafiği ortadan kalktı ve her örnek (instance) bir değişiklikten eş zamanlı olarak haberdar oldu.

Sistemi güvenli tutan desenler

Etcd tek başına tüm riskleri çözmedi. Mühendisler üç tamamlayıcı desen ekledi:

  1. Leases (Kiralamalar) – bir editör geçici bir öne çıkarma ayarlayabilir (örneğin, bir Kore popu havuzunun ağırlığını altı saatliğine artırmak). Kiralama süresi otomatik olarak dolar, böylece öne çıkarma işlemi manuel bir geri alma (rollback) gerektirmeden ortadan kalkar.
  2. Compare-and-swap (CAS) – iki kişi aynı ayarı eş zamanlı olarak düzenlediğinde, CAS bir kişi için açıkça hata verir ve sessizce üzerine yazılmasını önler.
  3. Sidecar süreci – PHP, uzun süreli bağlantılar konusunda zorlanır. Her makinedeki küçük bir Go sidecar'ı etcd'yi izler ve yönlendirme tablosunun bir anlık görüntüsünü (snapshot) paylaşımlı bellek dosyasına (/dev/shm) yazar. PHP, istek işleme sırasında herhangi bir ağ gidiş-dönüşünden (round-trip) kaçınmak için bu yerel dosyayı okur.

Mimariye dahil edilmiş dayanıklılık

Yeni tasarım birkaç güvenlik ağı ekliyor:

  • Sıfır gecikmeli okumalar – PHP'nin kritik yolu (hot path) yerel bellekten okuma yapar, böylece istekler uzak bir depolama birimini beklerken asla duraksamaz.
  • Kademeli bozulma (Graceful degradation) – etcd çökerse, yönlendiriciler son bilinen iyi yapılandırmayı sunmaya devam ederek ani bir kesintiyi önler.
  • Güvenilir güncellemeler – sidecar, yeniden bağlanma mantığını yönetir ve etcd bağlantısı geçici olarak kopsa bile hiçbir değişikliğin kaçırılmamasını garanti eder.

Sahada neler değişti

Göçten sonra ekip, bayat veya uyuşmayan yönlendirme verilerinden kaynaklanan olaylarda keskin bir düşüş gördü. Artık tek bir konsol mevcut yapılandırmayı gösteriyor ve yapılan herhangi bir düzenleme bir saniye içinde sekiz bölgenin tamamına yayılıyor. Geçici öne çıkarmalar, kiralama süreleri dolduğunda kendiliğinden temizleniyor ve bu da daha önce insan hatasına yol açan manuel temizleme adımlarını ortadan kaldırıyor.

Karşı görüş: bir sidecar'ın maliyeti

Bir sidecar eklemek, sunucu başına ikinci bir süreç ve PHP merkezli bir yığında bir Go çalışma zamanı (runtime) anlamına gelir. Bazı operatörler ekstra bellek kullanımı ve başka bir ikiliyi (binary) izleme ihtiyacı konusunda endişeleniyor. Uygulamada sidecar'ın ayak izi mütevazı kalır ve elde edilen güvenilirlik kazanımları —özellikle PHP'nin bir ağ çağrısında asla bloklanmayacağı garantisi— operasyonel yükten daha ağır basar.

Bundan sonra nelere dikkat edilmeli

Çok bölgeli hizmetleri yöneten ekipler şunları izlemelidir:

  • etcd sağlık metrikleri – yönlendirme katmanı tek bir depoya bağlıdır; quorum (çoğunluk) durumunu ve gecikmeyi göz önünde bulundurun.
  • Kiralama süresi sonu yönetimi – kiralama sürelerini iş pencereleriyle eşleştirin; aşırı uzun kiralamalar bayat öne çıkarmaların kalmasına neden olur.
  • Watch yükünü ölçeklendirme – yönlendiriciler arttıkça watch bağlantıları da artar; etcd sunucuları için kapasiteyi buna göre planlayın.

Sonuç

Birçok bölge genelinde hızlı ve koordineli yapılandırma değişikliklerine ihtiyaç duyan her türlü servis için etcd'nin watch, lease ve transaction primitifleri; dosya tabanlı yapılandırmalara veya ağır sıklet mesh yapılarına hafif ve güçlü tutarlılığa sahip bir alternatif sunar. Yapılandırmayı itme tabanlı ve kendi kendini temizleyen bir depolama alanına dönüştürmek, bir dizi olayı tamamen ortadan kaldırdı ve platforma yönlendirme mantığı üzerinde gerçek zamanlı kontrol sağladı.