Wysoka dostępność a tolerancja błędów: definicje i kompromisy

Wysoka dostępność (HA) i tolerancja awarii (FT) to dwa odrębne cele związane z niezawodnością, które architekci często mylą. Wysoka dostępność oznacza minimalny czas niedostępności systemu — system może tolerować awarie, ale podczas odzyskiwania może wystąpić krótka przerwa. Tolerancja awarii oznacza, że system działa bez żadnej przerwy nawet w przypadku awarii komponentów, ponieważ ma w pełni nadmiarowe ścieżki, które natychmiast przejmują obsługę.

Dostępność mierzy się jako procent czasu działania w ciągu roku. Dostępność 99,9% (trzy dziewiątki) oznacza około 8,7 godziny niedostępności rocznie, natomiast 99,99% (cztery dziewiątki) pozwala tylko na 52,6 minuty. 99,999% (pięć dziewiątek) pozwala zaledwie na 5,26 minuty. Każda kolejna dziewiątka zazwyczaj wymaga większej nadmiarowości, automatyzacji i nakładów. Na egzaminie SAA-C03 często trzeba wskazać architekturę spełniającą określony poziom dostępności.

Architektura o wysokiej dostępności toleruje awarię jednego komponentu, automatycznie wykrywając awarię i przełączając się na sprawny zamiennik w ciągu kilku sekund lub minut. Przykłady obejmują RDS Multi-AZ (automatyczne przełączenie awaryjne na replikę zapasową w innej strefie AZ), grupy Auto Scaling zastępujące zakończone instancje oraz moduły Elastic Load Balancing kierujące ruch z dala od niesprawnych celów. Występuje krótka przerwa w działaniu, ale system odzyskuje sprawność bez ręcznej interwencji.

Architektura odporna na awarie wykorzystuje aktywną nadmiarowość — wiele identycznych komponentów jednocześnie obsługuje żądania, dzięki czemu po awarii jednego z nich pozostałe natychmiast przejmują jego obciążenie, bez żadnej przerwy w działaniu. Przykłady obejmują aktywny-aktywny ELB z wieloma instancjami EC2, DynamoDB Global Tables obsługujące jednocześnie odczyty i zapisy w wielu regionach oraz Aurora z wieloma replikami tylko do odczytu. Tolerancja awarii wymaga stałego uruchomienia większej ilości zasobów.

Tolerancja awarii jest znacznie droższa niż wysoka dostępność, ponieważ wymaga stałego utrzymywania w pełni skonfigurowanej nadmiarowej przepustowości. Wysoce dostępna instancja RDS Multi-AZ podwaja koszt bazy danych, zapewniając replikę zapasową, która uaktywnia się tylko w razie awarii. Odporne na awarie wdrożenie Aurora active-active w wielu regionach może kosztować cztery razy więcej, ale eliminuje wszelkie przestoje podczas awarii regionu. Architekci muszą wyważyć koszt nadmiarowości względem biznesowego kosztu niedostępności.

Recovery Time Objective (RTO) to maksymalny dopuszczalny czas niedostępności systemu. Architektury o wysokiej dostępności zakładają niski RTO — zazwyczaj liczony w minutach — dzięki automatycznemu przełączaniu awaryjnemu. Architektury odporne na awarie zakładają RTO bliskie zeru. Podczas projektowania HA należy wybrać usługi i konfiguracje gwarantujące odzyskanie sprawności w ramach określonego budżetu RTO. Na przykład RDS Multi-AZ zapewnia RTO wynoszący około 60–120 sekund, co spełnia wiele wymagań dotyczących HA.

Pojedynczy punkt awarii (SPOF) to dowolny komponent, którego awaria powoduje awarię całego systemu. Typowe SPOF to pojedyncza instancja EC2 bez ASG, baza danych RDS działająca w jednej strefie AZ, pojedyncza brama NAT lub pojedyncza strefa dostępności. Eliminowanie SPOF to pierwszy krok w kierunku zarówno HA, jak i FT. Na egzaminie SAA-C03 często sprawdza się umiejętność rozpoznawania i eliminowania SPOF na przedstawionych diagramach architektury.

Osiągnięcie HA lub FT jest znacznie prostsze w przypadku usług bezstanowych (takich jak serwery internetowe lub funkcje Lambda), ponieważ dowolna instancja może obsłużyć dowolne żądanie. Usługi stanowe (bazy danych, pamięci podręczne, systemy plików) są trudniejsze — należy synchronizować stan między replikami, obsługiwać opóźnienia replikacji i zapewnić spójność podczas przełączania awaryjnego. Usługi AWS, takie jak EFS (współdzielony system plików), ElastiCache z grupami replikacji oraz Aurora (współdzielona pamięć masowa), zostały zaprojektowane, aby ułatwiać zapewnianie HA usług stanowych.

Typowe wzorce HA w AWS obejmują: 1) równoważenie obciążenia w wielu strefach AZ — rozdzielanie instancji EC2 między strefy AZ za modułem ALB. 2) repliki tylko do odczytu — odciążanie ruchu odczytu i promowanie repliki w ramach odzyskiwania po awarii. 3) S3 dla zasobów bezstanowych — S3 jest z natury wysoce dostępny i zapewnia 11 dziewiątek trwałości. 4) Global Accelerator — statyczne adresy IP Anycast kierujące ruch do sprawnych punktów końcowych w różnych regionach. Każdy wzorzec stanowi kompromis między kosztem a określonym poziomem dostępności.

Wzorce odporne na awarie wymagają aktywnej nadmiarowości wszędzie. Najważniejsze wzorce FT: DynamoDB jest z natury odporne na awarie — replikuje dane między trzema strefami AZ bez konieczności przełączania awaryjnego. S3 ma wbudowaną tolerancję awarii. Aurora Multi-Master (obecnie Aurora Serverless v2 multi-writer) umożliwia jednoczesne zapisy w wielu strefach AZ. Kinesis domyślnie przechowuje dane w wielu strefach AZ. Wybór usług zarządzanych z wbudowaną tolerancją awarii to najbardziej opłacalna droga do architektur bez przestojów.

Projektowanie z myślą o HA lub FT jest tak dobre, jak przeprowadzane testy. AWS zaleca korzystanie z AWS Fault Injection Simulator (FIS) do przeprowadzania kontrolowanych eksperymentów, które kończą działanie instancji, ograniczają przepustowość interfejsów API lub wprowadzają awarie sieci. Należy sprawdzić, czy przełączenie awaryjne faktycznie kończy się w ramach RTO, czy utrata danych nie przekracza RPO oraz czy alarmy są prawidłowo uruchamiane. Regularne dni testowe i ćwiczenia chaos engineering ujawniają luki w założeniach dotyczących odporności, zanim zrobią to incydenty produkcyjne.

Sprawdź swoją znajomość zagadnień z egzaminu AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: wysoka dostępność minimalizuje przestoje dzięki automatycznemu odzyskiwaniu sprawności (RTO liczony w minutach), tolerancja awarii eliminuje przestoje dzięki aktywnej nadmiarowości (RTO równe zero), a koszt znacząco rośnie wraz z każdym poziomem odporności. Eliminowanie pojedynczych punktów awarii stanowi podstawę obu podejść. Następnie omówimy wzorce obejmujące wiele stref AZ dla usług stanowych.