0Pricing
AWS Solutions Architect · Lekcja

Scenariusze odpornych i wysoce dostępnych architektur

Rozwiązywać scenariusze przełączania baz danych Multi-AZ, automatycznego skalowania przy skokowym ruchu oraz przełączania awaryjnego Route 53 z kontrolą stanu, aby utrwalić zagadnienia niezawodności.

Scenariusze odpornych i wysoce dostępnych architektur to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AWS Solutions Architect, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Scenariusz 1: Aplikacja webowa w wielu strefach AZ

Scenariusz: Firma korzysta z dwuwarstwowej aplikacji webowej (ALB → EC2 → RDS) i chce wyeliminować pojedyncze punkty awarii w obrębie regionu AWS. Rozwiązanie: Należy wdrożyć instancje EC2 w grupie Auto Scaling obejmującej co najmniej 2 strefy dostępności za modułem ALB (który z natury działa w wielu strefach AZ). Należy włączyć RDS Multi-AZ w celu synchronicznej replikacji do instancji zapasowej. Należy skonfigurować kontrole kondycji na ALB, aby automatycznie kierować ruch z dala od niesprawnych instancji. Dzięki tej architekturze utrata dowolnej pojedynczej strefy AZ powoduje automatyczne przełączenie awaryjne na każdej warstwie.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

Scenariusz 2: Skalowanie odczytu RDS pod obciążeniem

Scenariusz: Instancja RDS aplikacji e-commerce osiąga limity procesora w godzinach szczytu z powodu intensywnych zapytań analitycznych odczytujących dane, generowanych przez zespół analityki biznesowej. Rozwiązanie: Należy utworzyć repliki odczytu RDS i kierować zapytania BI do punktu końcowego repliki. Repliki odczytu korzystają z replikacji asynchronicznej — niewielkie opóźnienie jest akceptowalne w przypadku analiz. Odciąża to podstawową instancję RDS z ruchu odczytu, dzięki czemu może ona obsługiwać operacje zapisu i odczyty aplikacji. W przypadku wyjątkowo intensywnych obciążeń odczytem należy dodać warstwę ElastiCache przed RDS, aby przechowywać często używane dane w pamięci podręcznej.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

Scenariusz 3: Auto Scaling podczas skoku użycia procesora

Scenariusz: Bezstanowe API działa na EC2 za modułem ALB. W godzinach pracy użycie procesora wzrasta do 90%, a w nocy spada niemal do zera. Firma chce, aby flota skalowała się automatycznie. Rozwiązanie: Należy skonfigurować grupę Auto Scaling z zasadą skalowania Target Tracking, której celem jest średnie użycie procesora na poziomie 60%. ASG będzie automatycznie dodawać instancje, gdy użycie procesora przekroczy 60%, oraz usuwać je, gdy spadnie poniżej wartości docelowej. Należy dodać zaplanowaną akcję skalowania, aby wstępnie zwiększyć minimalną pojemność przed rozpoczęciem godzin pracy i zapobiec opóźnieniom podczas porannego wzrostu ruchu.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

Scenariusz 4: Przełączenie Route 53 na stronę DR

Scenariusz: Firma uruchamia podstawową aplikację webową w us-east-1 i chce przełączać ruch na statyczną stronę konserwacyjną hostowaną w S3 w us-west-2, jeśli podstawowa aplikacja przestanie działać poprawnie. Rozwiązanie: Należy utworzyć kontrolę kondycji Route 53 monitorującą punkt końcowy podstawowego ALB. Należy utworzyć dwa rekordy Route 53 z zasadą routingu przełączania awaryjnego: rekord podstawowy wskazujący ALB (powiązany z kontrolą kondycji) oraz rekord zapasowy wskazujący statyczną witrynę S3. Jeśli kontrola kondycji zakończy się niepowodzeniem, Route 53 automatycznie zwróci odpowiedź DNS dla rekordu zapasowego.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

Scenariusz 5: Rozdzielenie komponentów za pomocą SQS w celu zwiększenia odporności

