0Pricing
AWS Solutions Architect · Lekcja

Kontrole stanu, wyłączniki i logika ponawiania

Używać kontroli stanu ELB, kontroli punktów końcowych Route 53 oraz wyłączników na poziomie aplikacji do wykrywania awarii i automatycznego przekierowywania ruchu.

Kontrole stanu, wyłączniki i logika ponawiania to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 4 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.

Dlaczego automatyczne wykrywanie awarii ma znaczenie

W systemach rozproszonych komponenty nieustannie ulegają awariom — instancje przestają działać, występują partycje sieciowe, a usługi zależne zostają przeciążone. Bez automatycznego wykrywania awarii ruch nadal jest kierowany do uszkodzonych komponentów, co powoduje awarie kaskadowe. AWS zapewnia wiele warstw kontroli stanu: kontrole stanu ELB wykrywają niezdrowe instancje, kontrole stanu Route 53 wykrywają niezdrowe punkty końcowe, a Auto Scaling zastępuje uszkodzone instancje. Wzorce na poziomie aplikacji, takie jak circuit breakers i ponawianie prób, uzupełniają obraz odporności systemu.

Kontrole stanu ELB

Kontrole stanu Elastic Load Balancer okresowo wysyłają żądania do zarejestrowanych celów, aby określić, czy działają prawidłowo. Konfigurują Państwo ścieżkę kontroli stanu (np. /health), protokół, port, interwał (domyślnie 30 sekund) oraz próg stanu prawidłowego/nieprawidłowego (liczbę kolejnych powodzeń/niepowodzeń). Gdy cel nie przejdzie kontroli stanu, ELB przestaje kierować do niego ruch. Cel jest stale ponownie oceniany i zostaje dodany z powrotem po osiągnięciu progu stanu prawidłowego.

# Configure ALB target group health check
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
  --health-check-protocol HTTPS \
  --health-check-port 443 \
  --health-check-path /health \
  --health-check-interval-seconds 15 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200

Kontrole stanu Route 53

Kontrole stanu Route 53 monitorują punkty końcowe z wielu lokalizacji na całym świecie i współpracują z routingiem DNS typu failover. Istnieją trzy typy: Kontrole punktów końcowych bezpośrednio odpytują adres URL aplikacji. Kontrole obliczane łączą wiele podrzędnych kontroli stanu za pomocą logiki AND/OR (co jest przydatne w przypadku złożonego monitorowania). Kontrole alarmów CloudWatch przekazują określanie stanu do CloudWatch — są przydatne, gdy nie mogą Państwo udostępnić publicznego punktu końcowego stanu lub potrzebują określania stanu na podstawie metryk.

# Create endpoint health check
aws route53 create-health-check \
  --caller-reference ref-$(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 2,
    "EnableSNI": true
  }'

Kontrole stanu Auto Scaling

Grupy Auto Scaling mogą używać dwóch typów kontroli stanu: kontrole stanu EC2 wykrywają awarie instancji na poziomie hypervisora (niepowodzenie kontroli stanu instancji). Kontrole stanu ELB uwzględniają stan aplikacji — instancja może działać, ale zwracać błędy, a kontrole stanu ELB to wykryją. Mogą Państwo skonfigurować ASG tak, aby używał kontroli stanu ELB, dzięki czemu awarie na poziomie aplikacji również spowodują zastąpienie instancji, a nie tylko awarie bazowej infrastruktury EC2.

# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

# Grace period: time after launch before health checks start
# Prevents premature termination during startup

Wzorzec circuit breaker

Circuit breaker to wzorzec na poziomie aplikacji, który zapobiega kaskadowym awariom przez monitorowanie wywołań usługi podrzędnej i tymczasowe zatrzymywanie wywołań, gdy liczba awarii przekroczy próg. Obwód ma trzy stany: Closed (normalne działanie), Open (przekroczono próg awarii, wywołania są natychmiast blokowane) oraz Half-Open (po upływie limitu czasu dozwolona jest niewielka liczba wywołań testowych, aby sprawdzić, czy usługa odzyskała sprawność). AWS App Mesh i zestawy SDK aplikacji, takie jak Resilience4j, implementują ten wzorzec.

