Kuyruk çökerse uygulaman ne yapar? Hipotezli bir dayanıklılık deneyi kurmak
Testing application resilience with Amazon SQS and AWS Fault Injection Service · Richard Whitworth
Uygulaman SQS kuyruğuna mesaj gönderemez ya da alamaz hâle gelirse, aşağı akıştaki işleme durur. Sebep yanlış yapılandırılmış bir IAM politikası, ağ bölünmesi, kötü bir dağıtım ya da geçici bir servis olayı olabilir; uygulamanın gördüğü hep aynı: SQS işlemleri başarısız oluyor. Servislerin bu hatayı nasıl ele aldığı (kaçınılmaz olanı hızlı başarısız saymak, devre kesici açmak, üretici tarafında tamponlamak) kısa bir aksaklıkla zincirleme bir kesinti arasındaki farkı belirleyebilir. Yazının ana cümlesi: bu mekanizmaları arıza altında hiç test etmediysen, varsayımlara güveniyorsun.
Deneyin amacı SQS'in çalıştığını doğrulamak değil, SQS işlemleri başarısız olunca uygulamanın ne yaptığını ve bunu fark edip etmeyeceğini öğrenmek. Yöntem: AWS Fault Injection Service (FIS) ve SSM Automation ile uygulamanın SQS'e erişimini kapsamı dar bir deny kaynak politikasıyla engellemek, sonra erişimi geri verip toparlanmayı gözlemek. Politika yalnızca uygulamanın bağımlı olduğu veri düzlemi işlemlerini reddediyor (gönderme, alma, silme, görünürlük süresini değiştirme, temizleme), kuyruk yönetimine dokunmuyor. Kesinti süresi dört aşamada kademeli artıyor: kısa kesintiler hata yönetim mekanizmalarının devreye girip girmediğini, uzun kesintiler ancak sürekli arızada ortaya çıkan sistemik sorunları gösteriyor.
İki arıza yüzeyi aynı anda izleniyor. Üretici tarafı: gönderim reddedilince hızlı başarısız mı oluyor, devre kesici mi açıyor, yerelde tamponluyor mu, yoksa mesajı mı düşürüyor? Tüketici tarafı: alma reddedilince birikim büyüyor mu, toparlanmada yeniden teslimat ve birikmiş yükle başa çıkış nasıl? Yazı kritik bir tuzağı da vurguluyor: **sqs:* işlemini reddetme.** IAM'de açık bir Deny her Allow'u geçer, otomasyonun kendi politikayı sonradan kaldırma iznini bile; kendi ellerinle kendini kilitlersin.
Öne çıkanlar
- İyi bir dayanıklılık deneyi ölçülebilir hipotez ve başarı ölçütüyle başlar: ne gözlemlemeyi bekliyorsun?
- Deney iki şeyi aynı anda test eder: kurtarma mekanizmaların ve gözlemlenebilirliğin (arızayı fark ettin mi?).
- Arızayı kademeli artır: kısa kesinti tepkiyi, uzun kesinti sistemik birikimi gösterir.
- Üretici ve tüketici tarafı farklı arıza davranışları sergiler; ikisini ayrı ölç.
- Arıza enjeksiyonunun kendisi bir arıza kaynağı olabilir: geri alma yolunu kesen bir Deny yazma.
Neden önemli?
Devre kesici, yeniden deneme ve tamponlama kodda yazılıdır ama çalışıp çalışmadığı yalnızca gerçek arıza altında bilinir. Bu yazı, ‘test ettiğimi sanıyorum’ ile ‘test ettim’ arasındaki farkı küçük, kontrollü ve geri alınabilir bir deneyle kapatıyor.
Sende karşılığı
Aynı deneyi yerelde, parasız yapabilirsin: bir Redis ya da PostgreSQL konteynerini docker stop ile durdur ve Spring Boot uygulamanın ne yaptığına bak. İstekler sonsuza dek mi asılıyor, zaman aşımı kaç saniye, hata kullanıcıya anlamlı dönüyor mu, alarm çalıyor mu? Hipotezini önce yaz (‘5 saniye içinde 503 dönmeli, 30 saniye sonra otomatik toparlanmalı’), sonra gözlemle. Çoğu projede ilk denemede en az bir sürprizle karşılaşırsın; Mobit’teki mesajlaşma altyapısında bunu yapmak tam bu tür bir sürprizi üretimden önce yakalamanın en ucuz yolu.
Sözlük
- chaos engineering kaos mühendisliği
- Sistemin arızaya dayanıklılığını, kontrollü biçimde arıza enjekte ederek önceden test etme pratiği.
- circuit breaker devre kesici
- Sürekli başarısız bir bağımlılığa istek göndermeyi geçici olarak durdurup sistemi koruyan desen.
- data plane vs control plane veri düzlemi / kontrol düzlemi
- Veri düzlemi gerçek işi (mesaj gönder/al) yapar; kontrol düzlemi kaynakları yönetir (kuyruk oluştur/ayarla).
- hypothesis-driven experiment hipotez güdümlü deney
- Ne olacağını önceden yazıp sonucu buna karşı ölçen deney kurgusu.