0Pricing
Cloud & IT Cert Prep · Lektion

Health Checks, Circuit Breaker und Retry-Logik

Verwenden Sie ELB-Health-Checks, Route-53-Endpunktprüfungen und anwendungseigene Circuit Breaker, um Ausfälle zu erkennen und Datenverkehr automatisch umzuleiten.

Health Checks, Circuit Breaker und Retry-Logik ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Warum die automatische Ausfallerkennung wichtig ist

In verteilten Systemen fallen Komponenten fortlaufend aus: Instanzen stürzen ab, Netzwerkpartitionen treten auf und nachgelagerte Services werden überlastet. Ohne automatische Ausfallerkennung wird der Datenverkehr weiterhin an ausgefallene Komponenten geleitet, was kaskadierende Ausfälle verursachen kann. AWS bietet mehrere Ebenen für Zustandsprüfungen: ELB-Zustandsprüfungen erkennen fehlerhafte Instanzen, Route-53-Zustandsprüfungen erkennen fehlerhafte Endpunkte und Auto Scaling ersetzt ausgefallene Instanzen. Anwendungsmuster wie Circuit Breaker und Wiederholungsversuche vervollständigen das Resilienzkonzept.

ELB-Zustandsprüfungen

Elastic Load Balancer-Zustandsprüfungen senden regelmäßig Anfragen an registrierte Ziele, um festzustellen, ob diese fehlerfrei sind. Sie konfigurieren den Pfad für die Zustandsprüfung (z. B. /health), das Protokoll, den Port, das Intervall (Standard: 30 Sekunden) sowie den Schwellenwert für fehlerfreie bzw. fehlerhafte Ziele (Anzahl aufeinanderfolgender Erfolge bzw. Fehler). Wenn ein Ziel die Zustandsprüfungen nicht besteht, leitet der ELB keinen Datenverkehr mehr dorthin weiter. Das Ziel wird kontinuierlich erneut bewertet und wieder hinzugefügt, sobald es den Schwellenwert für fehlerfreie Ziele erreicht.

# 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-Zustandsprüfungen

Route-53-Zustandsprüfungen überwachen Endpunkte von mehreren Standorten weltweit und arbeiten mit DNS-Failover-Routing zusammen. Es gibt drei Typen: Endpunktprüfungen fragen Ihre Anwendungs-URL direkt ab. Berechnete Prüfungen kombinieren mehrere untergeordnete Zustandsprüfungen mit einer AND-/OR-Logik und eignen sich für komplexe Überwachungsszenarien. CloudWatch-Alarmprüfungen überlassen die Zustandsbestimmung CloudWatch. Das ist nützlich, wenn Sie keinen öffentlich erreichbaren Zustandsendpunkt bereitstellen können oder eine zustandsbasierte Entscheidung anhand von Metriken benötigen.

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

Zustandsprüfungen für Auto Scaling

Auto Scaling Groups können zwei Arten von Zustandsprüfungen verwenden: EC2-Zustandsprüfungen erkennen Instanzfehler auf Hypervisor-Ebene (Fehler bei der Statusprüfung der Instanz). ELB-Zustandsprüfungen berücksichtigen die Anwendung stärker: Eine Instanz kann zwar ausgeführt werden, aber Fehler zurückgeben, die von den ELB-Zustandsprüfungen erkannt werden. Sie können die ASG so konfigurieren, dass sie ELB-Zustandsprüfungen verwendet. Dadurch lösen auch Fehler auf Anwendungsebene den Austausch einer Instanz aus und nicht nur zugrunde liegende EC2-Fehler.

# 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

Das Circuit-Breaker-Muster

Ein Circuit Breaker ist ein Muster auf Anwendungsebene, das kaskadierende Fehler verhindert, indem es Aufrufe an einen nachgelagerten Service überwacht und Aufrufe vorübergehend stoppt, wenn die Fehler einen Schwellenwert überschreiten. Der Circuit hat drei Zustände: Closed (Normalbetrieb), Open (der Schwellenwert für Fehler wurde überschritten, Aufrufe werden sofort blockiert) und Half-Open (nach einer Zeitüberschreitung wird eine kleine Anzahl von Testaufrufen zugelassen, um zu prüfen, ob sich der Service erholt hat). AWS App Mesh und Anwendungs-SDKs wie Resilience4j implementieren dieses Muster.

# 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 ist ein Service Mesh, das Circuit Breaking, Wiederholungen und Zeitüberschreitungsrichtlinien auf Infrastrukturebene implementiert, ohne dass Codeänderungen erforderlich sind. Sie definieren Circuit-Breaker-Richtlinien in der Konfiguration des virtuellen Knotens oder virtuellen Routers. Wenn ein vorgelagerter Service fehlerhaft wird, öffnet der Envoy-Proxy von App Mesh den Circuit automatisch und gibt sofort Fehler zurück, statt auf Zeitüberschreitungen zu warten. Das ist besonders wertvoll in Microservices-Architekturen, die auf ECS oder EKS ausgeführt werden.

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

Wiederholungslogik und exponentielles Backoff

