Cloud & IT Cert Prep · Lektion

Hälsokontroller, kretsbrytare och återförsökslogik

Använd ELB-hälsokontroller, slutpunktskontroller i Route 53 och kretsbrytare på programnivå för att upptäcka fel och automatiskt dirigera om trafiken.

Lektion 4 av 413 steg

Hälsokontroller, kretsbrytare och återförsökslogik är en gratis lektion i Cloud & IT Cert Prep på CoddyKit. Detta är lektion 4 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Cloud & IT Cert Prep, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Cloud & IT Cert Prep innehåller totalt 4 lektioner.

Varför automatiserad feldetektering är viktig

I distribuerade system uppstår fel kontinuerligt – instanser kraschar, nätverkspartitioner inträffar och nedströms tjänster blir överbelastade. Utan automatiserad feldetektering fortsätter trafiken att flöda till komponenter som slutat fungera, vilket orsakar kaskadfel. AWS tillhandahåller flera lager av hälsokontroller: ELB-hälsokontroller upptäcker instanser som inte är friska, Route 53-hälsokontroller upptäcker slutpunkter som inte är friska och Auto Scaling ersätter instanser som slutat fungera. Mönster på programnivå, som kretsbrytare och nya försök, kompletterar bilden av motståndskraft.

ELB-hälsokontroller

Elastic Load Balancer-hälsokontroller skickar regelbundet förfrågningar till registrerade mål för att avgöra om de är friska. Ni konfigurerar sökvägen för hälsokontrollen (t.ex. /health), protokoll, port, intervall (standardvärde: 30 sekunder) samt tröskelvärdena för frisk och ofrisk (antalet lyckade eller misslyckade försök i följd). När ett mål misslyckas med hälsokontrollerna slutar ELB att dirigera trafik till det. Målet utvärderas kontinuerligt på nytt och läggs tillbaka när det har klarat tröskelvärdet för friskt tillstånd.

# 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-hälsokontroller

Route 53-hälsokontroller övervakar slutpunkter från flera platser globalt och fungerar tillsammans med DNS-baserad failover-dirigering. Det finns tre typer: slutpunktskontroller skickar direkta förfrågningar till programmets URL. Beräknade kontroller kombinerar flera underordnade hälsokontroller med AND/OR-logik (användbart för komplex övervakning). CloudWatch-larmkontroller överlåter hälsobedömningen till CloudWatch – användbart när ni inte kan exponera en offentlig hälsoslutpunkt eller behöver fatta hälsobeslut baserat på mätvärden.

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

Hälsokontroller för Auto Scaling

Auto Scaling Groups kan använda två typer av hälsokontroller: EC2-hälsokontroller upptäcker instansfel på hypervisor-nivå (misslyckad statuskontroll för instansen). ELB-hälsokontroller är mer medvetna om programmets tillstånd – en instans kan vara igång men ändå leverera fel, vilket ELB-hälsokontroller upptäcker. Ni kan konfigurera ASG att använda ELB-hälsokontroller, så att fel på programnivå också utlöser ersättning av instansen, inte bara underliggande EC2-fel.

# 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önstret

En circuit breaker är ett mönster på programnivå som förhindrar kaskadfel genom att övervaka anrop till en underordnad tjänst och tillfälligt stoppa anrop när antalet fel överskrider ett tröskelvärde. Kretsen har tre tillstånd: Closed (normal drift), Open (tröskelvärdet har överskridits och anrop blockeras omedelbart) och Half-Open (efter en timeout tillåts ett litet antal testanrop för att kontrollera om tjänsten har återhämtat sig). AWS App Mesh och SDK:er för program, till exempel Resilience4j, implementerar detta 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 för circuit breaking

AWS App Mesh är ett service mesh som implementerar circuit breaking, återförsök och timeout-principer på infrastrukturnivå utan kodändringar. Ni definierar circuit breaker-principer i konfigurationen för den virtuella noden eller den virtuella routern. När en uppströms tjänst blir ofrisk öppnar App Meshs Envoy-proxy automatiskt kretsen och returnerar fel omedelbart i stället för att vänta på timeouts. Detta är särskilt värdefullt i mikrotjänstarkitekturer som körs 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
      }
    }]
  }
}

Återförsökslogik och exponentiell backoff

Återförsökslogik försöker automatiskt utföra misslyckade åtgärder igen, men naiv återförsökslogik (omedelbara återförsök i en tät loop) kan förvärra situationer med överbelastning. Exponentiell backoff ökar väntetiden mellan återförsöken exponentiellt: 1 s, 2 s, 4 s, 8 s ... Detta minskar belastningen på en överbelastad tjänst och ger den tid att återhämta sig. Jitter (slumpmässiga återförsöksintervall) förhindrar problemet med thundering herd, där alla klienter försöker igen samtidigt efter ett kort avbrott. AWS SDK implementerar automatiskt exponentiell backoff med jitter.

