Rozumienie wzorców wytrzymałości i kompromisów w celu działań wydajnej architektury w chmurze

Projektowanie obciążeń w celu osiągnięcia celów w zakresie wytrzymałości może być działaniem równoważącym. Firmy projektujące wytrzymałość w chmurze często muszą ocenić wiele czynników, zanim będą mogły wybrać najbardziej optymalną architekturę dla swoich obciążeń.

Example Corp posiada wiele aplikacji o różnej krytyczności, a każda z tych aplikacji ma inne potrzeby pod względem odporności, złożoności i kosztów. Mają wiele możliwości zaprojektowania swoich obciążeń pod kątem wytrzymałości i kosztów, ale która opcja najlepiej odpowiada ich potrzebom? Czy będą musieli dokonać poświęcenia, aby wprowadzić jeden nad drugim? Jak i dlaczego powinni wybierać jeden wzór, a nie inny?

Aby pomóc odpowiedzieć na te pytania, twórcy omówią pięć wzorców odporności przedstawionych na rysunku 1 oraz kompromisy do rozważenia podczas ich wdrażania: 1) złożoność projektu, 2) koszt wdrożenia, 3) wysiłek operacyjny, 4) wysiłek w celu zabezpieczenia, oraz 5) wpływ na środowisko. Pomoże Ci to osiągnąć różne poziomy odporności i podjąć decyzje dotyczące architektury najbardziej odpowiedniej dla Twoich potrzeb.

Rysune 1: Wzorce odporności i kompromisy

Czym jest wytrzymałość? Dlaczego ma znaczenie?

AWS Well-Architected Framework definiuje wytrzymałość jako „zdolność do odzyskania sprawności w przypadku obciążenia (więcej żądań usług), ataków (przypadkowych z powodu błędu lub celowych) oraz awarii dowolnego składnika w komponentach obciążenia.”

Aby spełnić wymagania dotyczące wytrzymałości firmy, podczas projektowania obciążeń należy wziąć pod uwagę następujące kluczowe czynniki:

• Złożoność projektu – zazwyczaj im bardziej złożone staje się obciążenie pracą, tym bardziej skomplikowane będą wymagania dotyczące wytrzymałości. Każdy pojedynczy składnik obciążenia musi być odporny i musisz wyeliminować pojedyncze punkty awarii w ludziach, procesach i elementach technologicznych.
• Koszt wdrożenia – koszty często znacznie wzrastają po wdrożeniu większej wytrzymałości, ponieważ potrzebne jest nowe oprogramowanie i elementy infrastruktury.
• Wysiłek operacyjny – Wdrażanie i wspieranie wysoce odpornych systemów wymaga bardziej złożonych procesów operacyjnych i zaawansowanych umiejętności technicznych. Zanim zdecydujesz się na wdrożenie większej wytrzymałości, oceń swoje kompetencje operacyjne, aby potwierdzić, że masz wymagany poziom dojrzałości procesu i umiejętności.
• Wysiłek w celu zabezpieczenia – złożoność zabezpieczeń jest mniej bezpośrednio skorelowana z wytrzymałością. Jednak w przypadku wysoce odpornych systemów na ogół jest więcej elementów do zabezpieczenia. Najlepsze praktyki AWS Security mogą pomóc klientom osiągnąć cele bezpieczeństwa w przypadku tak złożonych wdrożeń.
• Wpływ na środowisko – większy ślad po wdrożeniu wytrzymałych systemów może zwiększyć zużycie zasobów w chmurze. Możesz jednak skorzystać z kompromisów, takich jak przybliżone obliczenia i wolniejsze czasy odpowiedzi, aby zmniejszyć zużycie zasobów.

P1 – Multi-AZ

P1 to wzorzec architektury oparty na chmurze (rysunek nr 2), który wprowadza do architektury strefy dostępności (AZ) w celu zwiększenia odporności systemu. Wzorzec P1 wykorzystuje architekturę Multi-AZ, w której aplikacje działają w wielu obszarach AZ w ramach jednego regionu AWS. Dzięki temu Twoja aplikacja jest odporna na uderzenia na poziomie AZ.

