AWS Solutions Architect · Les

Health checks, circuit breakers en retrylogica

Gebruik ELB-health checks, Route 53-endpointchecks en circuit breakers op applicatieniveau om storingen te detecteren en verkeer automatisch om te leiden.

Les 4 van 413 stappen

Health checks, circuit breakers en retrylogica is een gratis AWS Solutions Architect-les op CoddyKit. Dit is les 4 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject AWS Solutions Architect. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus AWS Solutions Architect bevat in totaal 4 lessen.

Waarom geautomatiseerde storingsdetectie belangrijk is

In gedistribueerde systemen vallen onderdelen voortdurend uit: instanties crashen, netwerkpartities ontstaan en downstreamservices raken overbelast. Zonder geautomatiseerde storingsdetectie blijft verkeer naar defecte onderdelen stromen, waardoor kettingstoringen ontstaan. AWS biedt meerdere lagen voor health checks: ELB-healthchecks detecteren ongezonde instanties, Route 53-healthchecks detecteren ongezonde eindpunten en Auto Scaling vervangt defecte instanties. Patronen op toepassingsniveau, zoals circuit breakers en nieuwe pogingen, maken het beeld van veerkracht compleet.

ELB-gezondheidscontroles

Gezondheidscontroles van Elastic Load Balancer sturen periodiek verzoeken naar geregistreerde doelen om te bepalen of deze gezond zijn. Je configureert het pad voor de gezondheidscontrole (bijvoorbeeld /health), het protocol, de poort, het interval (standaard 30 seconden) en de drempel voor gezond/ongezond (het aantal opeenvolgende geslaagde of mislukte controles). Wanneer een doel een gezondheidscontrole niet doorstaat, stopt ELB met het routeren van verkeer ernaartoe. Het doel wordt voortdurend opnieuw geëvalueerd en weer toegevoegd zodra het de drempel voor gezond bereikt.

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

Route 53-gezondheidscontroles bewaken eindpunten vanaf meerdere locaties wereldwijd en werken samen met DNS-failoverroutering. Er zijn drie typen: controles van eindpunten bevragen rechtstreeks de URL van je toepassing. Gecombineerde controles combineren meerdere onderliggende gezondheidscontroles met AND/OR-logica (handig voor complexe bewaking). CloudWatch-alarmcontroles laten CloudWatch bepalen of een eindpunt gezond is — nuttig wanneer je geen openbaar gezondheidseindpunt beschikbaar kunt maken of wanneer je gezondheidsbeslissingen op metingen wilt baseren.

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

Gezondheidscontroles voor automatisch schalen

Auto Scaling Groups kunnen twee typen gezondheidscontroles gebruiken: EC2-gezondheidscontroles detecteren storingen van instanties op hypervisorniveau (een mislukte statuscontrole van de instantie). ELB-gezondheidscontroles houden meer rekening met de toepassing: een instantie kan actief zijn maar fouten aanbieden, en ELB-gezondheidscontroles detecteren dit. Je kunt ASG zo configureren dat het ELB-gezondheidscontroles gebruikt, zodat storingen op toepassingsniveau ook vervanging van instanties starten, en niet alleen onderliggende EC2-storingen.

# 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

Het circuit-breakerpatroon

Een circuit breaker is een patroon op toepassingsniveau dat kettingreacties van storingen voorkomt door aanroepen naar een achterliggende service te bewaken en deze tijdelijk te stoppen wanneer het aantal storingen een drempel overschrijdt. Het circuit heeft drie statussen: Closed (normale werking), Open (de drempel voor storingen is overschreden en aanroepen worden direct geblokkeerd) en Half-Open (na een time-out wordt een klein aantal testaanroepen toegestaan om te controleren of de service is hersteld). AWS App Mesh en SDK's voor toepassingen, zoals Resilience4j, implementeren dit patroon.

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

AWS App Mesh is een servicemesh die circuit breaking, nieuwe pogingen en time-outbeleid op infrastructuurniveau implementeert, zonder wijzigingen in de code. Je definieert circuit-breakerbeleid in de configuratie van het virtuele knooppunt of de virtuele router. Wanneer een upstream-service ongezond wordt, opent de Envoy-proxy van App Mesh het circuit automatisch en retourneert deze direct fouten in plaats van op time-outs te wachten. Dit is vooral waardevol in microservicesarchitecturen die op ECS of EKS draaien.

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

Logica voor nieuwe pogingen en exponentiële wachttijd

Logica voor nieuwe pogingen probeert mislukte bewerkingen automatisch opnieuw uit, maar naïeve logica voor nieuwe pogingen (direct opnieuw proberen in een krappe lus) kan overbelasting verergeren. Exponentiële wachttijd verhoogt de wachttijd tussen nieuwe pogingen exponentieel: 1 s, 2 s, 4 s, 8 s... Hierdoor neemt de belasting van een overbelaste service af en krijgt deze tijd om te herstellen. Willekeurige variatie (de intervallen tussen nieuwe pogingen willekeurig maken) voorkomt het probleem van de denderende kudde, waarbij alle clients na een korte storing tegelijk opnieuw proberen. De AWS SDK implementeert automatisch exponentiële wachttijd met willekeurige variatie.

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

