Reliability Friday 09: Load Balancer Retry'ları Backend Trafiğini Nasıl Katlar?

Kısa cevap: Kullanıcınız ya da trafiğiniz artmadı, ancak backend request sayısı dokuz katına çıkabilir. Kullanıcı yalnızca bir request gönderdiğini düşünür; o request client, CDN / WAF, load balancer, ingress ve service katmanlarından geçer ve bu katmanların her biri kendi retry politikasına sahip olabilir. Client 1 initial attempt + 2 retry = 3 attempt, load balancer her client attempt'i için 1 initial attempt + 2 retry = 3 attempt: sonuç 3 × 3 = 9. Bir request, backend'de bir request olarak kalmayabilir.

Don't Deploy on Friday. Verify on Friday.

Bu haftanın kontrolü

Sisteminizde retry yapan katmanları bulun: client / SDK, CDN / WAF, load balancer, ingress / service mesh, application.

# NGINX
nginx -T 2>&1 | grep -E 'proxy_next_upstream|proxy_next_upstream_tries|proxy_next_upstream_timeout'

# HAProxy
grep -E 'retries|retry-on|redispatch' /etc/haproxy/haproxy.cfg

Kaç katmanın retry yaptığını biliyor musunuz?

Beklenen çıktı

NGINX'te proxy_next_upstream yönergesi varsa load balancer retry yapıyor demektir; proxy_next_upstream_tries ve proxy_next_upstream_timeout o retry'ın sınırını söyler. Sınır yazılmamışsa NGINX, upstream grubundaki her sunucuyu sırayla dener. HAProxy'de retries deneme sayısını, retry-on hangi hatalarda deneneceğini, redispatch ise denemenin başka bir sunucuya yönlendirilip yönlendirilmeyeceğini belirler.

Çıktının kendisi bir sorun değil. Sorun, bu satırların kaç katmanda birden geçtiğini kimsenin saymamış olmasıdır. Aynı sorguyu client SDK'nın, CDN / WAF'ın ve ingress / service mesh'in ayarlarında da tekrarlayın.

Gizli trafiği ölçün. İzlenmesi gereken temel oran:

Upstream Attempts / Incoming Requests   hedef ≈ 1

Bu oran 1'den uzaklaşıyorsa sistemin görünmeyen trafiği büyüyor demektir. Birlikte izleyin: retry rate ve retry reason, exhausted retries, backend saturation, timeout ve p99 latency, duplicate transaction, retry sonrası başarı oranı.

Ne zaman aksiyon alınmalı

Oranın kabul edilebilir değeri sizin hedeflerinize bağlı; ancak oran 1'den uzaklaşırken backend saturation ve p99 latency birlikte yükseliyorsa retry'lar artık isteği kurtarmıyor, kesintiyi besliyordur. Retry sonrası başarı oranı düşüyorsa aynı şey geçerli: başarısız olan retry, sadece incident'a yeni trafik ekler.

Risk

Arıza döngüsü şöyle işler: backend yavaşlar, timeout'lar başlar, client ve load balancer retry eder, backend daha fazla request alır, latency ve timeout daha da yükselir, döngü başa döner. Retry, kısmi arızayı tam kesintiye çevirebilir.

İkinci risk trafikle ilgili değil. Retry edilen işlem POST /orders, POST /payments ya da PATCH /inventory ise ikinci attempt yalnızca trafik yaratmayabilir, aynı işlemi yeniden gerçekleştirebilir: duplicate order, double payment, yanlış inventory, tekrarlanan notification. Non-idempotent request'lerde retry bir availability ayarı değil, data consistency riskidir.

Otomatikleştirin

Haftalık elle kontrol bir başlangıçtır, varılacak yer değil. Retry politikalarını kodda ve konfigürasyonda görünür kılın:

Sadece geçici hatalarla sınırlayın.Toplam retry budget belirleyin.Exponential backoff ve jitter kullanın.Katmanlar arasında koordine edin.Non-idempotent işlemleri koruyun.

Sonra Upstream Attempts / Incoming Requests oranını panoya alın ve 1'den uzaklaştığında uyarı üretin; görünmeyen trafik böylece görünür olur. Katman envanteri ve bu panonun kurulumu gözlemlenebilirlik ve APM ile ağ mühendisliği hizmetlerimizin kapsamındadır.

Eclit notu

Retry is not free capacity. Bir retry request'i kurtarabilir; kontrolsüz retry outage'ı büyütebilir.

Serinin sitedeki önceki yazısında incident escalation matrisini doldurmuştuk; o kontrol kararın kimde olduğuyla ilgiliydi. Bu hafta kararı kimsenin vermediği bir trafiğin peşindeyiz. Önleyici bakım tarafı sistem güvenilirliği hizmetlerimizin kapsamındadır.

Every Friday. One Production Check.