Jak przedstawiono na rysunku nr 2, Example Corp wdraża swoje wewnętrzne aplikacje pracownicze przy użyciu wzorca P1. Te aplikacje mają niewielki wpływ na biznes i dlatego mają mniejsze wymagania dotyczące wytrzymałości.

Firma Example Corp wdraża te aplikacje w chmurze Amazon Elastic Compute Cloud (Amazon EC2), która wykorzystuje kontrole kondycji do automatycznego wykrywania błędów. Jeśli AZ zawiedzie, Amazon EC2 prosi grupę Amazon EC2 Auto Scaling o odtworzenie aplikacji w innym niezmienionym AZ.

Rysunek 2: Wzorzec wdrażania Multi-AZ (P1)

Kompromisy

P1 to niewielki wysiłek w kilku kategoriach, ale odbywa się to kosztem odzyskiwania aplikacji. Jeśli AZ nie działa, zakłóci to dostęp użytkowników końcowych do aplikacji, podczas gdy nowe zasoby są ponownie udostępniane w nowym AZ. Jest to znane jako zachowanie bimodalne.

P2 – Multi-AZ ze stabilnością statyczną

P2 wykorzystuje wiele AZ w regionie, aby zwiększyć wytrzymałość, ale wykorzystuje stabilność statyczną, aby zapobiec bimodalnemu zachowaniu. P2 wykorzystuje systemy stabilności statycznej, które pozostają stabilne i działają w jednym trybie niezależnie od zmian w środowisku operacyjnym.

Jak przedstawiono na rysunku nr 3, firma Example Corp posiada witrynę internetową skierowaną do klientów, która wykazuje mniejszą tolerancję na przestoje. Za każdym razem, gdy witryna nie działa, może to spowodować utratę przychodów. Z tego powodu witryna wymaga dwóch wystąpień EC2, które są udostępniane w ramach dwóch odniesień AZ. W ten sposób, jeśli AZ ulegnie uszkodzeniu, strona internetowa może nadal działać i nie wymaga od firmy Example Corp wykrycia usterki lub uruchomienia nowej infrastruktury.

Rysunek 3: Multi-AZ ze stabilnością statyczną P2

Kompromisy

P2 należy porównać z kwestiami kosztów. P1 jest tańszy, ponieważ zapewnia mniejszą moc obliczeniową i polega na uruchamianiu nowych instancji w przypadku awarii. Jednak bimodalne zachowanie P1 może wpływać na Twoich klientów podczas wydarzeń na dużą skalę.

Możesz pójść dalej i wdrożyć swoje obciążenie pracą w trzech AZ w całym regionie. Zmniejszy to koszty związane z nadmiarową alokacją, ponieważ wystarczy udostępnić tylko trzy wystąpienia w porównaniu z czterema wymienionymi w naszym poprzednim przykładzie.

Dystrybucja portfolio aplikacji

Wzorzec P3 wykorzystuje wzorzec wielu regionów w celu zwiększenia wytrzymałości funkcjonalnej. Dystrybuuje różne krytyczne aplikacje w wielu Regionach.

Example Corp świadczy usługi bankowe, takie jak sprawdzanie salda kredytowego konsumentom w wielu kanałach cyfrowych. Usługi te są dostępne dla konsumentów za pośrednictwem aplikacji mobilnej, contact center oraz aplikacji internetowych. Jeśli Region ulegnie awarii w miejscu wdrożenia aplikacji mobilnej, klienci nadal będą mogli uzyskać dostęp do usług za pośrednictwem innych kanałów wdrożonych w innych Regionach. Przerwy regionalne zdarzają się rzadko, ale wdrożenie tego wzorca gwarantuje, że użytkownicy zachowają dostęp do usług o znaczeniu krytycznym dla firmy podczas przerw.

Rysunek 4: Dystrybucja portfolio aplikacji - Wzorzec P3 

Kompromisy

Obsługa portfela aplikacji, który obejmuje wiele Regionów, wymaga znaczącego planowania operacyjnego i zarządzania. Izolowane elementy funkcjonalne mogą zależeć od wspólnych systemów niższego szczebla i źródeł danych, które są wdrożone w jednym Regionie. Dlatego wydarzenia obejmujące cały region mogą nadal powodować zakłócenia; jednak powierzchnia uderzenia jest znacznie zmniejszona.

P4 – Wdrożenie Multi-AZ (wieloregionalne odzyskiwanie po awarii)

Example Corp obsługuje kilka usług o znaczeniu krytycznym dla działalności, takich jak możliwość dokonywania przez konsumentów płatności bankowych, które charakteryzują się bardzo niską tolerancją na zakłócenia. Example Corp używa następujących wzorców podrzędnych dla tych aplikacji:

• Pilot Light – ten wzorzec działa dla aplikacji, które wymagają czasu RTO/RPO wynoszącego 10 sekund. Dane są aktywnie replikowane, a infrastruktura aplikacji jest wstępnie udostępniana w regionie odzyskiwania po awarii (DR). Optymalizacja kosztów jest tutaj kluczowym czynnikiem, ponieważ infrastruktura aplikacji jest wyłączona i włączana tylko podczas zdarzenia przywracania.
• Warm Standby – ten wzorzec znacznie skraca czas przywracania w porównaniu z lampką kontrolną, utrzymując działanie aplikacji w regionie DR, ale ze zmniejszoną pojemnością. Infrastruktura aplikacji będzie skalowana podczas zdarzenia DR, ale zazwyczaj można to zautomatyzować przy minimalnym nakładzie pracy ręcznej. Ten wzorzec może osiągnąć RTO/RPO minut, jeśli zostanie poprawnie zaimplementowany.

Raport Disaster Recovery of Workloads on AWS: Recovery in the Cloud szczegółowo opisuje te wzorce.

Kompromisy

Regionalne wzorce DR zwiększają złożoność wdrażania, ponieważ zmiany w infrastrukturze muszą być synchronizowane między regionami. Testowanie jest również znacznie bardziej złożone i powinno obejmować scenariusze, takie jak utrata regionu oraz kierowanie i zarządzanie ruchem. Używanie infrastruktury jako kodu do automatyzacji wdrożeń może pomóc w złagodzeniu tych problemów.

P5 – Multi-Region active-active

Podstawowe aplikacje bankowe i aplikacje do zarządzania relacjami z klientami firmy Example Corp nie tolerują zakłóceń regionalnych. Używają wzorca P5 do wdrażania tych aplikacji, ponieważ ma on RTO czasu rzeczywistego i RPO prawie zerową utratę danych. W ten sposób uruchamiają swoje obciążenie jednocześnie w wielu Regionach, co pozwala im obsługiwać ruch ze wszystkich Regionów.

Rysunek 5: P5 – Multi-Region active-active

Kompromisy

Ekosystemy multifunkcyjne są zazwyczaj złożone, ponieważ zawierają wiele aplikacji, które współpracują ze sobą, aby dostarczać wymagane usługi biznesowe. Jeśli zaimplementujesz ten wzorzec, musisz wziąć pod uwagę fakt, że wprowadzasz asynchroniczną replikację danych w różnych regionach oraz wpływ, jaki ma to na spójność danych.

Obsługa tego wzorca wymaga bardzo wysokiego poziomu dojrzałości procesu, dlatego autorzy zalecają klientom stopniowe budowanie w kierunku tego wzorca, zaczynając początkowo od wzorców wdrażania opisanych wcześniej.

Wnioski

W powyższym artykule blogowym autorzy przedstawili pięć wzorców odporności oraz kompromisy, które należy rozważyć podczas ich wdrażania. Pokazali, jak firma Example Corp oceniła te opcje i jak zastosowała je do potrzeb biznesowych, aby pomóc Ci wybrać najbardziej wydajną architekturę do wdrożenia.

Dodatkowa lektura

• AWS Well Architected Framework – Resilience Pillar
• Building Resilient Well-Architected Workloads Using AWS Resilience Hub
• Disaster Recovery of Workloads on AWS: Recovery in the Cloud
• Disaster Recovery (DR) Architecture on AWS, Architecture Blog series

Szukasz więcej treści związanych z architekturą?

AWS Architecture Center zapewnia diagramy architektury referencyjnej, sprawdzone rozwiązania architektoniczne, dobrze zaprojektowane najlepsze praktyki, wzorce, ikony i wiele więcej!

źródło: AWS