Scenariusz: Backend przetwarzania zamówień zapisuje dane w bazie danych, ale baza czasami staje się niedostępna podczas okien konserwacyjnych, co powoduje utratę zamówień. Rozwiązanie: Należy umieścić kolejkę SQS między frontendem (który przyjmuje zamówienia) a backendem (który je przetwarza). Zamówienia są natychmiast umieszczane w kolejce, dzięki czemu klient od razu otrzymuje potwierdzenie. Procesy robocze w tle pobierają zamówienia z kolejki i przetwarzają je, gdy baza danych jest dostępna. Podczas konserwacji zamówienia gromadzą się w kolejce zamiast być odrzucane — zapewnia to odporność dzięki asynchronicznemu rozdzieleniu komponentów.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

Scenariusz 6: Pilot Light dla DR

Scenariusz: Firma potrzebuje rozwiązania odzyskiwania po awarii z RPO wynoszącym 1 godzinę i RTO wynoszącym 4 godziny, przy umiarkowanym budżecie. Rozwiązanie: Należy wdrożyć strategię DR typu Pilot Light. Główną bazę danych należy replikować do regionu DR za pomocą repliki odczytu RDS w innym regionie. Serwery aplikacji nie działają w regionie DR podczas normalnej pracy — utrzymywany jest tylko minimalny „rdzeń” (baza danych). W przypadku awarii należy promować replikę odczytu do samodzielnej bazy i uruchomić serwery aplikacji na podstawie wcześniej utworzonych obrazów AMI za pomocą CloudFormation. RTO wynosi godziny, a nie minuty, ponieważ serwery muszą zostać uruchomione.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

Scenariusz 7: Kolejka SQS typu Dead-Letter dla nieudanych komunikatów

Scenariusz: Przetwarzanie komunikatów w kolejce SQS wielokrotnie kończy się niepowodzeniem z powodu błędu w funkcji Lambda będącej konsumentem. Komunikaty ciągle pojawiają się ponownie i blokują kolejkę. Rozwiązanie: Należy skonfigurować kolejkę Dead-Letter (DLQ) dla głównej kolejki. Gdy przetwarzanie komunikatu zakończy się niepowodzeniem określoną liczbę razy (maxReceiveCount), SQS automatycznie przeniesie go do DLQ zamiast dostarczać go ponownie w nieskończoność. Odblokuje to główną kolejkę dla prawidłowych komunikatów. Należy ustawić alarm CloudWatch dla metryki DLQ ApproximateNumberOfMessagesVisible, aby powiadamiać zespół inżynieryjny o gromadzeniu się komunikatów w DLQ.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

Scenariusz 8: Globalna baza danych Aurora

Scenariusz: Firma działa w Stanach Zjednoczonych i Europie. Użytkownicy w Europie doświadczają dużych opóźnień odczytu z bazy danych, ponieważ RDS znajduje się w us-east-1. Rozwiązanie: Należy użyć Amazon Aurora Global Database. Klaster podstawowy znajduje się w us-east-1, a pomocniczy klaster tylko do odczytu jest dodawany w eu-west-1. Aurora replikuje dane do pomocniczego regionu z typowym opóźnieniem poniżej 1 sekundy, korzystając z replikacji na poziomie pamięci masowej. Użytkownicy w Europie odczytują dane z pomocniczego klastra w eu-west-1. W przypadku awarii regionu klaster pomocniczy można promować do roli podstawowego w czasie poniżej 1 minuty (to najlepsze RTO spośród wszystkich wieloregionowych opcji baz danych AWS).

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

Scenariusz 9: Usługa ECS z ALB i Auto Scaling

Scenariusz: Konteneryzowana usługa API działająca w ECS Fargate musi skalować się na podstawie użycia procesora i przetrwać awarie stref AZ. Rozwiązanie: Należy zarejestrować usługę ECS w grupie docelowej Application Load Balancer, aby ruch był rozdzielany między uruchomione zadania. Zadania należy umieścić w wielu strefach AZ, określając wiele podsieci w konfiguracji usługi. Należy skonfigurować ECS Service Auto Scaling z zasadą Target Tracking opartą na użyciu procesora przez usługę ECS, aby automatycznie zwiększać i zmniejszać liczbę zadań. Jeśli strefa AZ ulegnie awarii, ECS uruchomi ponownie niesprawne zadania w zdrowych strefach AZ.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