Wiederholungslogik versucht fehlgeschlagene Vorgänge automatisch erneut auszuführen. Eine naive Wiederholungslogik (sofortige Wiederholung in einer engen Schleife) kann Überlastungssituationen jedoch verschärfen. Beim exponentiellen Backoff wird die Wartezeit zwischen Wiederholungen exponentiell erhöht: 1 s, 2 s, 4 s, 8 s ... Dadurch wird ein überlasteter Service entlastet und erhält Zeit zur Erholung. Jitter (zufällige Variation der Wiederholungsintervalle) verhindert das Thundering-Herd-Problem, bei dem alle Clients nach einem kurzen Ausfall gleichzeitig neue Versuche starten. Das AWS SDK implementiert exponentielles Backoff mit Jitter automatisch.

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

Idempotenz für sichere Wiederholungen

Wiederholungen sind nur dann sicher, wenn Vorgänge idempotent sind – wenn also die mehrfache Ausführung desselben Vorgangs dasselbe Ergebnis liefert. Das Erstellen eines S3-Objekts mit demselben Schlüssel ist beispielsweise idempotent und liefert dasselbe Ergebnis. Wird eine Bestellung jedoch zweimal aufgegeben, entstehen zwei Bestellungen – der Vorgang ist nicht idempotent. Entwerfen Sie APIs mithilfe von vom Client bereitgestellten Idempotenzschlüsseln idempotent: Der Server speichert das Ergebnis der ersten Anfrage und gibt bei nachfolgenden Anfragen mit demselben Schlüssel dasselbe Ergebnis zurück. DynamoDB, SQS und API Gateway unterstützen Muster mit Idempotenzschlüsseln.

# 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 von Zeitüberschreitungen

Ohne ausdrücklich festgelegte Zeitüberschreitungen führt ein langsamer nachgelagerter Service dazu, dass Threads auf unbestimmte Zeit blockiert werden. Dadurch wird der Verbindungspool erschöpft und es können kaskadierende Fehler entstehen. Legen Sie auf jeder Ebene Zeitüberschreitungen fest: Verbindungs-Timeout (Zeit zum Herstellen der TCP-Verbindung), Read-Timeout (Zeit bis zum Empfang einer Antwort) und Gesamt-Timeout für die Anfrage. Konfigurieren Sie in AWS das ELB-Idle-Timeout (Standard: 60 s), das Lambda-Ausführungs-Timeout (maximal 15 Minuten) und das Integration-Timeout von API Gateway (maximal 29 s). Zeitüberschreitungen lösen Ihre Wiederholungs- oder Circuit-Breaker-Logik aus.

# 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 fehlgeschlagene Verarbeitung

Wenn die Verarbeitung einer Nachricht wiederholt fehlschlägt, erfasst eine Dead Letter Queue (DLQ) Nachrichten, die nach der maximalen Anzahl von Empfangsversuchen nicht verarbeitet werden konnten. Konfigurieren Sie DLQs für SQS-Warteschlangen und Lambda-Ereignisquellzuordnungen, damit fehlerhafte Nachrichten Ihre Warteschlange nicht auf unbestimmte Zeit blockieren. Nachrichten in der DLQ können untersucht, nach der Fehlerbehebung erneut verarbeitet oder archiviert werden. DLQs sind ein wichtiger Bestandteil ausfallsicherer ereignisgesteuerter Architekturen.

# 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

Fehler mit CloudWatch beobachten

Wirksame Zustandsprüfungen und Circuit Breaker erfordern eine Überwachung, um Fehlermuster zu verstehen. CloudWatch ist die Observability-Ebene: Erstellen Sie Alarme für ELB UnHealthyHostCount (Instanzen, die Zustandsprüfungen nicht bestehen), die Rate von Lambda Errors, SQS NumberOfMessagesSentToDLQ (Nachrichten, die in der DLQ landen) und RequestCountPerTarget der Target group. Richten Sie SNS-Benachrichtigungen ein, damit Ihr Bereitschaftsteam sofort alarmiert wird, wenn automatisierte Zustandsprüfungen eine Verschlechterung erkennen.

# 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

Kurztest

Testen Sie Ihr Verständnis der Konzepte aus AWS Solutions Architect (SAA-C03) in dieser Lektion.

Zusammenfassung der Lektion

In dieser Lektion haben Sie gelernt: ELB- und Route-53-Zustandsprüfungen automatisieren die Fehlererkennung auf Infrastrukturebene, Circuit Breaker verhindern kaskadierende Fehler, indem sie Aufrufe an fehlerhafte Services stoppen, und exponentielles Backoff mit Jitter macht Wiederholungen unter Last sicher. Dead-Letter-Queues erfassen fehlgeschlagene Nachrichten zur Untersuchung. Als Nächstes befassen wir uns mit RTO, RPO und Disaster-Recovery-Stufen.

Häufig gestellte Fragen

Ist die Lektion „Health Checks, Circuit Breaker und Retry-Logik“ kostenlos?

Ja — der vollständige Text von „Health Checks, Circuit Breaker und Retry-Logik“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Health Checks, Circuit Breaker und Retry-Logik“?

Verwenden Sie ELB-Health-Checks, Route-53-Endpunktprüfungen und anwendungseigene Circuit Breaker, um Ausfälle zu erkennen und Datenverkehr automatisch umzuleiten. Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?

Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Health Checks, Circuit Breaker und Retry-Logik“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?

Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Hohe Verfügbarkeit im Vergleich zu Fehlertoleranz: Definitionen und Abwägungen
  2. Multi-AZ-Muster für zustandsbehaftete Services
  3. Multi-Region Active-Active und Active-Passive
  4. Health Checks, Circuit Breaker und Retry-Logik
← Zurück zu Cloud & IT Cert Prep