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, iż 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źć adekwatnych 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ą, ale skalą problemów.
– Ta awaria pokazuje, jak choćby 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
– komentuje Marek Szustak, IT Security Officer w eSky.plSzustak podkreśla jednocześnie, iż incydent to czytelne ostrzeżenie: inżynierowie nie powinni zakładać, iż jeden region chmury utrzyma cały biznes. Zapewnienie zapasowego środowiska i geograficzne rozproszenie zasobów powinny być normą, nie dodatkiem.
Jednocześnie AWS potwierdził, iż 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, iż jeden węzeł po przeciwnej stronie globu potrafi wyłączyć fragment świata.
A tak się składa, iż już w czwartek odbędzie się w Brukseli szczyt, którego jednym z głównych tematów będzie cyfrowa niezależność Unii Europejskiej. o ile 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:
