503 Service Unavailable: przeciążenie, konserwacja i Retry-After

Żywy, i odmawiający pracy

Żeby w ogóle zwrócić 503, coś musi działać: przyjęło połączenie TCP, sparsowało żądanie i wygenerowało odpowiedź. Ten pojedynczy fakt wyklucza całą klasę problemów. Host działa, ścieżka sieciowa funkcjonuje, TLS się zakończył, a serwer webowy albo proxy działa. Brakuje pojemności albo chęci.

RFC 9110 dodaje zastrzeżenie: serwer nie jest zobowiązany używać 503 przy przeciążeniu. Niektóre po prostu odmawiają połączenia zamiast tego. 503 jest więc grzeczną formą przeciążenia. Jeśli dostajesz odmowę połączenia albo przekroczenie limitu czasu zamiast 503, masz do czynienia z inną i zwykle gorszą awarią.

Łatwo pomylić dwóch sąsiadów. 504 Gateway Timeout oznacza, że backend został zaakceptowany, a potem nigdy nie odpowiedział na czas; żądanie zostało podjęte. 503 oznacza, że żądanie zostało odrzucone, zanim rozpoczęła się prawdziwa praca. Cała rodzina jest porównana w przeglądzie 5xx.

Retry-After i dlaczego zawsze powinieneś go wysyłać

RFC 9110 pozwala, żeby 503 niósł nagłówek Retry-After, w jednej z dwóch form: liczbie sekund do odczekania albo bezwzględnej dacie HTTP.

HTTP/1.1 503 Service Unavailable
Retry-After: 300
Content-Type: text/html

Nic to nie kosztuje. Dobrze zachowujący się klienci i biblioteki wycofują się na podany interwał, zamiast bombardować i tak już zmagający się serwer. Roboty wyszukiwarek traktują URL jako tymczasowo niedostępny i wracają później, zamiast traktować awarię jako usunięcie treści. Twój własny monitoring i narzędzia statusu dostają jawny oczekiwany czas powrotu do wyświetlenia.

503 domyślnie nie podlega buforowaniu, więc pośrednicy nie będą go dalej serwować po odzyskaniu sprawności przez usługę.

Co powoduje 503

• Przeciążenie. Wszystkie wątki robocze, procesy albo miejsca w puli połączeń są zajęte, więc nowe żądania są odrzucane, zamiast kolejkowane w nieskończoność. Zwykle zaczyna się przerywanie w godzinach szczytu i staje się stałe wraz ze wzrostem obciążenia.
• Tryb konserwacji. Celowy przełącznik, z flagi frameworka, pliku konserwacji albo reguły proxy. To 503 robiące dokładnie to, co powinno.
• Zależność nie działa. Dobrze napisana aplikacja, która nie może dotrzeć do swojej bazy danych, pamięci podręcznej albo kolejki, powinna zwracać 503, a nie zrzut stosu, bo stan jest tymczasowy i nie jest winą żądania.
• Brak zdrowych backendów. Load balancer, którego każdy element zawodzi kontrolę zdrowia, nie ma dokąd kierować ruchu, i wiele z nich w takim stanie zwraca 503.
• Wdrożenia i restarty. Okno między wygaszeniem starego procesu a gotowością nowego.
• Celowe odrzucanie obciążenia. Wyłączniki bezpieczeństwa (circuit breakers) i kontrola przyjęć celowo zwracają 503, żeby chronić części systemu, które wciąż działają.
• Wyczerpanie zasobów na poziomie hosta. Brak pamięci, brak deskryptorów plików albo pełny dysk, co uniemożliwia rozpoczęcie nowej pracy.

Wzorzec 503 podczas wdrożenia

To najczęstsze 503, które nie jest prawdziwym incydentem, i ma rozpoznawalny kształt: krótki wybuch 503, trwający od kilku sekund do paru minut, zaczynający się dokładnie przy wydaniu i kończący się sam. Skoreluj sygnatury czasowe z historią wdrożeń, zanim zbadasz cokolwiek innego.

Dobrze obsłużone 503 podczas konserwacji powinno:

1. Zwracać prawdziwy kod statusu. Strona konserwacji serwowana z 200 mówi crawlerom, że Twoja treść to teraz powiadomienie o konserwacji, co jest najgorszym możliwym wynikiem dla zaplanowanego okna.
2. Zawierać Retry-After z realistycznym szacowaniem długości okna.
3. Pozostawać statyczne i tanie. Strona konserwacji nie powinna zależeć od bazy danych ani aplikacji, którą właśnie wyłączyłeś.
4. Przepuszczać Twoje własne adresy, żeby zespół mógł zweryfikować nowe wydanie, zanim ponownie otworzy dostęp.
5. Być zaplanowane w monitoringu jako okno konserwacji, żeby planowana przerwa nie wzywała nikogo dyżurnego.

Naprawą dla nieplanowanych 503 podczas wdrożenia jest aktualizacja kroczącą bramkowana zdrowiem: uruchom nowy proces, poczekaj, aż przejdzie kontrolę gotowości, a potem wygaś i zatrzymaj stary. Zrobione właściwie, nie ma okna, w którym nic nie może obsłużyć ruchu.

Jak naprawić nieplanowane 503

1. Potwierdź kod i przeczytaj nagłówki, w tym czy wysłano Retry-After i który komponent podpisał odpowiedź:

   curl -sS -o /dev/null -D - https://example.com/

2. Najpierw wyklucz tryb konserwacji. Sprawdź, czy nie została flaga albo plik konserwacji pozostawiony po wydaniu. Zdarza się to częściej, niż ktokolwiek przyznaje.
3. Sprawdź zdrowie backendu. Na load balancerze spójrz, ile elementów przechodzi kontrole. Zero zdrowych elementów to natychmiastowa odpowiedź.
4. Spójrz na nasycenie. Użycie puli wątków i połączeń, pamięć, połączenia do bazy danych i głębokość kolejki. 503 pod obciążeniem, gdy wszystko jest na suficie, to kwestia pojemności, a nie błąd.
5. Sprawdź zależności. Jeśli baza danych, pamięć podręczna albo krytyczne API nie działają, napraw to, a nie warstwę webową.
6. Zmniejsz obciążenie, a potem znajdź przyczynę. Skalowanie w poziomie albo podniesienie limitów przywraca usługę, ale 503, które pojawiło się bez wzrostu ruchu, zwykle ukrywa wolne zapytanie albo wyciek, które wrócą.

503 w godzinach szczytu i zaplanowane okna konserwacji

503 z przeciążenia są zwykle przerywane na długo, zanim staną się stałe, pojawiając się w godzinach szczytu i ustępując same. Tę wczesną fazę łatwo przeoczyć z poziomu przeglądarki, a jest oczywista w ciągłym zapisie. Zaplanowane sprawdzenie HTTP, które potwierdza oczekiwany kod statusu, zamienia te rozproszone awarie w widoczny trend z przypisanymi czasami, dzięki czemu możesz zadziałać, zanim faza przerywana stanie się awarią. Planowanie okien konserwacji w tym samym narzędziu powstrzymuje planowane 503 przed generowaniem alertów.