# Circuit breaker states
# CLOSED: All calls pass through
#   failureCount < threshold -> stay CLOSED
#   failureCount >= threshold -> open circuit

# OPEN: All calls fail immediately
#   After timeout -> enter HALF-OPEN

# HALF-OPEN: Allow limited test calls
#   Success -> return to CLOSED
#   Failure -> return to OPEN

# Example threshold: 5 failures in 10 seconds -> OPEN

AWS App Mesh na potrzeby circuit breaking

AWS App Mesh to service mesh, który implementuje circuit breaking, ponawianie prób i zasady limitów czasu na poziomie infrastruktury, bez zmian w kodzie. Zasady circuit breaker definiują Państwo w konfiguracji węzła wirtualnego lub routera wirtualnego. Gdy usługa nadrzędna przestaje działać prawidłowo, proxy Envoy usługi App Mesh automatycznie otwiera obwód i natychmiast zwraca błędy zamiast czekać na upływ limitów czasu. Jest to szczególnie cenne w architekturach mikrousług działających w ECS lub EKS.

# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
  'spec': {
    'listeners': [{
      'outlierDetection': {
        'consecutiveErrors': 5,
        'interval': {'unit': 'ms', 'value': 10000},
        'baseEjectionDuration': {'unit': 's', 'value': 30},
        'maxEjectionPercent': 50
      }
    }]
  }
}

Logika ponawiania prób i wykładniczy backoff

Logika ponawiania prób automatycznie ponawia nieudane operacje, jednak naiwna logika ponawiania prób (natychmiastowe ponawianie w ciasnej pętli) może pogorszyć sytuację związaną z przeciążeniem. Wykładniczy backoff wykładniczo zwiększa czas oczekiwania między próbami: 1 s, 2 s, 4 s, 8 s... Zmniejsza to obciążenie przeciążonej usługi i daje jej czas na odzyskanie sprawności. Jitter (losowe zmienianie odstępów między próbami) zapobiega problemowi szturmującego tłumu, w którym wszyscy klienci ponawiają próby jednocześnie po krótkiej awarii. AWS SDK automatycznie implementuje wykładniczy backoff z jitterem.

# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds

# Python boto3 custom retry configuration
import boto3
from botocore.config import Config

config = Config(
    retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)

Idempotencja na potrzeby bezpiecznego ponawiania prób

Ponawianie prób jest bezpieczne tylko wtedy, gdy operacje są idempotentne — wielokrotne wykonanie tej samej operacji daje ten sam wynik. Na przykład utworzenie obiektu S3 z tym samym kluczem jest idempotentne (daje ten sam wynik). Jednak dwukrotne złożenie zamówienia tworzy dwa zamówienia — nie jest więc idempotentne. Należy projektować interfejsy API jako idempotentne, używając kluczy idempotencji dostarczanych przez klienta: serwer przechowuje wynik pierwszego żądania i zwraca ten sam wynik dla kolejnych żądań z tym samym kluczem. DynamoDB, SQS i API Gateway obsługują wzorce kluczy idempotencji.

# SQS message deduplication ID for FIFO queues
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
  --message-body '{"orderId":"ord-123","items":[...]}' \
  --message-group-id 'customer-456' \
  --message-deduplication-id 'ord-123-attempt-1'

# SQS deduplicates messages with same ID for 5 minutes

Konfiguracja limitów czasu

