"Yerelde mükemmel çalıştı": Netflix'in servis haritası üretimde nasıl kırıldı
Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned · Netflix Technology Blog
Netflix'in mühendisleri servis bağımlılıklarının gerçek zamanlı ve birleşik bir görünümüne ihtiyaç duyuyordu: sorunları daha hızlı gidermek, bir arızanın etki yarıçapını (blast radius) anlamak ve dağıtık mimaride yol bulmak için. Çözüm çok kaynaklı: eBPF ağ akışları, IPC metrikleri ve dağıtık izleme (tracing) verileri, birbirinden fiziksel olarak ayrı grafik katmanlarında toplanıp ayrı ayrı ya da birleşik sorgulanabiliyor.
Ama yazının değeri mimaride değil, itirafta. Kendi cümleleriyle: ilk sürüm yerel ortamda kusursuz çalıştı. Üretim başka bir hikâyeydi. Sonra sayıyorlar: Kafka tüketicileri geride kaldı. Örnekler bellek yetersizliğine düştü. Bazı düğümler diğerlerinin 100 katı trafik aldı. Çöp toplama (GC) duraklamaları, asıl iş mantığından daha fazla CPU tüketti.
Mimarideki temel karar akış-öncelikli (streaming-first) olmak. Geleneksel servis topolojisi sistemleri toplu işleme kullanır: veriyi saatlik ya da günlük toplar, sonra tam anlık görüntüleri saklar. Orta ölçekte çalışır ama temel bir sorunu vardır — veriyi gördüğünde zaten eskimiştir. Bir üretim arızası sırasında bu işe yaramaz. Netflix bunun yerine çok-bölgeli Kafka akışlarından akış kayıtlarını ve Sunucu Gönderimli Olaylar (SSE) üzerinden IPC metriklerini sürekli alıp reaktif pipeline'lardan geçiriyor.
Öne çıkanlar
- "Bazı düğümler 100 kat trafik aldı" — dağıtık sistemlerde en sinsi problem sıcak nokta (hot partition): ortalama iyi görünür, birkaç düğüm yanar.
- GC duraklamalarının iş mantığından fazla CPU yemesi, JVM tabanlı yüksek hacimli sistemlerin klasik tuzağı.
- Toplu işleme yerine akış: arıza anında saatlik özet işe yaramaz, gerçek zamanlı gerekir.
- Katmanları fiziksel olarak ayırmak, her veri kaynağının bağımsız ölçeklenmesini ve sorgulanmasını sağlıyor.
- Yazı bir başarı hikâyesi değil, açıkça bir öğrenme yolculuğu olarak sunuluyor.
Neden önemli?
Yeni mezun bir mühendisin en zor öğrendiği şey, "çalışıyor" ile "ölçekte çalışıyor" arasındaki farktır. Bu yazı o farkı listeleyerek gösteriyor: aynı kod, aynı mantık — ama veri hacmi ve eşzamanlılık değişince tamamen farklı bir sistem. Bu tür açık sözlü yazılar, yıllarca üretim deneyimi olmadan öğrenilemeyecek şeyleri öğretir.
Sende karşılığı
Bu yazıyı iki kere oku ve şu üç şeyi not al. Bir: sıcak nokta problemi — Tradebot'ta veriyi sembole göre bölümlediysen, işlem hacminin %60'ı BTC'deyse o bölüm diğerlerinin katbekat yükünü taşır. Bölümleme anahtarını seçerken dağılıma bak, isme değil. İki: tüketici geride kalması (consumer lag) — bir kuyruk sisteminde en kritik metrik budur ve mutlaka alarma bağlanmalıdır; Redis Streams ya da Kafka fark etmez. Üç: GC — Java tarafında yüksek hacimli bir servis yazıyorsan, GC log'larını açıp duraklama sürelerine bakmayı öğren. "Uygulama yavaş" şikâyetlerinin şaşırtıcı bir kısmının cevabı orada.
Sözlük
- blast radius etki yarıçapı
- Bir bileşen arızalandığında etkilenen diğer bileşenlerin kapsamı.
- eBPF eBPF
- Linux çekirdeğinde güvenli şekilde kod çalıştırıp ağ ve sistem olaylarını gözlemlemeyi sağlayan teknoloji.
- consumer lag tüketici gecikmesi
- Bir kuyruk tüketicisinin, üretilen mesajların ne kadar gerisinde kaldığı; kuyruk sistemlerinin en kritik sağlık metriği.
- hot partition sıcak bölüm
- Yükün dengesiz dağılması sonucu diğerlerinden kat kat fazla trafik alan bölüm ya da düğüm.
- garbage collection (GC) pause çöp toplama duraklaması
- JVM'in kullanılmayan belleği temizlerken uygulamayı kısa süre durdurması; sık olursa gecikmeyi ciddi bozar.