Chmury też “padają”, co to oznacza dla Ciebie?
Wielkie poruszenie w Internecie, “pół Internetu nie działa”, to pogłos ostatniej awarii Amazon Web Services.
W dniu wczorajszym ok godziny 9:44 PST pojawiły się problemy z usługą S3 (Simple Storage Server) w regionie US-East-1. Pech chciał, że padło na jeden z większych regionów, w związku z czym siła rażenia była dość duża. Spora część popularnych serwisów jak np. Medium, Docker Registry Hub czy Trello informowało o problemach z ich usługami.
Pomijając falę memów i hejtu jaka od razu przewinęła się przez sieć, popatrzmy na to trzeźwym okiem i wyciągnijmy pewne wnioski.
Chmury też padają i będą padać.
To nic nadzwyczajnego, błąd ludzki, zdarzenia atmosferyczne czy po prostu sprzęt który w zawsze może zawieść. Więc jeśli planujesz zbudować system oparty o chmurę, to nadal musisz wziąć pod uwagę, że coś może się czasem popsuć. Dlatego podczas przygotowywania architektury systemu warto zastanowić jaki poziom niezawodności chce się osiągnąć i jakie narzędzia/rozwiązania które oferuje dostawca chmury można wykorzystać.
Multi-region, go multi-region.
Każdy z dostawców chmury rekomenduje budowanie systemów rozproszonych między Regionami. W szczególności gdy jednym z głównych powodów migracji jest podniesienie niezawodności. Trudno tu powiedzieć o wspólnym scenariuszu, gdyż każdy z dostawców trochę inaczej definuje pojęcie Regionu, a co za tym idzie różne usługi różnie są w nich “ulokowane”. Ale weźmy już na tapetę przykład usługi Amazon S3.
Serwis ten pozawala na przechowywanie różnego rodzaju “dowolnej” ilości danych, które umieszczane są w tzw bucket’ach. Tworząc S3 bucket wybiera się Region w którym będzie umiejscowiony i w którym bedą przetrzymywane dane. SLA na usługę S3 wynosi 99.99%, czyli jest o poziom dostępności samej usługi. Wrzucając dane do bucketu następuję automaty replikacja do trzech zupełnie niezależnych i odseparowanych od siebie ośrodków Data Center. Data Durability dla usługi S3 wynosi 99,999999999% dla Standard Storage.
I jest to na czym poprzestaje wiele firm. Powód jest dość prosty, większość usług definiowanych jest w ramach Regionu przez co dość łatwo składa się system w całość. Niestety rozpinanie aplikacji między regionami staje się trochę trudniejsze. Dodatkowa konfiguracja replikacji, większe odległości, opóźnienia, spójność danych itp. Dlatego część firm wkalkulowuje w ryzyko awarie regionu, które nie oszukujmy się nie są częste. Oczywiście jak się już coś zadzieje, Internet aż kipi.
Czego możesz być pewien.
Tego, że praktycznie nie ma możlwiości aby taka sama (technicznie, jako powód) awaria wystąpiła ponownie. Każdy dostawca powtarza, że klient i jego bezpieczeństwo (pod kątem security, biznesowym itp) jest najważniejsze. Dlatego przy każdej takiej sytuacji poświęcane są ogromne środki, na to aby problem rozwiązać, przeanalizować i sprawić aby się więcej nie powtórzył. To rzecz jasna oczywiste, mają środki finansowe, mają sztab ludzi który nad tym może pracować 24h. I przede wszystkim co też bardzo ważne, mają sprzęt który sami stworzyli, więc sami go naprawią. Nie muszą czekać na odpowiedź supportu, kontrakty serwisowe, modelowanie problemu w labie i vendora, czas reakcji itp.
Ale to jednak Ty decydujesz.
Dlatego budując system w chmurze pamiętaj ona też się psuje. Nie zwalaj całej odpowiedzialności za to co umieszczasz w chmurze na dostawcę, gdyż możesz się mocno rozczarować.
Planując aplikację dobrze zapoznaj się z usługami z jakich będziesz korzystać, jak działają, co zapewniają, za co odpowiada dostawca a za co ty. Ocen dobrze na czym Ci zależy i czego możesz użyć aby to osiągnąć. W szczególności jest jeśli celem jest osiągnięcie wysokiej dostępności systemu.
PS. Jak widać w całej sytuacji Netflix najlepiej odrobił pracę domową. W czasie gdy ja śledziłem Twittera moja żona oglądała swój serial ?.
Zbuduje swoje bezpieczne środowisko AWS.
