Projektowanie wysoko dostępnych architektur
Wyobraź sobie, że Twoja aplikacja to szpital. Czy wystarczy, że ma jedne drzwi wejściowe? A co jeśli się zablokują? W architekturze chmurowej myślenie o dostępności to absolutna podstawa. W tej lekcji nauczysz się trzech kluczowych koncepcji, które AWS uwielbia pytać na egzaminie: High Availability, Fault Tolerance i Disaster Recovery.
High Availability vs Fault Tolerance vs Disaster Recovery
Te trzy pojęcia brzmią podobnie, ale oznaczają zupełnie różne rzeczy. Zrozumienie różnic to klucz do egzaminu Cloud Practitioner.
| Cecha | High Availability | Fault Tolerance | Disaster Recovery |
|---|---|---|---|
| Cel | Minimalizacja downtime | Zero downtime nawet przy awarii | Odzyskanie po katastrofie |
| Koszt | Umiarkowany | Wysoki (pełna redundancja) | Zależy od strategii |
| Przykład | Multi-AZ RDS (failover ~60s) | Samolot z wieloma silnikami | Backup + przywracanie w innym regionie |
| Downtime | Krótki (sekundy/minuty) | Brak | Zależy od RTO |
High Availability (HA) oznacza, że system działa przez większość czasu. Krótkie przerwy są akceptowalne, ale system szybko wraca do działania. Pomyśl o tym jak o sklepie, który ma dwa wejścia. Jeśli jedno jest zablokowane, wchodzisz drugim.
Fault Tolerance (FT) idzie o krok dalej. System działa nieprzerwanie, nawet gdy jeden komponent padnie. To jak samolot z czterema silnikami: jeśli jeden zgaśnie, pozostałe trzy utrzymują maszynę w powietrzu bez żadnej przerwy w locie.
Disaster Recovery (DR) to strategia na wypadek poważnej katastrofy: pożar w data center, powódź, awaria całego regionu. Nie chodzi o to, żeby system nigdy nie padł, ale o to, żeby można go było szybko odbudować.
RTO i RPO: dwa magiczne skróty
Kiedy planujesz Disaster Recovery, musisz odpowiedzieć na dwa kluczowe pytania:
RTO (Recovery Time Objective) = ile czasu możesz sobie pozwolić na downtime? Jeśli Twoje RTO wynosi 4 godziny, to po katastrofie musisz przywrócić system w ciągu 4 godzin.
RPO (Recovery Point Objective) = ile danych możesz stracić? Jeśli Twoje RPO wynosi 1 godzina, to backup musi być robiony co najmniej co godzinę. Wszystko od ostatniego backupu do momentu awarii jest stracone.
Prowadzisz sklep e-commerce. Właśnie wyznaczyłeś cele DR:
- RTO = 1 godzina: po awarii sklep musi wrócić w ciągu godziny, bo każda minuta bez sprzedaży to straty
- RPO = 15 minut: maksymalnie możesz stracić 15 minut zamówień (te trzeba będzie odtworzyć ręcznie)
To oznacza, że potrzebujesz częstych backupów (co 15 minut) i szybkiej procedury przywracania (poniżej godziny). Na AWS możesz to osiągnąć np. z RDS automated backups + Multi-AZ + cross-region read replica.
Multi-AZ vs Multi-Region
AWS daje Ci dwa poziomy redundancji geograficznej:
Multi-AZ (Availability Zones) to rozmieszczenie zasobów w różnych Availability Zones w ramach jednego regionu. AZ to osobne data centers (lub grupy data centers) w tym samym mieście/obszarze, połączone szybkimi łączami. Odległość między nimi to kilka-kilkadziesiąt kilometrów.
Multi-Region to rozmieszczenie zasobów w różnych regionach AWS (np. eu-west-1 i us-east-1). Regiony to kompletnie niezależne lokalizacje, często na różnych kontynentach.
| Aspekt | Multi-AZ | Multi-Region |
|---|---|---|
| Ochrona przed | Awaria jednego data center | Awaria całego regionu, katastrofy naturalne |
| Latencja | Bardzo niska (ms) | Wyższa (dziesiątki ms) |
| Koszt | Umiarkowany | Wyższy (duplikacja infrastruktury) |
| Złożoność | Niska (wbudowana w wiele usług) | Wysoka (synchronizacja danych) |
| Przykład | RDS Multi-AZ, ALB + EC2 w wielu AZ | DynamoDB Global Tables, S3 Cross-Region Replication |
Active-Active vs Active-Passive
Dwa popularne wzorce architektoniczne, które zobaczysz na egzaminie:
Active-Active: oba środowiska (np. dwa regiony) obsługują ruch jednocześnie. Ruch jest rozdzielany między nie (np. przez Route 53). Jeśli jedno padnie, drugie przejmuje cały ruch. Zaleta: zero downtime, lepsze wykorzystanie zasobów. Wada: wyższy koszt, trudniejsza synchronizacja danych.
Active-Passive: jedno środowisko (active) obsługuje cały ruch. Drugie (passive/standby) czeka w gotowości. Gdy active padnie, passive się aktywuje. Zaleta: prostsze, tańsze (passive może być mniejsze). Wada: czas przełączenia (failover), passive "marnuje" zasoby w oczekiwaniu.
Bank online: wybiera active-active. Każda sekunda downtime to utrata zaufania klientów i potencjalne straty finansowe. Dwa regiony obsługują ruch równolegle przez Route 53 z latency-based routing.
Blog firmowy: wybiera active-passive. Kilka minut downtime przy failover jest akceptowalne. Primary region obsługuje cały ruch, a w secondary regionie stoi minimalna infrastruktura gotowa do aktywacji.
Strategie Disaster Recovery
AWS definiuje cztery strategie DR, od najtańszej do najdroższej:
1. Backup & Restore: najprostsza i najtańsza. Robisz regularne backupy do innego regionu (np. S3 Cross-Region Replication). Po katastrofie odtwarzasz infrastrukturę i dane z backupów. RTO: godziny. RPO: zależy od częstotliwości backupów.
2. Pilot Light: minimalna wersja środowiska działa w drugim regionie (np. baza danych z replikacją). Reszta infrastruktury jest "wyłączona" (AMI gotowe, ale EC2 nie uruchomione). Po katastrofie "zapalasz" resztę. RTO: dziesiątki minut.
3. Warm Standby: pomniejszona, ale działająca wersja systemu w drugim regionie. Np. zamiast 10 instancji EC2 masz 2, ale cała infrastruktura działa. Po katastrofie skalujesz do pełnej wielkości. RTO: minuty.
4. Multi-Site / Hot Standby: pełna kopia środowiska w drugim regionie, obsługująca ruch (active-active). Najdroższe, ale praktycznie zero downtime. RTO: sekundy.
Wybór strategii DR zależy od budżetu i wymagań biznesowych:
- Backup & Restore: RPO godziny, RTO godziny. Koszt: $. Dobre dla systemów o niskim priorytecie.
- Pilot Light: RPO minuty, RTO dziesiątki minut. Koszt: $$. Baza danych stale synchronizowana, reszta do uruchomienia.
- Warm Standby: RPO sekundy, RTO minuty. Koszt: $$$. Cały system działa w mniejszej skali.
- Multi-Site: RPO ~0, RTO sekundy. Koszt: $$$$. Pełna redundancja, ruch obsługiwany równolegle.
Na egzaminie Cloud Practitioner musisz rozpoznać, którą strategię wybrać na podstawie wymagań RTO/RPO i budżetu klienta.
Usługi AWS wspierające HA i DR
Wiele usług AWS ma wbudowane mechanizmy wysokiej dostępności:
- Elastic Load Balancing (ELB): rozkłada ruch na wiele instancji w wielu AZ
- Auto Scaling: automatycznie zastępuje uszkodzone instancje
- RDS Multi-AZ: automatyczny failover do standby w innej AZ
- S3: domyślna replikacja w wielu AZ (11 dziewiątek trwałości)
- DynamoDB Global Tables: multi-region, active-active replikacja
- Route 53: health checks i DNS failover
- CloudFormation: Infrastructure as Code do szybkiego odtwarzania infrastruktury w innym regionie
- High Availability = minimalizacja downtime (krótkie przerwy OK). Fault Tolerance = zero downtime. Disaster Recovery = plan na katastrofę
- RTO = ile czasu na przywrócenie systemu. RPO = ile danych możesz stracić
- Multi-AZ chroni przed awarią jednego data center. Multi-Region chroni przed awarią całego regionu
- Active-Active = oba środowiska obsługują ruch. Active-Passive = jedno czeka w standby
- Strategie DR od najtańszej: Backup & Restore, Pilot Light, Warm Standby, Multi-Site
- Wiele usług AWS (S3, RDS, DynamoDB) ma wbudowane mechanizmy HA
Firma potrzebuje, aby jej aplikacja działała bez żadnej przerwy, nawet gdy jeden serwer ulegnie awarii. Jakiego podejścia potrzebuje?
Firma chce chronić się przed awarią całego regionu AWS, ale ma ograniczony budżet. Która strategia DR jest najtańsza?
Czym jest RPO (Recovery Point Objective)?