Scenariusz 10: Przełączenie awaryjne na podstawie kontroli kondycji w Route 53

Scenariusz: Firma uruchamia dwie instancje EC2 w różnych strefach AZ, obsługujące tę samą domenę. Chce, aby Route 53 automatycznie przestał kierować ruch do niesprawnej instancji. Rozwiązanie: Należy użyć routingu ważonego Route 53 z jednakowymi wagami (50/50) i powiązać kontrolę kondycji punktu końcowego z każdym rekordem. Gdy Route 53 wykryje niesprawny punkt końcowy, usunie ten rekord z odpowiedzi DNS i skieruje 100% ruchu do sprawnego punktu końcowego. Po przywróceniu działania instancji i ponownym pomyślnym przejściu kontroli kondycji Route 53 automatycznie ponownie rozdzieli ruch — bez konieczności ręcznych zmian w DNS.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

Scenariusz 11: DynamoDB Global Tables dla wysokiej dostępności w wielu regionach

Scenariusz: Aplikacja do gier mobilnych potrzebuje danych graczy dostępnych do odczytu i zapisu z małymi opóźnieniami zarówno w us-east-1, jak i ap-southeast-1. Tabela DynamoDB działająca w jednym regionie powoduje duże opóźnienia u użytkowników z Azji. Rozwiązanie: Należy włączyć DynamoDB Global Tables. Global Tables automatycznie replikuje dane między określonymi regionami za pomocą replikacji multi-master — każdy region może przyjmować operacje zapisu. Użytkownicy z Azji zapisują dane do repliki w ap-southeast-1 i odczytują je z niej przy lokalnym opóźnieniu (~5 ms). Global Tables rozwiązuje konflikty za pomocą strategii „wygrywa ostatni zapis”, opartej na znacznikach czasu. RTO w przypadku całkowitej awarii regionu jest niemal zerowe — ruch jest po prostu kierowany do działającego regionu.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

Szybki test

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji przeanalizowano scenariusze obejmujące: ASG Multi-AZ i RDS zapewniające wysoką dostępność w obrębie regionu, routing przełączania awaryjnego Route 53 na potrzeby DR w innym regionie, SQS DLQ do odizolowania nieudanych komunikatów bez blokowania kolejek oraz Aurora Global Database do skalowania odczytu między regionami i przełączania awaryjnego z RTO poniżej minuty. W następnej części omówimy scenariusze dotyczące wysokowydajnej i zoptymalizowanej kosztowo architektury.

Często zadawane pytania

Czy lekcja „Scenariusze odpornych i wysoce dostępnych architektur” jest bezpłatna?

Tak — pełny tekst „Scenariusze odpornych i wysoce dostępnych architektur” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AWS Solutions Architect, przejdź na CoddyKit PRO. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Co nauczysz się w „Scenariusze odpornych i wysoce dostępnych architektur”?

Rozwiązywać scenariusze przełączania baz danych Multi-AZ, automatycznego skalowania przy skokowym ruchu oraz przełączania awaryjnego Route 53 z kontrolą stanu, aby utrwalić zagadnienia niezawodności. Ćwiczysz AWS Solutions Architect z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AWS Solutions Architect?

Nie wymagamy żadnego doświadczenia. AWS Solutions Architect w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Scenariusze odpornych i wysoce dostępnych architektur”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AWS Solutions Architect?

Tak. Każda lekcja AWS Solutions Architect zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Scenariusze bezpiecznych architektur
  2. Scenariusze odpornych i wysoce dostępnych architektur
  3. Scenariusze wysokiej wydajności i optymalizacji kosztów
  4. Pełny mini-egzamin z mieszanych domen
← Powrót do AWS Solutions Architect