Trzy Klasyczne Schematy Kaskadowe

Awarie Przechodzą Przez Zależności

Schemat 1: Burza heroldów. Zasób udostępniony (cache, blokada, baza danych) ulega awarii lub restartuje. Każdy klient, który na niego zależał, ponawia próbę jednocześnie. Fala zasypania przeciąża coś, co podniesione jest z powrotem; powtarzające się próby nakładają się szybciej niż rekonstrukcja może je wchłonąć; rekonstrukcja nigdy się nie zakończy.

Schemat 2: Burza powtórzeń. Usługa w dół zwalnia. Wyższe usługi, zamiast zawodzić, powtarzają próby. Powtarzające się próby mnożą pierwotny ładunek. Slowing usługi zwalnia dalej, wywołując więcej powtórzeń. Ostatecznie ładunek przekracza nawet zdrową wersję usługi.

Schemat 3: Śmierć kolejki. Kolejka przetwarzająca otrzymuje szybciej niż przetwarza. Kolejka rośnie nieskończenie. Pamięć wyczerpuje się; konsumenci zawodzą; restartują; znajdują większą kolejkę; zawodzą ponownie.

Wspólny wątek: mała perturbacja początkowa wyzwala pętlę zwrotnej wiązania. Odpowiedź systemu wzmacnia awarie zamiast tłumić je.

Mechanizmy Tłumienia

Powtarzające się cofanie z zakłóceniami eksponenialnymi. Klienci, którzy powtarzają próby, czekają dłużej każdorazowo, z losowym przesunięciem. Zapobiega synchronizacji fal powtórzeń.

Przerwa obwodowa. Wywołujący śledzi stopy awarii w dół. Po przekroczeniu progów, wywołujący przestaje wywoływać na okres ostudzenia i natychmiast zawodzi własne żądania zamiast.

Zabezpieczenie przed przeciążeniem. Odosobnienie zasobów na zależność. Pula połączeń A dla bazy danych, oddzielona pula połączeń B dla cache. Powolna baza danych nie może zagłodzić wszystkich połączeń; wywołania cache kontynuują.

Odrzucanie obciążenia. Gdy jest przeciążony, odrzucają żądania na krawędzi zamiast przyjmować i powoli zawodzić. 429 w 1 ms jest lepsze niż 500 w 30 sekund.

Wsteczne naciskanie. Powoli producenci, gdy konsumenci nie mogą utrzymać kroku. Kolejki stają się związane; nadawcy blokują; pierwotne źródło pracy odczuwa tarcie.

Diagnoza Kaskady

Wzmacnianie zespołu API osłabia się podczas rutynowego przełączania bazy danych. Schemat czasowy:

- 14:00:00 — operator promuje bazę danych rezerwową. Oczekiwana niedostępność: ok. 10 sekund.

- 14:00:08 — główna niedostępność. Błędy połączenia z baza danych zaczynają się pojawiać w warstwie API.

- 14:00:08 — warstwa API ponawia próby (domyślna konfiguracja: 5 prób, bez cofania, co 100 ms).

- 14:00:11 — rezerwowa baza danych jest promowana i akceptuje nowe połączenia.

- 14:00:11 — warstwa API otwiera tysiące nowych połączeń z bazą danych jednocześnie (każdy egzemplarz repliki × każde żądanie konkurencyjne × każda ponowna próba).

- 14:00:13 — nowa główna baza danych wyczerpuje pulę połączeń; nowe połączenia odrzucone.

- 14:00:13-14:05:00 — repliki warstwy API wyczerpują pulę połączeń, rzucają wyjątki, zawodzą, restartują się, powtarzają.

- 14:05:00 — operator ręcznie zatrzymuje ruch dla warstwy API; baza danych stabilizuje się.

- 14:10:00 — stopniowe przywrócenie ruchu kończy się. Całkowite wyjście z działania: ok. 10 minut (w zamierzeniu 10 sekund).

SERVFAIL DNS: Dwa Zgubne Wady

Prawdziwe Sprawozdanie z Wypadku

Następujące jest zsanitowaną wersją rzeczywistego incydentu. Nazwy firm zamienione, IP anonimizowane; kształt, czasoskład, a także nauki są prawdziwe.

Podsumowanie

Strona example.com zwracała SERVFAIL z wszystkich publicznych serwerów DNS przez około 3-4 godziny. Pozostałe 46 stref na tym samym serwerze DNS nie zostało dotkniętych. Przyczyna: dwa wzajemnie się nasilające wady.

