11

Na szali jest życie pacjentów, ale ich fotki są bezpieczne. Awaria chmury Amazonu inaczej

Wstrzymanie się przed krytycznym komentarzem na temat Chmury Amazonu oszczędziło mi dzisiaj wycofywania się z niego rakiem. Łatwo zwalić całą winę za ponad setkę wyłączonych serwisów na Amazon i uderzyć na trwogę, że przez awarię chmury zagrożone było ludzkie życie, jak sugerował serwis wykorzystujący Amazon Web Services do monitorowania elektrokardiogramów swoich pacjentów. Jednak okazuje się, że problemem nie jest sama awaria, a raczej błędy projektujących i budujących […]

Wstrzymanie się przed krytycznym komentarzem na temat Chmury Amazonu oszczędziło mi dzisiaj wycofywania się z niego rakiem. Łatwo zwalić całą winę za ponad setkę wyłączonych serwisów na Amazon i uderzyć na trwogę, że przez awarię chmury zagrożone było ludzkie życie, jak sugerował serwis wykorzystujący Amazon Web Services do monitorowania elektrokardiogramów swoich pacjentów. Jednak okazuje się, że problemem nie jest sama awaria, a raczej błędy projektujących i budujących serwisy korzystające z tej usługi. Jak w każdym kompleksowym systemie wpadki są one nieuniknione, ale Amazon oferuje wystarczający poziom redundancji, aby nawet w wypadku poważnej awarii utrzymać na chodzie serwisy zaprojektowane z myślą o potencjalnych problemach. Dlatego, gdy nie można było monitorować EKG pacjentów, wciąż można było oglądać sobie ich fotki na SmugMug.

Trafiłem dziś na interesujący artykuł prezesa serwisu SmugMug – jednego z najbardziej zaawansowanych narzędzi w sieci, służących do składowania, edycji i prezentacji zdjęć w sieci. Wyjaśnia w nim, dlaczego awaria chmury Amazon nie spowodowała większych zakłóceń w jego działaniu, choć setka innych witryn była niedostępna – w tym wspomniana infrastruktura usługi monitorującej EKG pacjentów mających problemy z sercem.

Design for failure

Tak Don MacAskill z SmugMug, jak i spec od rozwiązań w chmurze George Reese podkreślają, że awaria Amazon Web Services to dowód, że wadliwa jest implementacja w wykonaniu korzystających z chmury serwisów, a nie koncepcja Cloud Computing. MacAskill wyjaśnia, że kluczowe dla działania SmugMug usługi są rozłożone po kilku „strefach dostępności” (Availability Zones), które w Amazon są od siebie dokładnie odseparowane, aby awaria jednej nie wpływała na pozostałe. W wypadku krytycznych systemów, istnieje też (kosztowna) możliwość umieszczenia go w innym regionie, co gwarantuje lepsza separację i jeszcze wyższy poziom bezpieczeństwa.

Cała infrastruktura SmugMug została od początku „zaprojektowana z myślą o awarii” (design for failure). Oznacza to, że awaria jednego z komponentów serwisu nie oznacza konieczności zdjęcia całości z sieci, a tylko tymczasowy brak jednej z funkcji.  Każdy z elementów infrastruktury może zostać „zabity”, a system automatycznie zareaguje na awarię przerzucając obciążenie na działający komponent znajdujący się w innej „strefie dostępności”.  Dlatego, efekty awarii chmury Amazonu były nieporównywalne z ponad 8 godzinną awarią, z jaką SmugMug musiał się zmierzyć, gdy korzystał jeszcze z własnej infrastruktury.

