AWS Solutions Architect · Lektion

Tilstandstjek, circuit breakers og retry-logik

Brug ELB-tilstandstjek, Route 53-endpointtjek og circuit breakers på applikationsniveau til automatisk at registrere fejl og omdirigere trafik

Lektion 4 af 413 trin

Tilstandstjek, circuit breakers og retry-logik er en gratis AWS Solutions Architect-lektion på CoddyKit. Dette er lektion 4 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i AWS Solutions Architect, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Hvorfor automatiseret fejldetektering er vigtigt

I distribuerede systemer svigter komponenter hele tiden — instanser går ned, netværkspartitioner opstår, og downstream-tjenester bliver overbelastede. Uden automatiseret fejldetektering fortsætter trafikken med at flyde til defekte komponenter, hvilket forårsager kaskadefejl. AWS leverer flere lag af sundhedstjek: ELB-sundhedstjek registrerer usunde instanser, Route 53-sundhedstjek registrerer usunde slutpunkter, og Auto Scaling erstatter defekte instanser. Mønstre på applikationsniveau som kredsløbsafbrydere og nye forsøg fuldender billedet af robusthed.

ELB-sundhedstjek

Elastic Load Balancer-sundhedstjek sender med jævne mellemrum forespørgsler til registrerede mål for at afgøre, om de er sunde. Du konfigurerer stien til sundhedstjekket (f.eks. /health), protokollen, porten, intervallet (standard er 30 sekunder) og grænseværdien for sunde/usunde mål (antallet af efterfølgende succeser/fejl). Når et mål ikke består sundhedstjekket, stopper ELB med at dirigere trafik til det. Målet evalueres løbende igen og føjes tilbage, når det har bestået grænsen for sunde mål.

# 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

Route 53-sundhedstjek

Route 53-sundhedstjek overvåger slutpunkter fra flere placeringer globalt og fungerer sammen med DNS-failoverdirigering. Der findes tre typer: slutpunkttjek sender forespørgsler direkte til din program-URL. Beregnede tjek kombinerer flere underordnede sundhedstjek med AND/OR-logik (nyttigt til kompleks overvågning). CloudWatch-alarmtjek overlader vurderingen af sundhed til CloudWatch – det er nyttigt, når du ikke kan eksponere et offentligt sundhedsslutpunkt, eller når du har brug for sundhedsvurderinger baseret på målinger.

# 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
  }'

Sundhedstjek i Auto Scaling

Auto Scaling-grupper kan bruge to typer sundhedstjek: EC2-sundhedstjek registrerer fejl i instanser på hypervisor-niveau (fejl i instansens statustjek). ELB-sundhedstjek er mere opmærksomme på applikationen – en instans kan godt køre, men levere fejl, og det registrerer ELB-sundhedstjek. Du kan konfigurere ASG til at bruge ELB-sundhedstjek, så fejl på applikationsniveau også udløser udskiftning af instansen og ikke kun fejl i den underliggende EC2-infrastruktur.

# 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

Circuit Breaker-mønsteret

En circuit breaker er et mønster på applikationsniveau, der forhindrer kaskadefejl ved at overvåge kald til en underordnet tjeneste og midlertidigt stoppe kald, når antallet af fejl overskrider en grænseværdi. Circuit breakeren har tre tilstande: Lukket (normal drift), Åben (antallet af fejl har overskredet grænseværdien, og kald blokeres med det samme) og Halvåben (efter en timeout tillades et lille antal testkald for at kontrollere, om tjenesten er kommet sig). AWS App Mesh og SDK'er til applikationer som Resilience4j implementerer dette mønster.

# 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 til circuit breaking

AWS App Mesh er et tjenestenet, der implementerer circuit breaking, gentagelser og timeoutpolitikker på infrastrukturniveau uden ændringer i koden. Du definerer circuit breaker-politikker i konfigurationen af den virtuelle node eller den virtuelle router. Når en overordnet tjeneste bliver usund, åbner App Mesh' Envoy-proxy automatisk circuit breakeren og returnerer fejl med det samme i stedet for at vente på timeouts. Det er især værdifuldt i mikrotjenestearkitekturer, der kører på ECS eller 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
      }
    }]
  }
}

Gentagelseslogik og eksponentiel ventetid

Gentagelseslogik forsøger automatisk mislykkede handlinger igen, men naiv gentagelseslogik (øjeblikkelig gentagelse i en tæt løkke) kan forværre situationer med overbelastning. Eksponentiel ventetid øger ventetiden mellem gentagelser eksponentielt: 1s, 2s, 4s, 8s ... Det reducerer belastningen på en presset tjeneste og giver den tid til at komme sig. Tilfældig variation (randomisering af gentagelsesintervaller) forhindrer problemet med den stampende flok, hvor alle klienter forsøger igen samtidig efter en kortvarig afbrydelse. AWS SDK implementerer automatisk eksponentiel ventetid med tilfældig variation.