1. Dostawca A (drugie tłumaczenie DNS) dodał nowy wewnętrzny IP synchronizacji, który nie był w allow-axfr-ips liście dopuszczalnych.

2. Strefa example.com miała kilkuletni konflikt CNAME naruszający RFC (demo.example.com miało zarówno CNAME, jak i MX/TXT rekordy na tym samym etykiecie), co spowodowało odrzucenie strefy przez dostawcę A na żywym AXFR.

Schemat czasowy (UTC)

- ok. 15:00 — Dostawca A dodaje nowy IP synchronizacji wewnętrznej 198.51.100.42 do swojej infrastruktury

- 15:02 — pierwsze AXFR-out denied dla 198.51.100.42 pojawia się w logach głównego DNS (brak ostrzeżeń tego sygnału)

- ~18:00 — osiągnięty okienek wygaśnięcia SOA; Wendor A usuwa strefę example.com z cache

- ~18:30 — wykrywane zewnętrznie SERVFAIL

- ~19:45 — zidentyfikowana przyczyna

- 20:00 — 198.51.100.42 dodany do allow-axfr-ips; główny zrestartowany

- 20:05 — wysłane NOTIFY; AXFR inicjowany; strefa Wciąż SERVFAIL (konflikt CNAME)

- 20:07 — check-zone odkrywa 1 błąd: konflikt CNAME na demo.example.com

- 20:09 — CNAME zastąpiony rekordem A; sprawdzanie strefy czyste (0 błędów)

- 20:10 — wysłane NOTIFY; AXFR zakończony; Vendor A zaczyna obsługiwać strefę

- 20:11 — dig @8.8.8.8 example.com A zwraca poprawny adres IP — ROZWIĄZANE

Dlaczego tylko example.com?

Wszystkie 47 stref dzieli tę sama DNS primary. Blok IP AXFR wpłynął na wszystkie strefy. Ale tylko example.com miał konflikt CNAME i tylko example.com potrzebował świeżego AXFR w chwili, gdy został nałożony zakaz. Inne strefy już odświeżyły się przed zakazem lub jeszcze nie musiały.

Skryty wada

Konflikt CNAME na demo.example.com istniał przez lata. Działało to, ponieważ główny serwował strefę z swojej bazy danych (leniwy wobec naruszeń RFC) i Vendor A służył dane z zapisu w pamięci przed wprowadzenie naruszenia. Gdy Vendor A usunął swoją pamięć cache i potrzebował świeżych danych, naruszenie wysunęło się na powierzchnię.

Spowodowanie

Vendor A w ciszy dodał nowy adres synchronizacji. Primary nie zawierał go w swoim zezwoleniu. AXFR odmówiono. Trzy godziny później (okienek wygaśnięcia SOA) Vendor A usunął strefę. Skryta wada wysunęła się na powierzchnię, gdy system próbował odzyskać.

Zapisz Bezkarnych Zadań Działaniowych

Bezkarny: Celuj w Systemy, a Nie w Ludzi

Bezkarny element działający nazwać musi coś, co system powinien zrobić inaczej, a nie coś, co osoba powinna zrobić inaczej. 'Szkolenie operatora' jest winne. 'Dodaj automatyczne sprawdzenie, które to zatrzyma przed wdrożeniem' jest bezkarny.

Dobrze napisane bezkarne elementy działające gromadzą się w trzech wymiarach:

- Profilaktyka: spraw, aby złe rzeczy były trudniejsze lub niemożliwe

- Wykrywanie: zauważyć je wcześniej, jeśli się zdarzy

- Odzyskiwanie: ograniczyć szkody, gdy się zdarza

Każdy element powinien nazwać (1) konkretne zmiany systemowe, (2) zespół właścicielski i (3) wymiar, który służy.

Kompartmenty, które toną bez statku

Zaciągane z inżynierii okrętowej

Okręty mają ściany wodoszczelne: pionowe ściany, które dzielą kadłub na kompartmenty. Jeden kompartment może zatopić się bez zatopienia statku; kolejny może nie działać bez wpływu na resztę.

Systemy rozproszone korzystają z tego samego słowa & tej samej idei.