Bez jawnie określonych limitów czasu wolna usługa podrzędna powoduje nieograniczone blokowanie wątków, wyczerpanie puli połączeń i kaskadowe awarie. Należy ustawić limity czasu na każdej warstwie: limit czasu połączenia (czas na ustanowienie połączenia TCP), limit czasu odczytu (czas na odebranie odpowiedzi) oraz łączny limit czasu żądania. W AWS należy skonfigurować limit czasu bezczynności ELB (domyślnie 60 s), limit czasu wykonania Lambda (maks. 15 min) oraz limit czasu integracji API Gateway (maks. 29 s). Limity czasu uruchamiają logikę ponawiania prób lub circuit breaker.

# Lambda: set execution timeout
aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 30

# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <ALB-ARN> \
  --attributes Key=idle_timeout.timeout_seconds,Value=60

# API Gateway: integration timeout max 29000ms

Kolejki Dead Letter dla nieudanego przetwarzania

Gdy przetwarzanie wiadomości wielokrotnie kończy się niepowodzeniem, kolejka Dead Letter (DLQ) przechwytuje wiadomości, których nie udało się przetworzyć po maksymalnej liczbie prób odebrania. Należy skonfigurować DLQ dla kolejek SQS i mapowań źródeł zdarzeń Lambda, aby zapobiec nieograniczonemu blokowaniu kolejki przez nieprawidłowe wiadomości. Wiadomości w DLQ można skontrolować, ponownie odtworzyć po naprawieniu błędu lub zarchiwizować. DLQ są kluczowym elementem odpornych architektur sterowanych zdarzeniami.

# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
  }'

# After 3 failed processing attempts, message goes to DLQ

Monitorowanie awarii za pomocą CloudWatch

Skuteczne kontrole stanu i circuit breakery wymagają monitorowania, aby można było zrozumieć wzorce awarii. CloudWatch to warstwa obserwowalności: należy utworzyć alarmy dla ELB UnHealthyHostCount (instancji, które nie przechodzą kontroli stanu), współczynnika Lambda Errors, SQS NumberOfMessagesSentToDLQ (wiadomości trafiających do DLQ) oraz Target group RequestCountPerTarget. Należy skonfigurować powiadomienia SNS, aby zespół dyżurny był natychmiast informowany, gdy automatyczne kontrole stanu wykryją pogorszenie działania.

# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
  --alarm-name 'ALB-UnhealthyHosts' \
  --alarm-description 'Alert when targets fail health checks' \
  --metric-name UnHealthyHostCount \
  --namespace AWS/ApplicationELB \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-team

Szybki test

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

Podsumowanie lekcji

W tej lekcji nauczyli się Państwo, że: kontrole stanu ELB i Route 53 automatyzują wykrywanie awarii na poziomie infrastruktury, circuit breakery zapobiegają kaskadowym awariom, zatrzymując wywołania usług, które nie działają prawidłowo, a wykładniczy backoff z jitterem zapewnia bezpieczne ponawianie prób przy dużym obciążeniu. Kolejki Dead Letter przechwytują nieudane wiadomości do późniejszej analizy. Następnie omówimy RTO, RPO i poziomy odzyskiwania po awarii.

Często zadawane pytania

Czy lekcja „Kontrole stanu, wyłączniki i logika ponawiania” jest bezpłatna?

Tak — pełny tekst „Kontrole stanu, wyłączniki i logika ponawiania” 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 „Kontrole stanu, wyłączniki i logika ponawiania”?

Używać kontroli stanu ELB, kontroli punktów końcowych Route 53 oraz wyłączników na poziomie aplikacji do wykrywania awarii i automatycznego przekierowywania ruchu. Ć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 4 z 4.

Ile czasu zajmuje lekcja „Kontrole stanu, wyłączniki i logika ponawiania”?

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. Wysoka dostępność a tolerancja błędów: definicje i kompromisy
  2. Wzorce Multi-AZ dla usług stanowych
  3. Aktywna-aktywna i aktywna-pasywna architektura wieloregionowa
  4. Kontrole stanu, wyłączniki i logika ponawiania
← Powrót do AWS Solutions Architect