Idempotentie voor veilige nieuwe pogingen

Nieuwe pogingen zijn alleen veilig als bewerkingen idempotent zijn: dezelfde bewerking meerdere keren uitvoeren levert hetzelfde resultaat op. Het maken van een S3-object met dezelfde sleutel is bijvoorbeeld idempotent (het resultaat blijft hetzelfde). Maar een bestelling twee keer plaatsen maakt twee bestellingen aan en is dus niet idempotent. Ontwerp API's idempotent met behulp van door de client aangeleverde idempotentiesleutels: de server slaat het resultaat van het eerste verzoek op en retourneert hetzelfde resultaat voor volgende verzoeken met dezelfde sleutel. DynamoDB, SQS en API Gateway ondersteunen patronen met idempotentiesleutels.

# 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

Configuratie van time-outs

Zonder expliciete time-outs zorgt een trage achterliggende service ervoor dat threads onbeperkt geblokkeerd blijven. Hierdoor raakt de verbindingspool uitgeput en ontstaan kettingreacties van storingen. Stel op elke laag time-outs in: verbindings-time-out (de tijd om een TCP-verbinding tot stand te brengen), lees-time-out (de tijd om een antwoord te ontvangen) en algemene time-out voor verzoeken. Configureer in AWS de inactiviteitstime-out van ELB (standaard 60 seconden), de uitvoeringstime-out van Lambda (maximaal 15 minuten) en de integratie-time-out van API Gateway (maximaal 29 seconden). Time-outs activeren je logica voor nieuwe pogingen of circuit breakers.

# 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 voor mislukte verwerking

Wanneer de verwerking van berichten herhaaldelijk mislukt, vangt een Dead Letter Queue (DLQ) berichten op die na het maximale aantal ontvangstpogingen niet konden worden verwerkt. Configureer DLQ's voor SQS-wachtrijen en toewijzingen van Lambda-gebeurtenisbronnen om te voorkomen dat ongeldige berichten je wachtrij onbeperkt blokkeren. Berichten in de DLQ kun je inspecteren, opnieuw afspelen nadat je de fout hebt opgelost of archiveren. DLQ's zijn een cruciaal onderdeel van robuuste gebeurtenisgestuurde architecturen.

# 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

Storingen observeren met CloudWatch

Voor effectieve gezondheidscontroles en circuit breakers heb je bewaking nodig om storingspatronen te begrijpen. CloudWatch is de observatielaag: maak alarmen voor ELB UnHealthyHostCount (instanties die gezondheidscontroles niet doorstaan), het aantal Lambda Errors, SQS NumberOfMessagesSentToDLQ (berichten die de DLQ bereiken) en RequestCountPerTarget van de doeltroep. Stel SNS-meldingen in, zodat je team van dienst direct wordt gewaarschuwd wanneer geautomatiseerde gezondheidscontroles een verslechtering detecteren.

# 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

Korte toets

Toets je begrip van de AWS Solutions Architect-concepten (SAA-C03) uit deze les.

Beantwoord dit in de interactieve les

Samenvatting van de les

In deze les heb je geleerd dat ELB- en Route 53-gezondheidscontroles het detecteren van storingen op infrastructuurniveau automatiseren, dat circuit breakers kettingreacties van storingen voorkomen door aanroepen naar ongezonde services te stoppen en dat exponentiële wachttijd met willekeurige variatie nieuwe pogingen veilig maakt bij hoge belasting. Dead Letter Queues vangen mislukte berichten op voor inspectie. Hierna behandelen we RTO, RPO en niveaus voor herstel na calamiteiten.

Gratis beginnen

Leer AWS Solutions Architect met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 30
Lessen: 120

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Health checks, circuit breakers en retrylogica” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad AWS Solutions Architect, waaronder “Health checks, circuit breakers en retrylogica”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus AWS Solutions Architect bevat in totaal 4 lessen.

Wat leer ik in “Health checks, circuit breakers en retrylogica”?

Gebruik ELB-health checks, Route 53-endpointchecks en circuit breakers op applicatieniveau om storingen te detecteren en verkeer automatisch om te leiden. Je oefent met AWS Solutions Architect door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met AWS Solutions Architect te beginnen?

Ervaring vooraf is niet nodig. AWS Solutions Architect op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 4 van 4.

Hoe lang duurt de les “Health checks, circuit breakers en retrylogica”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over AWS Solutions Architect?

Ja. Elke les over AWS Solutions Architect bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

Hoge beschikbaarheid versus fouttolerantie: definities en afwegingen
Multi-AZ-patronen voor stateful services
Multi-Region active-active en active-passive
Health checks, circuit breakers en retrylogica

← Terug naar AWS Solutions Architect