Szyby wodoszczelne wzorca: izoluj zasoby na zależność. Usługa, która dzwoni do trzech różnych API zależności używa trzech oddzielnych pul połączeń, trzech oddzielnych pul wątków, trzech oddzielnych budżetów powtarzania. Jedna zależność downstream, która jest wolna lub się awanturuje, nie może używać zasobów przypisanych dla innych dwóch.

Bez szyb wodoszczelnych: jedna wolna zależność wyczerpuje wspólną pulę wątków; wywołania do innych zależności czekają na wątki; cała usługa staje się niedostępna.

Z szybami wodoszczelnymi: jedna wolna zależność wyczerpuje swoją własną pulę; wywołania do niej szybko się nie udają; wywołania do innych zależności kontynuują się normalnie; promieniowanie eksplozji jest związane z zależnością, która się awanturuje.

Zawory obwodowe

Wzorzec zaworu obwodowego: zabezpieczenie stanu, które otacza zależność downstream i śledzi szybkość awarii. Trzy stany:

- Zamknięty (normalny): wywołania przechodzą. Błędy są policzane.

- Otwarty (zawiony): gdy przekroczona jest próg awarii (np. 50% błędów w ciągu ostatnich 30 sekund), zawór się otwiera. Wywołania natychmiast się nie udają, nie próbując zależności. Zabezpiecza to wywołującego przed marnotrawieniem pracy; zabezpiecza to zależność przed otrzymywaniem obciążenia podczas jej niestrawności.

- Półotwarty (testujący): po okresie ostygania, zawór pozwala na mały procent wywołań. Jeśli się udają, zamyka z powrotem do normalnego stanu. Jeśli nie, znowu się otwiera na kolejne ostyganie.

Kluczowe odkrycie: zawór obwodowy zapobiega marnotrawieniu wysiłków podczas znanych okresów niestrawności & daje zależnościom szansę na odzyskanie bez ciągłego obciążenia.

Szyby wodoszczelne ograniczają promieniowanie eksplozji. Zawory obwodowe zapobiegają utrzymaniu się eksplozji.

Ogranicz promieniowanie eksplozji

Twój serwis API komunikuje się z czterema usługami docelowymi: Usługa Użytkownika, Usługa Rekomendacji, Usługa Powiadomień oraz API płatności trzeciej strony. Zespół słyszał, że "Usługa Rekomendacji bywa trochę niestała" i chce się upewnić, że gdy zawodzi, reszta systemu działa zdrowo.

Obecnie serwis korzysta z jednej wspólnej puli 200 wątków oraz jednej wspólnej puli połączeń HTTP. Wszystkie cztery usługi docelowe rywalizują o te zasoby. Brak obwodów przeciwprężnych.

Zaprojektuj recenzję trybu awaryjnego

Synteza

Nauczyłeś się wykrywać SPOFs przez inspekcję, rozpoznawać wzorce łańcuchowych błędów, oddzielać wyzwalacz od ukrytego błędu podczas czytania postmortem, pisać bezwzględne działania w zakresie profilaktyki, wykrywania i naprawy, oraz ograniczać zasięg eksplozji dzięki odcinkom, obwodom przeciwprężnym i stopniowej degradacji.

Zastosuj wszystkie pięć.

Twój zespół wkracza z nową usługą search.example.com, która zależy od trzech usług docelowych: głównego indeksu wyszukiwania (index.example.com), usługi analizy (analytics.example.com) oraz usługi rekomendacji (recs.example.com). Zespół chce, żebyś przeprowadził 'recenzję trybu awaryjnego' przed uruchomieniem.

Gdzie ta kurs idzie dalej

Gdzie ta kurs idzie dalej

Teraz możesz zauważyć SPOF, zrozumieć łańcuchowy błąd, czytać postmortem produktywnie, pisać bezwzględne działania i ograniczać zasięg eksplozji dzięki zaprojektowanym rozwiązaniom.

Ostatnia lekcja w tym kursie (cs_distsys_observability_and_capacity) nauczania, jakie warto pomiarów, aby dowiedzieć się, że problem występuje przed użytkownikami. Sprawdzanie stanu systemu, wersje punktów końcowych, cztery złote sygnały na poziomie proxy oraz jak decyzje o zdolnościach awaryjnych są związane z danymi obserwacyjnymi.

Lekcja towarzysząca: geometry_of_failure_modes_and_blast_radius wyjaśnia międzywęź centrality (który węzeł grafu jest butelką) i min-cut (górna granica promieniowania wybuchowego).

Brawo. Naprzód.