# 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)

Idempotens til sikre gentagelser

Gentagelser er kun sikre, hvis handlingerne er idempotente – udførelse af den samme handling flere gange giver det samme resultat. Hvis du f.eks. opretter et S3-objekt med den samme nøgle, er handlingen idempotent (samme resultat). Men hvis du afgiver en ordre to gange, oprettes der to ordrer – det er ikke idempotent. Design API'er, så de er idempotente, ved at bruge idempotensnøgler leveret af klienten: serveren gemmer resultatet af den første forespørgsel og returnerer det samme resultat for efterfølgende forespørgsler med den samme nøgle. DynamoDB, SQS og API Gateway understøtter mønstre med idempotensnøgler.

# 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

Konfiguration af timeouts

Uden eksplicitte timeouts får en langsom underordnet tjeneste tråde til at blokere uendeligt, så forbindelsespoolen tømmes, og der opstår kaskadefejl. Angiv timeouts på hvert lag: forbindelsestimeout (tiden det tager at oprette en TCP-forbindelse), læsetimeout (tiden det tager at modtage et svar) og timeout for den samlede forespørgsel. I AWS skal du konfigurere ELB's inaktivitetstimeout (standard 60 s), Lambdas kørselstimeout (maks. 15 min.) og API Gateways integrationstimeout (maks. 29 s). Timeouts udløser din logik for gentagelser eller circuit breaking.

# 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

Dead Letter Queues til mislykket behandling

Når behandling af meddelelser mislykkes gentagne gange, opsamler en Dead Letter Queue (DLQ) de meddelelser, der ikke kunne behandles efter det maksimale antal modtageforsøg. Konfigurer DLQ'er på SQS-køer og Lambda-hændelseskildetilknytninger for at forhindre, at ugyldige meddelelser blokerer din kø uendeligt. Meddelelser i DLQ'en kan undersøges, afspilles igen, efter at fejlen er rettet, eller arkiveres. DLQ'er er en vigtig komponent i robuste hændelsesdrevne arkitekturer.

# 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

Observation af fejl med CloudWatch

Effektive sundhedstjek og circuit breakere kræver overvågning, så du kan forstå fejlmønstre. CloudWatch er laget til observerbarhed: Opret alarmer på ELB UnHealthyHostCount (instanser, der ikke består sundhedstjek), frekvensen af Lambda Errors, SQS NumberOfMessagesSentToDLQ (meddelelser, der når DLQ'en) og målgruppens RequestCountPerTarget. Konfigurer SNS-notifikationer, så dit vagtteam straks får besked, når automatiske sundhedstjek registrerer forringet tilstand.

# 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

Hurtigt tjek

Test din forståelse af AWS Solutions Architect-konceptet (SAA-C03) fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion har du lært, at ELB- og Route 53-sundhedstjek automatiserer registrering af fejl på infrastrukturniveau, at circuit breakere forhindrer kaskadefejl ved at stoppe kald til usunde tjenester, og at eksponentiel ventetid med tilfældig variation gør gentagelser sikre under belastning. Dead Letter Queues opsamler mislykkede meddelelser, så de kan undersøges. Nu går vi videre til RTO, RPO og niveauer for katastrofegendannelse.

Gratis at komme i gang

Lær AWS Solutions Architect med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Tilstandstjek, circuit breakers og retry-logik” gratis?

Ja — alle 3 lektioner i læringssporet AWS Solutions Architect, inklusive “Tilstandstjek, circuit breakers og retry-logik”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Tilstandstjek, circuit breakers og retry-logik”?

Brug ELB-tilstandstjek, Route 53-endpointtjek og circuit breakers på applikationsniveau til automatisk at registrere fejl og omdirigere trafik Du øver dig i AWS Solutions Architect med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på AWS Solutions Architect?

Der kræves ingen tidligere erfaring. AWS Solutions Architect på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 4 af 4.

Hvor lang tid tager lektionen “Tilstandstjek, circuit breakers og retry-logik”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne AWS Solutions Architect-lektion?

Ja. Alle AWS Solutions Architect-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Høj tilgængelighed kontra fejltolerance: Definitioner og afvejninger
Multi-AZ-mønstre for tilstandsholdende tjenester
Multi-Region Active-Active og Active-Passive
Tilstandstjek, circuit breakers og retry-logik

← Tilbage til AWS Solutions Architect