Mechanizm ratunkowy może zamienić mały problem w całkowitą awarię przez retry storm
Retry zwiększa szansę powodzenia przy sporadycznych błędach, ale podczas przeciążenia może działać jak dodatnie sprzężenie zwrotne. Serwer zaczyna odrzucać niewielką część żądań, klienci natychmiast je ponawiają, więc ruch rośnie. Większy ruch powoduje więcej błędów, a te generują jeszcze więcej retry. Google SRE opisuje przykład, w którym naiwnie ponawiane żądania stopniowo zwiększają QPS aż backend może się „stopić”, a awaria jednej repliki przerzuca obciążenie na pozostałe i uruchamia kaskadę. Mechanizm zaprojektowany do zwiększania niezawodności może więc obniżyć ją właśnie wtedy, gdy system jest najsłabszy.
Retry działa świetnie przy rzadkich błędach
Jeśli jedno żądanie na tysiąc ginie przez chwilowy problem sieciowy, druga próba najczęściej rozwiązuje problem prawie za darmo. Dlatego retry jest tak powszechne w bibliotekach klienckich i SDK.
Przeciążenie zmienia znak sprzężenia
Załóżmy, że backend jest w stanie obsłużyć określoną liczbę żądań. Gdy ruch nieco przekracza limit, część żądań zaczyna kończyć się błędem. Jeśli każdy błąd natychmiast tworzy następne żądanie, klient dodaje ruch dokładnie w chwili, gdy serwer najmniej może go przyjąć.
Google pokazuje narastającą spiralę
W rozdziale o cascading failures Google SRE prezentuje model, w którym niewielkie przeciążenie tworzy retry, retry zwiększają QPS, przez co rośnie liczba odrzuceń i kolejnych retry. Jeśli przeciążona instancja w końcu pada, jej normalny ruch trafia na inne repliki, które również mogą przekroczyć granicę.
Warstwy mogą mnożyć problem
Jeszcze gorzej jest wtedy, gdy retry wykonuje kilka poziomów stosu. Google podaje przykład trzech warstw, z których każda może wykonać trzy retry, czyli cztery łączne próby na warstwę. Jedna akcja użytkownika może wtedy wygenerować aż 64 próby do najniższej zależności. To wykładnicze wzmocnienie lokalnie rozsądnych decyzji.
Ratunek polega na ograniczaniu dodatniego sprzężenia
Stosuje się limity liczby ponowień, budżety retry, exponential backoff, jitter oraz rozróżnienie błędów trwałych i tymczasowych. Najważniejsza zasada brzmi: klient nie może traktować serwera pod presją jak maszyny, którą należy zmusić do odpowiedzi jeszcze większą liczbą żądań.
Retry storm może utrzymywać awarię po zniknięciu pierwotnej przyczyny
Jeśli serwer był przeciążony tylko chwilowo, nagromadzona fala ponowień może nadal dostarczać więcej pracy niż jego normalna pojemność. Wtedy system nie wraca do stabilności, mimo że początkowy spike już minął. Google zwraca uwagę, że w niektórych przypadkach trzeba radykalnie ograniczyć ruch, aby zatrzymać retry i pozwolić backendom się ustabilizować.
Budżet retry traktuje ponowienia jako ograniczony zasób
Zamiast pozwalać każdemu żądaniu próbować niezależnie wiele razy, proces może mieć wspólny limit ponowień. Gdy liczba błędów rośnie, budżet się wyczerpuje i system przestaje wzmacniać problem. To ważna zmiana perspektywy: retry nie jest darmowym mechanizmem niezawodności, ale dodatkowym ruchem, który trzeba planować podobnie jak każdą inną pojemność.
Najniebezpieczniejsze jest to, że wykres błędów może sugerować, iż retry są tylko reakcją na awarię, choć w rzeczywistości stały się jej głównym paliwem. Operator widzi wysoką liczbę 5xx i naturalnie szuka przyczyny w backendzie, podczas gdy część obciążenia pochodzi już z warstwy recovery. Dlatego dobre observability rozdziela ruch pierwotny od ponowień i pokazuje liczbę prób przypadających na jedną logiczną operację.
Circuit breaker jest innym narzędziem ograniczającym spiralę. Jeśli zależność przez pewien czas wyraźnie zawodzi, klient może przestać wysyłać kolejne próby i okresowo sprawdzać, czy usługa wróciła. Dzięki temu awaria downstreamu nie zużywa wszystkich zasobów upstreamu. Retry, backoff, jitter, breaker i load shedding są więc elementami jednego układu sterowania przepływem, a nie niezależnymi sztuczkami. Dlatego podczas incydentu ograniczenie retry może być równie ważne jak samo zwiększenie mocy backendu.