Koncepcja nie jest, ani nowa, ani rewolucyjna, ani pozbawiona wad. Jednak połączenie niższych kosztów Amazon Web Services, większa swoboda w budowaniu redundantnych serwisów „projektowanych z myślą o awarii” oraz przykład SmugMug, to z mojego punktu widzenia dowód, że pomijając oczywistą odpowiedzialność Amazon za działanie swoich usług, większość pokrzywdzonych przez awarię jest sama sobie winna. Jak widać da się to zrobić inaczej. Dlatego, to właściciele serwisów w których dostępność usługi jest absolutnie krytyczna (np. wspomniane EKG, usługi w modelu SAAS dla firm) ponoszą większa odpowiedzialność za wywołany awarią downtime niż Amazon.

  1. Adam Czajczyk napisał(a):

    no i wyszło szydło z worka – jak pokazuje ta sytuacja „chmura chmurze nie równa”, a dokładniej: to, że serwis/aplikacja „stoi w chmurze” nie znaczy nic, dopóki nawyki developerów infrastruktury pozostają takie same jak przy korzystaniu ze… zwykłych „dedyków” (gdzie nota bene przy odpowiednim „pomyślunku” można osiągnąć również całkiem niezłą redundancję, tyle, że wychodzi drogo jak diabli)

    no ale teraz wszystko trzeba „w chmurze”, jak przystało na XXI wiek :P

    1. matipl napisał(a):

      bo „chmura” to taki sam bullshit jak „web 2.0” – marketingowa gadka i nic więcej.
      Pod hasełkiem chmura kryje się masa narzędzi, która od dawna była dostępna. Jak ktoś nie potrafi korzystać będzie miał „zwykły hosting”…

  2. bachus napisał(a):

    Trzeba mieć tupet żeby sugerować (jak firma od EKG), że winą Amazonu było, że ich system przestał działać. Szkoda tylko, że w chmurze szpitale nie mają urządzeń do podtrzymywania życia… Chmura – srura.

    1. Paweł Nowak napisał(a):

      wydaje mi się, że nie doczytałeś artykułu do końca.

  3. Tomasz Gregorczyk napisał(a):

    ja to lubie czasem ściągnąć „chmure” z lufy :)
    i iech tak zostanie ;)

    1. Sova napisał(a):

      a chmurka do piwka też nie jest zła :0

  4. Artur napisał(a):

    we don’t use Elastic Block Storage (EBS)

    No i to jest clue w wypadku SmugMug (EBS to dyski używane w EC2 niezależne od instancji serwerów). Tyle, że przy normalnym korzystaniu z EC2 są potrzebne i większość serwisów z nich korzystała. Awaria dotyczyła głównie właśnie EBS i to we wszystkich datacenter! Więc dla nich nawet rozproszenie na kilka zonów nie pomogło. A że same EBS jest słabe tutaj pisze pracownik reddit: http://i.imgur.com/vK7de.jpg

    niższych kosztów Amazon Web Services

    To zależy… Serwery EC2 są ok. 2x droższe a transfer 5x droższy niż na OVH, przy wykorzystniu 24h/30d. Oczywiście przewaga EC2 jest taka, że możemy uruchamiać i zatrzymywać dodatkowe serwery w ramach potrzeby za pomocą zwykłego api.

    Cloud computing is just a tool

    I to jest myślę najtrafniejszy cytat. Tylko narzędzie a nie kraina szczęśliwości, gdzie nic się nie psuje i samo replikuje. Innymi słowy, „chmura” nic nie znaczy i i tak trzeba wiedzieć jak to pod spodem działa aby się zabezpieczyć.

  5. Tomasz Gregorczyk napisał(a):

    Sova: a chmurka do piwka też nie jest zła :0

    jak najbardziej ;)

  6. Jacek Lampart napisał(a):

    Jeszcze jedno ciekawe spojrzenie na ten temat opisał dzisiaj Jeff Atwood, na przykładzie Netfliksa: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

  7. Matt napisał(a):

    Na razie cały „Cloud computing” to buzz word. Minie jeszcze wiele lat zanim te usługi przejdą chrzest bojowy. Amazon ma jeszcze wiele zalet w przeciwieństwie do App Engine który ma np. limit projektu do 150MB, 3000 plików w projekcie…

  8. sieciobywatel napisał(a):

    Jak napisał Artur, SmugMug nie korzystał z EBS, które uległo awarii. Co gorsza, pod naporem zapytań praktycznie padł panel do zarządzania, przez co nie odpalały się automatycznie nowe instancje (i oczywiście nie można było ręcznie dodać nowych). A to już jest ewidentna wina Amazon:

    The important thing here is that there actually was, unbeknownst to AWS customers, a single point of failure across zones: the control plane. This made AWS unable to fulfill its own failover promises. In fact, RDS customers ended up in worse shape than many others – it took over 14 hours to get many of their databases moved over, longer than those that were able to failover manually.

    (źródło)
    Warto też przeczytać wątek na HN, gdzie dyskutowane jest oświadczenie SmugMug (z udziałem inżynierów z tej firmy).
    Dobry przegląd komentarzy na ten temat można znaleźć na Highscalability.