Dağıtık sistemlerde en pahalı arızalardan biri “tam bozuk olmayan node” problemidir. Node ayaktadır, health check geçer, CPU normaldir; ama gecikme üretir, bazı istekleri 500 döndürür ya da TLS handshake’lerinde sürtünme yaşatır. Yük dengeleyici bunu normal üye gibi görür ve kötü davranışı tüm trafiğe yayar.
Bu noktada Envoy outlier detection, arızalı örnekleri geçici olarak havuz dışına alarak blast radius’i küçültür. Ama yanlış eşiğe ayarlanırsa, bu kez sağlıklı node’ları da haksız yere cezalandırabilir.
1) Hangi problem sınıfını çözer?
Outlier detection özellikle şu durumlarda değerlidir:
- Bir veya birkaç pod aniden yüksek hata oranı üretir
- Bağlantı kuruluyor ama tail latency patlıyor
- Üye health check geçiyor, fakat uygulama işlevsel olarak bozuk
Bu mekanizma, root cause yerine geçmez. Yani bug’ı çözmez; sadece sistemin tamamını etkileyen yayılımı azaltır.
2) Sinyal: neye göre dışlayacağım?
Envoy tarafında tipik seçenekler:
- consecutive 5xx
- gateway failure
- success rate düşüşü
- local origin failure
Buradaki tuzak, tek sinyalle her problemi çözmeye çalışmaktır. Örneğin yalnızca consecutive_5xx kullanırsanız yüksek latency ama düşük hata üreten node gözden kaçabilir. Yalnızca success rate kullanırsanız düşük hacimli servislerde yanlış pozitif üretirsiniz.
3) Tasarım: agresif değil, kontrollü izolasyon
Benim tercih ettiğim yaklaşım:
- Önce dar kapsamlı servislerde başla
- Dışlama süresini kısa tut
- Maksimum ejection yüzdesini sınırlı tut
- Alarm ve dashboard olmadan açma
Örnek ilke:
- Üç kez ardışık 5xx → geçici dışla
- Dışlama 30–60 saniye
- Aynı anda havuzun en fazla %20–30’u dışlanabilir
Böylece tek node problemi yayılmaz; ama sistem kendi kendini tamamen boşaltmaz.
4) Operasyon: hangi dashboard işe yarar?
Asgari görünürlük seti:
- Ejected host sayısı
- Ejection nedeni
- Servis başarı oranı
- P95/P99 latency
- Retry hacmi
Retry metriği özellikle önemlidir. Çünkü outlier detection ile birlikte retry patlarsa, sağlıklı üyeler üzerine yeni baskı kurarsınız.
5) Runbook: dışlama artıyorsa neye bakarım?
- Tek node mu, genel bozulma mı?
- Eğer çok sayıda üye dışlanıyorsa eşik veya upstream genel bozuk olabilir.
- Common dependency var mı?
- Aynı cache, DB veya auth bağımlılığı tüm üyeleri etkiliyor olabilir.
- Retry zinciri ne durumda?
- İstemci, gateway ve sidecar aynı anda retry yapıyorsa problem büyür.
- Rollback gerekir mi?
- Yanlış tuning, gerçek arızadan daha büyük kesinti üretebilir.
6) Ne zaman kapatırım, ne zaman genişletirim?
Şu durumlarda kapsamı daraltırım:
- Düşük trafikli servislerde yanlış pozitif yüksekse
- Ortak bağımlılık hatasında tüm havuz dışlanmaya yaklaşıyorsa
- Uygulama hatası yerine ağ veya DNS sorunu varsa
Şu durumlarda genişletirim:
- Uzun süredir aynı sınıf node kusurları yaşanıyorsa
- Hata oranı düşük ama tail latency kaynaklı kullanıcı etkisi netse
- Sağlam dashboard ve rollback yolu hazırsa
Sonuç
Envoy outlier detection, dağıtık sistemlerde “bozuk ama ölmemiş node” problemini izole etmek için çok güçlüdür. Ancak etkisi, tuning disiplini ve görünürlükle doğru orantılıdır. Başarılı uygulama; ejection eşiği, retry bütçesi ve rollback planını birlikte tasarlamaktır. Amaç akıllı görünmek değil, arızalı üyeyi hızlı ayırıp kalan sistemi sakin tutmaktır.