Awaria Amazon Web Services zepsuła inteligentne łóżka i wiele więcej: oto jak to się stało i co ujawnia o naszym kruchym ekosystemie chmurowym

Kiedy Amazon Web Services (AWS) przestał działać 20 października, nagłówki gazet skupiły się na tym, jak wpłynęło to na media społecznościowe i przerwy w transmisji strumieniowej. Efekty były jednak bardziej dalekosiężne. Zakłócenie pokazało, jak bardzo nasze życie stało się powiązane z infrastrukturą chmury. Zamieniło to nawet inteligentne łóżka niektórych użytkowników w bezużyteczne "mokre torby".

Amazon potwierdził później, skąd wziął się problem. Usterka została zlokalizowana w regionie US-East-1 w Północnej Wirginii. To właśnie tam usługa rozproszonej bazy danych DynamoDB uległa awarii i wywołała reakcję łańcuchową. Awaria uniemożliwiła nowe połączenia online. Spowodowało to zakłócenie pracy maszyn wirtualnych EC2, Network Load Balancerów i zależnych backendowych interfejsów API. Mówiąc wprost, jedna z najbardziej krytycznych arterii danych w Internecie została zatkana i świat to odczuł.

Inteligentne łóżka wyłączone przez chmurę

Wśród nieoczekiwanych ofiar znalazł się kosztujący 7000 dolarów Pod firmy Eight Sleep. Pod to inteligentny materac, który wykorzystuje cyrkulację wody i mapowanie temperatury AI w celu optymalizacji snu. Przestój serwera AWS wpłynął również na firmę zajmującą się technologią snu.

Poleganie systemu Pod na uczeniu maszynowym opartym na chmurze i synchronizacji biometrycznej w czasie rzeczywistym sprawiło, że był on podatny na ataki. Ponieważ jego algorytmy i dane użytkowników działają na serwerach AWS, awaria sprawiła, że stał się on tymczasowo bezużyteczny. W rzeczywistości jeden z użytkowników zgłosił, że jedna strona łóżka przegrzała się do 110°F.

Eight Sleep wprowadza poprawkę "trybu awaryjnego"

W odpowiedzi, CEO Eight Sleep, Matteo Franceschetti, potwierdził problem na X i obiecał naprawę. W ciągu 24 godzin firma wprowadziła rozwiązanie awaryjne Bluetooth Low Energy, które nazwała "trybem awarii". Jest to lokalna warstwa kontrolna, która omija interfejsy API w chmurze i umożliwia bezpośrednią komunikację urządzenia z aplikacją. Umożliwiło to użytkownikom dostosowanie łóżek przez Bluetooth w przypadku awarii Internetu.

W międzyczasie inżynierowie AWS godzinami pracowali nad przywróceniem usługi. Gdy to osiągnięto, zrestartowali podstawowe systemy, aż do przywrócenia łączności. Amazon opublikował oficjalne przeprosiny, nazywając awarię "znaczącym wydarzeniem". Obiecano wdrożyć zabezpieczenia architektoniczne, aby zapobiec ponownemu wystąpieniu takiej sytuacji. Nie będzie to jednak pierwszy taki przypadek.

Powtarzający się słaby punkt w chmurze Amazona

Region US-East-1 od dawna jest piętą achillesową AWS. Jak na ironię, jest to najstarsze i najbardziej uczęszczane centrum firmy chmurowej. Niemniej jednak był on epicentrum awarii w latach 2021, 2023 i 2024, zakłócając działanie głównych usług, takich jak Disney+, Slack i Zoom.

Za każdym razem kaskadowe awarie w ramach wewnętrznych zależności AWS potęgowały to, co zaczęło się jako pojedyncze problemy systemowe. Od tego czasu inżynierowie ostrzegają, że hiper-centralizacja obciążeń w określonych regionach stwarza ryzyko systemowe. Można by je złagodzić poprzez inteligentniejsze rozłożenie obciążenia i redundancję regionalną.

Uzależnienie od chmury: problem systemowy

Choć historia ta może brzmieć zabawnie, zwraca ona uwagę na rosnący problem: kruchość sprzętu zależnego od chmury. AWS, Google Cloud i Microsoft Azure wspólnie hostują systemy zaplecza, na których opiera się większość podłączonych urządzeń. Są one używane z różnymi urządzeniami, od termostatów po monitory medyczne. Kiedy przestają działać, przestają działać również urządzenia, które ludzie uważają za niezależne.

Zwolennicy konsumentów twierdzą, że należy wprowadzić standard "prawa do funkcjonalności", wymagający, aby podstawowe funkcje działały nawet w przypadku awarii usług w chmurze. Lokalne systemy awaryjne, takie jak sterowanie AI lub Bluetooth na urządzeniu, mogą zachować użyteczność i zmniejszyć zależność od odległych centrów danych.

Incydent z Eight Sleep powinien być sygnałem ostrzegawczym, że "inteligentna" rewolucja jest tylko tak niezawodna, jak stojące za nią serwery. Dopóki producenci sprzętu nie nadadzą priorytetu lokalnej kontroli, nawet coś tak prostego jak pójście spać może zależeć od tego, czy centrum danych nie śpi.