# 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 för säkra återförsök

Återförsök är bara säkra om åtgärderna är idempotenta – att utföra samma åtgärd flera gånger ger samma resultat. Att skapa ett S3-objekt med samma nyckel är till exempel idempotent (samma resultat). Men om en order läggs två gånger skapas två ordrar – det är inte idempotent. Utforma API:er så att de är idempotenta genom att använda idempotensnycklar från klienten: servern lagrar resultatet från den första förfrågan och returnerar samma resultat för efterföljande förfrågningar med samma nyckel. DynamoDB, SQS och API Gateway stöder mönster med idempotensnycklar.

# 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 av timeouts

Utan explicita timeouts gör en långsam underordnad tjänst att trådar blockeras på obestämd tid, vilket tömmer anslutningspoolen och orsakar kaskadfel. Ange timeouts på varje lager: anslutningstimeout (tiden det tar att upprätta en TCP-anslutning), läs-timeout (tiden det tar att ta emot ett svar) och timeout för hela förfrågan. I AWS konfigurerar ni ELB:s idle-timeout (standardvärde: 60 s), Lambdas exekveringstimeout (högst 15 min) och API Gateways integrationstimeout (högst 29 s). Timeouts utlöser er återförsöks- eller circuit breaker-logik.

# 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 för misslyckad bearbetning

När meddelandebearbetning misslyckas upprepade gånger fångar en Dead Letter Queue (DLQ) upp meddelanden som inte kunde bearbetas efter det maximala antalet mottagningsförsök. Konfigurera DLQ:er för SQS-köer och Lambdas mappningar av händelsekällor för att förhindra att felaktiga meddelanden blockerar kön på obestämd tid. Meddelanden i DLQ:n kan granskas, spelas upp igen efter att felet har åtgärdats eller arkiveras. DLQ:er är en viktig del av motståndskraftiga händelsestyrda 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

Observera fel med CloudWatch

Effektiva hälsokontroller och circuit breakers kräver övervakning för att ni ska kunna förstå felmönster. CloudWatch är observability-lagret: skapa larm för ELB UnHealthyHostCount (instanser som misslyckas med hälsokontroller), frekvensen av Lambda Errors, SQS NumberOfMessagesSentToDLQ (meddelanden som hamnar i DLQ) och Target group RequestCountPerTarget. Konfigurera SNS-aviseringar så att ert jourteam omedelbart meddelas när automatiska hälsokontroller upptäcker försämrad funktion.

# 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

Snabbkontroll

Testa er förståelse av begreppen från AWS Solutions Architect (SAA-C03) i den här lektionen.

Besvara frågan i den interaktiva lektionen

Lektionssammanfattning

I den här lektionen har ni lärt er att: ELB- och Route 53-hälsokontroller automatiserar feldetektering på infrastrukturnivå, circuit breakers förhindrar kaskadfel genom att stoppa anrop till sjuka tjänster och exponentiell backoff med jitter gör återförsök säkra under belastning. Dead Letter Queues fångar upp misslyckade meddelanden för granskning. Härnäst går vi igenom RTO, RPO och nivåer för katastrofåterställning.

Gratis att börja

Lär dig Cloud & IT Cert Prep med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 150
Lektioner: 600

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Hälsokontroller, kretsbrytare och återförsökslogik” gratis?

Ja – hela texten till ”Hälsokontroller, kretsbrytare och återförsökslogik” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Cloud & IT Cert Prep, kan Ni uppgradera till CoddyKit PRO. Kursen i Cloud & IT Cert Prep innehåller totalt 4 lektioner.

Vad lär jag mig i ”Hälsokontroller, kretsbrytare och återförsökslogik”?

Använd ELB-hälsokontroller, slutpunktskontroller i Route 53 och kretsbrytare på programnivå för att upptäcka fel och automatiskt dirigera om trafiken. Ni övar på Cloud & IT Cert Prep med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Cloud & IT Cert Prep?

Du behöver inga förkunskaper. Utbildningen i Cloud & IT Cert Prep på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 4 av 4.

Hur lång tid tar lektionen ”Hälsokontroller, kretsbrytare och återförsökslogik”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Cloud & IT Cert Prep-lektionen?

Ja. Varje Cloud & IT Cert Prep-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

Hög tillgänglighet jämfört med feltolerans: Definitioner och avvägningar
Multi-AZ-mönster för tillståndsbaserade tjänster
Multi-Region Active-Active och Active-Passive
Hälsokontroller, kretsbrytare och återförsökslogik

← Tillbaka till Cloud & IT Cert Prep