Do największej od lat awarii AWS doprowadził pojedynczy błąd w systemie DNS

itreseller.com.pl 6 dni temu

Amazon ujawnił szczegóły poważnej awarii, która 20 października sparaliżowała jego infrastrukturę chmurową. Problem, wywołany błędem w automatycznym systemie DNS usługi DynamoDB, doprowadził do kaskadowych usterek w wielu regionach i unieruchomił tysiące stron internetowych oraz aplikacji na wiele godzin.

Błąd w zarządzaniu DNS uruchomił lawinę

Z opublikowanego przez Amazon raportu wynika, iż źródłem problemu było tzw. race condition w systemie zarządzania DNS bazy danych DynamoDB, jednej z kluczowych usług AWS. Awaria rozpoczęła się 19 października o 23:48 czasu pacyficznego (7:48 UTC 20 października) w regionie US-EAST-1, który jest sercem infrastruktury chmurowej Amazona. Klienci zaczęli zgłaszać rosnącą liczbę błędów API DynamoDB, co w krótkim czasie przerodziło się w globalną awarię.

System DNS DynamoDB opiera się na dwóch niezależnych komponentach, DNS Plannerze oraz DNS Enactorze, które mają zapewniać odporność na błędy. Planner monitoruje stan obciążenia i tworzy plany DNS, a Enactor wdraża je poprzez usługę Route 53. Tym razem jednak opóźnienia w działaniu jednego z Enactorów sprawiły, iż drugi rozpoczął czyszczenie „starych” planów, w tym kluczowych rekordów DNS. W efekcie wszystkie adresy IP regionalnego punktu końcowego DynamoDB zostały usunięte, a system utracił spójność.

Do momentu manualnej interwencji żadne kolejne automatyczne aktualizacje DNS nie były możliwe. W rezultacie systemy korzystające z DynamoDB, w tym wewnętrzne komponenty AWS, zaczęły doświadczać awarii nazw domen.

Awaria Amazon Web Services i jej skutki: Milionowe straty i ponowne wezwanie do podziału gigantów technologicznych

Efekt domina: EC2, Lambda i EKS stanęły

Jak opisuje Amazon, skutki błędu DNS gwałtownie przeniosły się na inne usługi. Jedną z najbardziej dotkniętych był DropletWorkflow Manager (DWFM), czyli system odpowiedzialny za utrzymanie dzierżaw fizycznych serwerów EC2. Gdy DWFM nie był w stanie komunikować się z DynamoDB, procesy leasingowe zostały wstrzymane, co uniemożliwiło tworzenie nowych instancji EC2.

Po przywróceniu działania DynamoDB o 2:25 czasu pacyficznego (9:25 UTC) DWFM próbował odtworzyć dzierżawy na całej flocie serwerów, ale skala operacji doprowadziła do przeciążenia i tzw. „zapaści kongestywnej”. Dopiero po manualnej interwencji o 5:28 PDT (12:28 UTC) udało się przywrócić stabilność.

W tym czasie Network Manager rozpoczął rozsyłanie ogromnej liczby zaległych konfiguracji sieciowych, co powodowało dalsze opóźnienia w uruchamianiu instancji. Problemy objęły także Network Load Balancer (NLB), który błędnie uznawał nowe serwery EC2 za niesprawne z powodu braku odpowiedzi w testach zdrowia.

Kiedy uruchamianie instancji EC2 przestało działać prawidłowo, awaria objęła kolejne warstwy infrastruktury: Lambda, Elastic Container Service (ECS), Elastic Kubernetes Service (EKS) i Fargate. W efekcie w ciągu kilku godzin setki popularnych serwisów internetowych i aplikacji chmurowych na świecie przestały funkcjonować.

Amazon wyłącza automatyzację i przeprasza klientów

W odpowiedzi na incydent Amazon zdecydował się tymczasowo wyłączyć mechanizmy DNS Planner i DNS Enactor we wszystkich regionach AWS do czasu wdrożenia nowych zabezpieczeń eliminujących ryzyko ponownego wystąpienia błędu.

„Kontynuujemy analizę wszystkich szczegółów tego zdarzenia, aby znaleźć dodatkowe sposoby zapobiegania podobnym problemom i skrócić czas reakcji w przyszłości” – napisał Amazon w oficjalnym oświadczeniu.

Idź do oryginalnego materiału