Bir uygulama yavaşlıyor. İstemci yanıt alamayınca yeniden deniyor. Aradaki servis de kendi isteğini tekrarlıyor. Birkaç saniyelik aksaklık geçse bile sistemin önündeki kuyruk uzamaya devam ediyor. Kullanıcı sayısı değişmediği hâlde istek sayısı artıyor; ekip kapasiteye bakarken uygulama aynı işi tekrar tekrar gönderiyor.
Retry, yani başarısız bir işlemi yeniden denemek, geçici hatalarda gerçekten işe yarar. Fakat nerede başlayıp nerede duracağını belirlemezsek, kurtarma mekanizması kesintiyi besleyebilir. Özellikle birden fazla ekibin yönettiği servislerde bu davranış kolayca gözden kaçar.
Bir kullanıcı işlemi kaç isteğe dönüşüyor?
Üç katmanlı basit bir çağrı zinciri düşünelim. Her katman, ilk çağrı dâhil toplam üç denemeye izin veriyor olsun. Alt servis sürekli hata verirse tek bir kullanıcı işlemi en altta 3 × 3 × 3, yani 27 denemeye kadar çıkabilir. Burada “üç retry” ile “toplam üç deneme” arasındaki fark da önemli; ürünlerin ayar adları aynı şeyi anlatmayabilir.
Google SRE'nin zincirleme arızalar bölümü, katmanlara yayılan tekrarların yükü nasıl çarptığını açıklıyor. İncelemeye istemci, API geçidi, uygulama ve kullanılan SDK'nın retry davranışını aynı çizimde göstererek başlamak faydalı. Hangi katmanın karar verdiği ve diğerlerinin ne yaptığı açık olsun.
Timeout değerini düşürmek her zaman hız kazandırmaz
Timeout, istemcinin ne kadar bekleyeceğini sınırlar. Çok kısa seçildiğinde tamamlanabilecek çağrıları yarıda bırakıp yeni denemeler üretebilir; çok uzun seçildiğinde bekleyen işler kaynakları daha uzun süre tutar.
AWS'nin timeout, backoff ve jitter rehberi, değeri seçerken alt servisin gecikme dağılımını ve ağ koşullarını dikkate almayı öneriyor. Ortalamaya bakmakla yetinmeyin. Yoğun saatleri, yüksek yüzdelik dilimleri ve yeni bağlantı kurulurken geçen süreyi inceleyin. Kullandığınız istemcinin timeout kapsamına DNS çözümlemesi ile TLS el sıkışmasını katıp katmadığını da dokümanından doğrulayın.
Ayrıca tek denemenin süresiyle bütün işlemin bekleme bütçesini ayrı yazın. Üç deneme, aradaki beklemelerle birlikte kullanıcının kabul edebileceği sürenin dışına çıkabilir.
Bekleme aralığı kadar dağılımı da önemli
Exponential backoff, başarısız denemeler arasındaki beklemeyi giderek artırır. Jitter ise bu beklemeye rastgelelik ekler. Bin istemci aynı anda hata alıp aynı süre beklerse yeniden birlikte yüklenebilir; jitter bu kümelenmeyi azaltmaya yardımcı olur.
Yalnızca bekleme eklemek yeterli olmaz. Tek bir işlem için deneme sınırı, toplam süre sınırı ve servis genelinde tekrar yükünü sınırlayan bir bütçe birlikte düşünülmeli. Bu bütçe yeni isteklerle tekrarların birbirini boğmasını önlemeye yardımcı olur. Her sistem için geçerli sabit bir deneme sayısı yok; karar, işlemin maliyetine ve beklenen hata türüne bağlı.
Yanıt gelmediğinde işlem yine de gerçekleşmiş olabilir
Bir kaynak oluşturma çağrısı başarılı olmuş, fakat yanıt istemciye ulaşmamış olabilir. Aynı çağrıyı yeniden göndermek ikinci bir kaynak oluşturabilir. Bu yüzden tekrar güvenliği konuşulurken idempotency, yani aynı işlemin tekrarında ek bir yan etki oluşmaması, ayrıca değerlendirilmeli.
AWS'nin idempotent API tasarımı açıklaması, istemcinin verdiği benzersiz işlem kimliğini bu amaçla kullanıyor. Böyle bir mekanizma varsa aynı mantıksal işlemin tekrarlarında kimliğin korunması gerekir. Ancak anahtarın kapsamı, saklanma süresi ve farklı parametrelerle kullanım davranışı hizmete bağlıdır. Başlığa rastgele bir kimlik eklemek tek başına güvence sağlamaz; sunucunun bu sözleşmeyi desteklemesi gerekir.
İlk kontrolde beş soruya cevap arayın
- Aynı işlem için hangi katmanlar tekrar deniyor?
- Hangi hatalar geçici kabul ediliyor, hangi durumda hemen duruluyor?
- Deneme sayısı ve toplam bekleme süresi nerede sınırlanıyor?
- Sonradan başarılı olan tekrarlar dâhil, retry oranı ölçülüyor mu?
- Alt servis toparlandığında birikmiş işler nasıl ve hangi hızla geri dönüyor?
Microsoft'un Retry pattern rehberi, politikanın hata türüne ve işin ihtiyacına göre seçilmesini vurguluyor. Geçersiz bir isteği değiştirmeden tekrar göndermek çoğu durumda yalnızca aynı hatayı üretir. Etkileşimli bir ekranla gece çalışan toplu işin bekleme beklentisi de farklıdır.
Kontrollü bir test ortamında kısa süreli gecikme ve geçici hata senaryolarını deneyin. Kullanıcı işlemi sayısını, toplam çağrıları, retry oranını ve tamamlanma süresini yan yana izleyin. Üretimde bütün tekrarları bir anda kapatmak yerine, değişikliği küçük kapsamda ve geri dönüş planıyla değerlendirin. İyi tasarlanmış bir retry politikası, sistem yavaşladığında ne kadar ısrar edeceğini ve ne zaman duracağını bilir.
Yorumlar (0)
Henüz onaylanmış yorum yok.