Głupi błąd wysadził pół internetu. Oto co się stało w serwerowni Amazonu
Awaria AWS przypomniała w brutalny sposób, czym skutkuje centralizacja. Drobny i stosunkowo częsty błąd DNS w jednej serwerowni Amazonu na kilka godzin zdestabilizował internet
Poniedziałkowa, globalnie odczuwalna awaria Amazon Web Services - która wyłączyła dziesiątki usług AWS i setki platform: od Zooma i Slacka, po Adobe Creative Cloud i Canvę, a na Steamie i Pokemon GO kończąc - nie została wywołana cyberatakiem ani blackoutem energetycznym. Źródłem awarii była usterka na poziomie DNS w regionie US-EAST-1, najstarszym i najbardziej obciążonym "pasie transmisyjnym" całej chmury Amazona w stanie Północna Wirginia.
Awaria AWS pokazuje, że chmura nie wybacza centralizacji
DNS (Domain Name System) to system, który przekształca czytelne nazwy - takie jak spidersweb.pl - w numeryczne adresy używane przez komputery do komunikacji między sobą. Gdy ten system przestaje działać lub działa niepoprawnie, aplikacje nie potrafią odnaleźć właściwych serwerów - z perspektywy użytkownika wyglądają na "martwe".
Sytuację problemów z działaniem DNS można w prosty sposób porównać do dowozu paczek przez kuriera: kurier jest zdrowy, samochód mu działa, pojazd załadowany jest paczkami, ale nagle przestała mu działać nawigacja. Fizycznie kurier wciąż może dokonać dostawy, ale bez adresu i działającej mapy może co najwyżej jeździć w kółko czekając na ponowne działanie nawigacji
Problem uderzył akurat w warstwę odpowiedzialną za dostęp do baz danych w AWS (m.in. usługę DynamoDB), czyli w element, który stanowi bazodanowy kręgosłup wielu aplikacji: komunikatorów, sklepów, gier, bankowości, urządzeń smart home. Gdy aplikacje nie mogły odczytać danych z DynamoDB (bo DNS nie mógł ich przetłumaczyć), to jak kostki domina posypały się kolejne elementy platform i serwisów: logowanie, widoki konta, koszyki, płatności, a inteligentne sprzęty nie mogły łączyć się z chmurą.
Na problem z DNSem nałożył się drugi efekt domina: warstwa balansowania ruchu (m.in. Network Load Balancers) zaczęła odrzucać lub kolejkować żądania, bo z perspektywy infrastruktury Amazonu wyglądało to jak masowy wzrost błędów po stronie aplikacji. W usłudze EC2 pojawiły się podwyższone błędy przy uruchamianiu nowych instancji - co przełożyło się na opóźnienia w przywracaniu działania aplikacji, które próbowały “sklonować” nowe zasoby w reakcji na przeciążenie. Amazon przywrócił poprawne działanie DNS w południe czasu polskiego, ale zaległe żądania i ponowne próby tysięcy klientów jeszcze przez kilka godzin utrzymywały spowolnienie i błędy w ekosystemie chmury.
AWS może i wyłączył internet, ale wszczął alarm
Eksperci nie są zaskoczeni przyczyną, lecz skalą problemów.
- Ta awaria pokazuje, jak nawet największe środowiska chmurowe mogą zostać sparaliżowane przez z pozoru drobny element infrastruktury. Kiedy przestaje działać rozwiązywanie nazw domen, całe aplikacje mogą przestać odpowiadać, niezależnie od tego, jak dobrze są zaprojektowane
Szustak podkreśla jednocześnie, że incydent to czytelne ostrzeżenie: inżynierowie nie powinni zakładać, że jeden region chmury utrzyma cały biznes. Zapewnienie zapasowego środowiska i geograficzne rozproszenie zasobów powinny być normą, nie dodatkiem.
Jednocześnie AWS potwierdził, że incydent nie miał charakteru ataku i wskazuje na wewnętrzny błąd na poziomie konfiguracji lub propagacji DNS dla usług w US-EAST-1. Pełny post-mortem Amazon ma opublikować osobno. Na poziomie użytkownika internetu sprawa jest już zamknięta - aplikacje wstały. Na poziomie zaufania do centralizacji chmury - przeciwnie: to kolejny alarm dla Europejczyków, że jeden węzeł po przeciwnej stronie globu potrafi wyłączyć fragment świata.
A tak się składa, że już w czwartek odbędzie się w Brukseli szczyt, którego jednym z głównych tematów będzie cyfrowa niezależność Unii Europejskiej. Jeżeli destabilizacja sieci jednym incydentem nie obudzi z letargu europejskich przywódców, to czekają nas całkiem mroczne czasy.
Może zainteresować cię także:
