Читать книгу Wzorce Cloud Native - Cornelia Davies - Страница 13

To nie wina Amazona. W niedzielę, 20 września 2015 roku Amazon Web Services (AWS) doświadczyło znaczącej awarii. Wraz z rosnącą liczbą firm utrzymujących na platformie AWS swoje krytyczne systemy, a nawet podstawowe usługi dostarczane klientom, jej awaria może doprowadzić do kolejnych, daleko idących przestojów systemów. W tym przypadku Netflix, Airbnb, Nest, IMDb i wiele innych firm doświadczyło przestoju wpływającego na ich klientów, a ostatecznie – na ich przychody. Awaria rdzennych części systemu trwała ponad pięć godzin (lub jeszcze dłużej, w zależności od tego, jak je liczyć), co u klientów korzystających z tych usług spowodowało jeszcze dłuższe awarie, zanim ich własne systemy powróciły do stabilnej pracy.

Firma Nest^* płaci AWS, ponieważ chce skupić się na dostarczaniu wartości dla swoich klientów, a nie na utrzymywaniu infrastruktury. Częścią umowy jest zapis, że AWS odpowiada za utrzymanie działania swoich systemów, co pozwala również twoim systemom domowym działać poprawnie. Jeśli AWS doświadcza przestoju, wydaje się, że łatwo go obwinić za przerwy w działaniu twojego produktu.

Ale to byłby błąd. Amazon nie ponosi winy za twoje problemy.

Zaczekaj! Nie wyrzucaj jeszcze tej książki. Wysłuchaj mnie do końca. To zdanie dotyka sedna problemu i tłumaczy cel tego przedsięwzięcia.

Po pierwsze, pozwól mi wyjaśnić jedną rzecz. Nie sugeruję, że Amazon czy inni dostawcy usług chmurowych nie ponoszą odpowiedzialności za utrzymanie działania swoich systemów – oczywiś­cie że ponoszą. A jeśli dostawca nie dopełnia pewnych umów dotyczących poziomu swoich usług (Service Level Agreements – SLA), jego klienci mogą poszukać i znajdą alternatywnych dostawców. Dostawcy usług udostępniają umowy o poziomie usług – na przykład Amazon gwarantuje dostępność większości swoich usług przez 99,95% czasu.

Ja twierdzę, że aplikacja, którą uruchamiasz na jakiejś infrastrukturze, może być bardziej stabilna niż sama infrastruktura. Jak to możliwe? Tego dokładnie, mój przyjacielu, nauczy cię ta książka.

Wróćmy na chwilę do awarii AWS z 20 września. Netflix był jedną z wielu firm, które zostały dotknięte tym przestojem, a jest to największa platforma internetowa w Stanach Zjednoczonych, biorąc pod uwagę zużycie przepustowości internetu (36%!). Jego błędy wpływają na bardzo wielu ludzi. Ale sprawdźmy, co Netflix miał do powiedzenia o awarii:

Netflix doświadczył krótkiej przerwy działania w dotkniętym awarią regionie, ale uniknęliśmy znaczącego wpływu na pracę, ponieważ ćwiczenia z wykorzystaniem narzędzia Chaos Kong przygotowały nas na takie zdarzenia. Dzięki regularnemu wykonywaniu symulacji wyłączeń całego regionu możemy wcześniej identyfikować i naprawiać wszelkie słabości naszego systemu. Kiedy US-EAST-1^** stał się niedostępny, nasz system był już wystarczająco stabilny, aby obsłużyć awaryjne przeniesienie obsługi ruchu”¹.

Netflix był w stanie szybko wstać z kolan po awarii i być w pełni funkcjonalny w kilka minut po tym, jak incydent się rozpoczął. Netflix, wciąż działający na AWS, był całkowicie sprawny mimo trwającej awarii AWS.

UWAGA Jak im się to udało? Dzięki redundancji.

Aplikacje działają wewnątrz stref dostępności i, co ważne, mogą działać w więcej niż jednej strefie dostępności (AZ) i więcej niż jednym regionie (rys. 1.1). Przypomnij sobie, jak przed chwilą stwierdziłam, że redundancja jest jednym z kluczowych elementów dostępności usługi.

Rysunek 1.1. AWS partycjonuje oferowane usługi na regiony i strefy dostępności (AZ). Regiony mapują się na obszary geograficzne, a strefy dostępności dostarczają dalszej redundancji i izolacji w obszarze jednego regionu

Na rysunku 1.2 umieśćmy kilka logotypów, aby hipotetycznie zaprezentować działające aplikacje (nie mam dokładnej wiedzy o tym, jak Netflix, IMDb czy Nest wdrożyły swoje aplikacje; to w pełni przypuszczalne, ale mimo wszystko obrazujące problem).

Rysunek 1.2. Aplikacje uruchomione na AWS mogą być umieszczone w jednej strefie dostępności (IMDb), wielu strefach, ale w jednym regionie (Nest) lub w wielu strefach i wielu regionach (Netflix). To gwarantuje różne profile odporności na awarie

Rysunek 1.3 przedstawia awarię pojedynczego regionu, taką jaka wystąpiła we wrześniu 2015 roku, kiedy tylko region us-east-1 przestał odpowiadać.

Rysunek 1.3. Jeśli aplikacje są poprawnie zaprojektowane i wdrożone, cyfrowe rozwiązania mogą przetrwać nawet szeroko zakrojone awarie, jak na przykład całego regionu

Na tej prostej grafice możemy natychmiast zauważyć, dlaczego Netflix mógł przetrwać awarię o wiele lepiej niż inne firmy; aplikacja już działała w innych regionach AWS i łatwo można było przekierować cały ruch na inne, zdrowe instancje. I mimo że, jak się wydaje, awaryjne przekierowanie nie było automatyczne, Netflix oczekiwał (a także ćwiczył obsługę!) możliwych awarii takich jak ta i zaprojektował oprogramowanie i procedury operacyjne, by je skompensować².

UWAGA Oprogramowanie cloud-native jest zaprojektowane tak, by oczekiwać awarii i pozostać stabilnym nawet wtedy, gdy infrastruktura, na której działa, doświadcza awarii lub zmienia się w inny sposób.

Twórcy aplikacji, a także zespoły wsparcia i operatorskie muszą poznać i stosować w praktyce nowe wzorce i praktyki, by tworzyć i zarządzać oprogramowaniem cloud-native, a ta książka uczy właśnie tego. Możesz myśleć, że to nie jest nic nowego, iż organizacje, szczególnie w krytycznych strefach biznesu, takich jak finanse, operowały systemami aktywny–aktywny już od dawna, i masz rację. Ale to, co jest nowe, to sposób, w jaki się to osiąga.

W przeszłości wdrożenie takich awaryjnych przełączeń było właściwie szytym na miarę rozwiązaniem, przybitym gwoździami do procedur wdrożeń systemu, który nie był początkowo zaprojektowany do dostosowywania się do awarii. Wiedza o tym, jak osiągnąć wymagane poziomy dostępności usług, była często ograniczona do kilku „gwiazd rocka” i niezwykły design, konfiguracje i mechanizmy testowania były rozmieszczone w systemie, aby spróbować zmusić systemy do odpowiedniego zachowania w przypadku awarii.

Różnica między tym a praktykami, które Netflix stosuje dzisiaj, zaczyna się od fundamentalnej różnicy w filozofii. W poprzednich podejściach zmiana lub awaria są traktowane jako wyjątek od reguły. Tu przeciwnie, Netflix i inne firmy o dużej skali istniejące w internecie, takie jak Google, Twitter, Facebook czy Uber, traktują zmianę jako regułę. Te organizacje zmieniły architektury swojego oprogramowania i swoje praktyki inżynierskie, by sprawić, że projektowanie na niepowodzenia stanie się integralną częścią tego, jak budują, dostarczają i zarządzają oprogramowaniem.

UWAGA Ponieważ niepowodzenia są regułą, a nie wyjątkiem.