Mikroservislerde her şey kısmen arızalanabilir. 8 servisten 1'i düştü. Sonuç, tam bir kesintiden daha kötüydü.

Senaryo:

  • Kullanıcı akışı: sırayla 8 servis
  • Servis 6 (öneriler): deneme başına %50 hata oranı
  • Circuit breaker yok, fallback yok
  • Retry politikası: her biri 30 saniye timeout'lu 3 deneme

Kullanıcıların yaşadığı:

  • İsteklerin yaklaşık yarısı ilk denemede başarılı oldu
  • Geri kalanın çoğu “eninde sonunda” başarılı oldu — bir ya da iki 30 saniyelik timeout'u bekledikten sonra
  • Kabaca her 8 istekten 1'i üç denemeyi de tüketip 90+ saniye sonra başarısız oldu
  • Kullanıcılar sayfayı yeniledi → zaten arızalı olan servise daha fazla yük
  • O 30 saniyelik beklemelerde bloke olan thread'ler tüm upstream servislerde havuzları tüketti — her şey degrade oldu

En kötü yanı:

  • Panolar “Servis 6: %50 sağlıklı” gösteriyordu
  • Kullanıcıya yansıyan deneyim: %0 kullanılabilir
  • Net bir sahibi yok (kısmi arıza kimin suçu?)

Çözüm:

  • Tüm dışa giden çağrılarda circuit breaker
  • Zarif bozulma (graceful degradation): sayfayı önerisiz göster
  • Saniye değil, milisaniye cinsinden ölçülen timeout'lar
  • Arızaları izole etmek için bulkhead deseni

Bu tür dayanıklılık desenleri DevOps ve güvenilirlik çalışmalarımızın standart kapsamındadır — onları olayın ortasında sonradan eklemek, öğrenmenin pahalı yoludur.

Ders: Dağıtık sistemlerde önce kısmi arızaya göre tasarlayın.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Mikroservisler #Güvenilirlik #HataYönetimi #DağıtıkSistemler