Dağıtık sistemlerde hata istisna değil, olağan bir durumdur. Bir sigorta şirketi servisi birkaç saniyeliğine yanıt vermeyebilir, ağda kısa bir kesinti yaşanabilir veya karşı taraf anlık bir yük artışı nedeniyle istekleri geri çevirebilir. Bu geçici hataların çoğu, biraz beklenip yeniden denendiğinde kendiliğinden düzelir. Ancak yeniden denemenin nasıl yapıldığı, sistemin dayanıklılığını belirleyen kritik bir ayrıntıdır. Yanlış kurgulanmış bir retry mekanizması, küçük bir aksaklığı büyük bir kesintiye dönüştürebilir.
Neden "hemen tekrar dene" yaklaşımı tehlikelidir?
Bir şirket servisinin yoğunluk nedeniyle yavaşladığını düşünelim. Bu servise istek gönderen bütün istemciler hata aldıklarında anında yeniden denerse, servise gelen trafik bir anda katlanır. Zaten zorlanan servis daha da yavaşlar, daha fazla hata döner, daha fazla yeniden deneme tetiklenir. Bu kısır döngüye literatürde "retry fırtınası" denir. Sonuçta kısa sürede toparlanabilecek bir servis, istemcilerin iyi niyetli ama kontrolsüz denemeleri yüzünden uzun süre ayağa kalkamaz.
Hangi hatalar yeniden denenmeli?
İlk karar, hatanın geçici mi kalıcı mı olduğudur. Kalıcı hataları tekrar denemek yalnızca kaynak israfıdır.
Yeniden denemeye uygun durumlar
- Bağlantı kurulamaması veya bağlantının yarıda kopması
- Zaman aşımı
- Karşı servisin geçici olarak hizmet veremediğini bildiren yanıtlar
- Hız sınırına takıldığını bildiren yanıtlar (bu durumda karşı tarafın önerdiği bekleme süresine uyulmalıdır)
Yeniden denenmemesi gereken durumlar
- Kimlik doğrulama veya yetki hataları
- İstek biçiminin geçersiz olduğunu bildiren yanıtlar
- İş kuralı reddi, örneğin aracın sorgulanan branşta teminata uygun bulunmaması
Bu ayrımı her şirket entegrasyonu için ayrı ayrı yapmak gerekebilir; çünkü şirketler aynı durumu farklı kodlar veya mesajlarla bildirebilir. Entegrasyon katmanı, bu farklı yanıtları ortak bir hata sınıflandırmasına çevirmelidir.
Üstel geri çekilme nasıl çalışır?
Üstel geri çekilme (exponential backoff), her başarısız denemeden sonra bekleme süresini katlayarak artırma yöntemidir. İlk denemeden sonra kısa bir süre beklenir, ikinci denemeden sonra bu sürenin iki katı, üçüncüden sonra dört katı ve böyle devam eder. Böylece karşı servise toparlanması için giderek artan bir zaman tanınır.
Bu artışın bir üst sınırı olmalıdır. Aksi halde bekleme süresi kısa sürede kabul edilemez uzunluklara ulaşır. Ayrıca toplam deneme sayısı da sınırlanmalıdır. Belirlenen sayıda denemeden sonra hâlâ başarı yoksa işlem başarısız sayılır ve uygun hata yönetimine devredilir.
Rastgele sapma (jitter) neden şart?
Yalnızca üstel geri çekilme kullanıldığında ince bir sorun ortaya çıkar. Aynı anda hata alan yüzlerce istemci, aynı formülle hesaplanan aynı bekleme sürelerinin sonunda aynı anda yeniden dener. Trafik yine dalgalar halinde gelir. Rastgele sapma, her istemcinin bekleme süresine rastgele bir bileşen ekleyerek bu senkronizasyonu kırar. İstekler zamana yayılır ve karşı servis daha dengeli bir yükle karşılaşır.
Uygulamada yaygın tercih, hesaplanan üst sınır ile sıfır arasında rastgele bir değer seçmektir. Bu yöntem basit olmasına rağmen yük dağılımında belirgin bir iyileşme sağlar.
Deneme bütçesi: Sistemi bütün olarak korumak
Tek tek isteklerin deneme sayısını sınırlamak yeterli değildir. Sistem genelinde yeniden denemelerin toplam trafiğe oranı da izlenmelidir. Deneme bütçesi yaklaşımında, belirli bir zaman diliminde yapılan yeniden denemeler, başarılı ilk isteklerin belirli bir oranını aşamaz. Bu oran aşıldığında yeni yeniden denemeler durdurulur. Böylece bir şirket servisi tamamen çöktüğünde, yeniden denemeler sistemin geri kalanını boğmaz.
Zamana duyarlı işlemlerde retry
Acente yazılımında her işlemin zaman toleransı farklıdır. Müşteri karşıdayken başlatılan bir trafik sorgusunda kullanıcı uzun süre bekleyemez; burada az sayıda ve kısa aralıklı deneme yapılıp sonuç hızla bildirilmelidir. Kasko sorguları genellikle daha fazla veri girişi ve daha uzun şirket yanıt süreleriyle çalıştığı için biraz daha toleranslı olabilir. DASK sorgularında ise adres doğrulama adımı ayrı bir dış çağrı olabileceğinden, her adımın kendi retry politikası tanımlanmalıdır.
Arka planda çalışan işlerde, örneğin gece yapılan poliçe durumu senkronizasyonunda, daha uzun aralıklar ve daha fazla deneme kabul edilebilir. Retry politikasını işlem türüne göre ayarlamak, tek bir genel ayardan çok daha iyi sonuç verir.
Retry ile idempotency ilişkisi
Yeniden deneme, isteğin ilk seferde karşı tarafta işlenmiş olma ihtimalini her zaman taşır. Yanıt yolda kaybolmuş olabilir. Bu nedenle yeniden denenen her işlemin idempotent olması, yani tekrarlandığında mükerrer kayıt üretmemesi gerekir. Özellikle poliçeleştirme gibi kalıcı sonuç doğuran işlemlerde, yeniden denemeden önce işlemin durumunu sorgulamak daha güvenli bir yoldur.
Karşı tarafın sinyallerine uymak
Bazı servisler, hız sınırına takılan veya geçici olarak hizmet veremeyen istemcilere ne kadar beklemeleri gerektiğini yanıt başlığında bildirir. Bu bilgi mevcutsa, kendi hesaplanan bekleme süresi yerine karşı tarafın önerdiği süre esas alınmalıdır. Karşı servisin sinyalini görmezden gelip kendi takvimine göre deneyen bir istemci, hem gereksiz reddedilir hem de bazı durumlarda daha uzun süreli engellemelere maruz kalabilir. Retry kütüphanesi seçerken veya yazarken bu başlıkları okuyabilmesi temel bir gereksinim olarak değerlendirilmelidir.
Katmanlar arasında çifte deneme tuzağı
Sık gözden kaçan bir sorun, birden fazla katmanın aynı anda yeniden deneme yapmasıdır. Mobil uygulama üç kez dener, API sunucusu her istek için üç kez dener, entegrasyon işçisi de her çağrıyı üç kez dener. Sonuçta tek bir kullanıcı işlemi, karşı servise yirmiden fazla istek olarak ulaşabilir. Bu çarpan etkisini önlemek için yeniden denemenin tek bir katmanda, tercihen dış servise en yakın katmanda yapılması ve diğer katmanların hızla hata bildirmesi önerilir.
Gözlemlenebilirlik
Retry mekanizması sessiz çalıştığında sorunları gizleyebilir. Her şey sonunda başarılı görünür ama arka planda istekler üç dört denemede tamamlanıyordur. Bu yüzden deneme sayılarının şirket ve branş bazında ölçülmesi gerekir. Yeniden deneme oranındaki artış, çoğu zaman tam bir kesintiden önce gelen erken bir uyarıdır.
InsureHub bakışıyla özet
InsureHub, sigorta acentelerine yazılım sağlayan bir platform olarak sigorta şirketi entegrasyonlarında geçici hataların kullanıcı deneyimini bozmamasını, kalıcı hataların ise hızla ve açıkça bildirilmesini hedefler. Sigorta teklif programı tarafında doğru kurgulanmış bir retry stratejisi, kullanıcının gereksiz yere tekrar sorgu başlatmasını önler. Bu sistemin nasıl davrandığını kendi senaryolarınızla görmek isterseniz demo talebi oluşturabilirsiniz.