Target Groups und Health Checks

Eine Zielgruppe ist eine logische Sammlung von Zielen, an die der Load Balancer Anfragen weiterleitet. Jede Zielgruppe verfügt über einen Zieltyp, ein Protokoll/einen Port und eine Konfiguration für Zustandsprüfungen. Der Load Balancer verteilt Anfragen auf die registrierten Ziele der Zielgruppe, die die Zustandsprüfungen bestehen.

Zielgruppen werden über Listener-Regeln mit Listenern von Load Balancern verknüpft. Ein Listener kann Anfragen anhand von Anfrageattributen an mehrere Zielgruppen weiterleiten. Dies ist der zentrale Mechanismus hinter pfad- und hostbasiertem Routing im ALB.

Zielgruppen unterstützen drei Zieltypen:

• instance: leitet anhand der Instance-ID an EC2-Instanzen weiter; der Load Balancer sendet den Datenverkehr über die primäre Netzwerkschnittstelle der Instanz an den angegebenen Port
• ip: leitet an private IP-Adressen weiter – nützlich für Ziele in Containern (ECS/EKS), On-Premises-Server, die über VPN/Direct Connect erreichbar sind, oder sekundäre IPs von EC2-Instanzen
• lambda: leitet an eine einzelne Lambda-Funktion weiter (nur ALB); der ALB wandelt die HTTP-Anfrage in ein JSON-Ereignis um und ruft die Funktion synchron auf

Der Zieltyp IP ist für ECS-Tasks mit dem Netzwerkmodus awsvpc (jeder Task erhält eine eigene IP), für EKS-Pods und für hybride Architekturen mit On-Premises-Zielen erforderlich.

Sie registrieren Ziele manuell (über die Konsole oder CLI) oder automatisch (durch die Zuordnung einer Auto Scaling Group oder die Konfiguration eines ECS-Service) bei einer Zielgruppe. Manuell registrierte Ziele bleiben in der Gruppe, bis Sie sie ausdrücklich deregistrieren.

Bei ASGs ordnen Sie die ASG einer Zielgruppe zu. Die ASG registriert neu gestartete Instances automatisch und deregistriert beendete Instances. Diese enge Integration mit ASGs ist das Standardmuster für elastische Compute-Tiers: Neue Instances werden gestartet und empfangen Datenverkehr, sobald sie den Health Check bestehen.

Jede Zielgruppe verfügt über einen zugehörigen Health Check, mit dem der Load Balancer ermittelt, ob ein Ziel gesund ist und Datenverkehr empfangen darf. Der Health Check sendet regelmäßig Anfragen an jedes Ziel und wertet die Antwort aus:

• Protokoll: HTTP, HTTPS oder TCP (für NLBs)
• Pfad: der anzufordernde URL-Pfad (z. B. /health oder /ping)
• Port: der zu prüfende Port (standardmäßig der Port der Zielgruppe)
• Schwellenwert für „gesund“: aufeinanderfolgende erfolgreiche Prüfungen, bevor das Ziel als gesund markiert wird
• Schwellenwert für „ungesund“: aufeinanderfolgende fehlgeschlagene Prüfungen, bevor das Ziel als ungesund markiert wird
• Intervall: Sekunden zwischen den Health Checks (5–300)
• Timeout: Sekunden, die auf eine Antwort gewartet wird

Bei HTTP-/HTTPS-Health-Checks legen Sie fest, welche HTTP-Antwortcodes ein gesundes Ziel anzeigen. Standardmäßig ist dies 200. Sie können jedoch auch Bereiche wie 200-299 oder durch Kommas getrennte Werte wie 200,301,302 konfigurieren.

Bewährte Vorgehensweise: Erstellen Sie in Ihrer Anwendung einen dedizierten Endpunkt /health, der nur dann 200 zurückgibt, wenn alle kritischen Abhängigkeiten verfügbar sind (Datenbankverbindung, Cache, nachgelagerter Service). Verwenden Sie nicht die Stamm-URL (/) als Health-Check-Pfad, wenn dabei aufwendige Vorgänge ausgeführt werden oder eine Authentifizierung erforderlich ist.

Nach der Registrierung durchläuft ein Ziel die folgenden Zustände:

• initial: ELB führt die ersten Health Checks durch
• healthy: Die erforderliche Anzahl aufeinanderfolgender Health Checks wurde bestanden; das Ziel empfängt Datenverkehr
• unhealthy: Die erforderliche Anzahl aufeinanderfolgender Health Checks wurde nicht bestanden; das Ziel wird aus der Verteilung entfernt
• draining: Die Deregistrierung läuft; bestehende Verbindungen dürfen abgeschlossen werden, es werden jedoch keine neuen Verbindungen gesendet
• unused: Das Ziel ist in der Gruppe registriert, aber derzeit leitet keine Listener-Regel Datenverkehr an diese Gruppe weiter

Überwachen Sie die CloudWatch-Metriken UnHealthyHostCount und HealthyHostCount, um Probleme mit Ihrer Zielflotte zu erkennen.

Die Deregistrierungsverzögerung (früher Connection Draining genannt) bezeichnet die Zeit, die ELB auf den Abschluss bestehender Verbindungen wartet, bevor ein Ziel endgültig deregistriert wird. Der Standardwert beträgt 300 Sekunden (5 Minuten). Während dieses Zeitraums werden keine neuen Anfragen an das Ziel gesendet, dessen Deregistrierung läuft. Bereits laufende Anfragen dürfen jedoch abgeschlossen werden.

Für schnelle Deployments und das Beenden von Instances durch Auto Scaling können Sie den Wert auf 30–60 Sekunden reduzieren, wenn Ihre Anwendung Anfragen schnell verarbeitet. Bei lang laufenden Vorgängen (Dateiuploads, Videoverarbeitung) sollten Sie einen ausreichend langen Zeitraum wählen, damit diese Vorgänge ohne Unterbrechung abgeschlossen werden können.

Zielgruppen unterstützen verschiedene Load-Balancing-Algorithmen:

• Round Robin (ALB-Standard): Anfragen werden abwechselnd gleichmäßig verteilt – am besten geeignet, wenn alle Ziele gleichwertig sind
• Least outstanding requests (ALB): Jede neue Anfrage wird an das Ziel mit den wenigsten laufenden Anfragen gesendet – besser geeignet für Workloads mit unterschiedlicher Laufzeit, bei denen manche Anfragen länger dauern als andere
• Flow hash (NLB): Die Verteilung basiert auf Protokoll, Quell-/Ziel-IP, Quell-/Zielport und TCP-Sequenznummer. Dadurch werden alle Pakete eines TCP-/UDP-Flows an dasselbe Ziel gesendet

Bei sitzungsbasierten Anwendungen, bei denen alle Anfragen eines Benutzers dasselbe Ziel erreichen müssen, aktivieren Sie Sticky Sessions, anstatt sich auf die Round-Robin-Verteilung zu verlassen.

Eine einzelne ALB-Listener-Regel kann Datenverkehr mithilfe von gewichteten Zielgruppen auf mehrere Zielgruppen verteilen. Sie können beispielsweise 90 % des Datenverkehrs an eine stabile Zielgruppe und 10 % an eine Canary-Zielgruppe weiterleiten, um Blue-Green-Deployments durchzuführen – ohne gewichtetes Routing in Route 53 zu verwenden.

Gewichtete Zielgruppen werden auf Ebene der Listener-Regel konfiguriert. Die Gewichtungen sind relativ: Bei 90/10 werden 90 % an die erste Gruppe und 10 % an die zweite gesendet. Dies unterscheidet sich vom gewichteten Routing über mehrere ALBs. Hier erfolgt die Verteilung innerhalb einer einzelnen ALB-Listener-Regel.

Wenn Sie ECS-Services hinter einem ALB bereitstellen, wird jede ECS-Task mithilfe des ip target type bei der ALB-Zielgruppe registriert (bei Verwendung des Netzwerkmodus awsvpc). Der ECS-Service verwaltet die Registrierung und Deregistrierung automatisch: Neue Tasks werden registriert, nachdem sie die Health Checks bestanden haben, und beim Stoppen von Tasks wird vor deren Beendigung die Deregistrierungsverzögerung ausgelöst.

Jeder ECS-Service kann mit einer bestimmten Portüberschreibung registriert werden. Dadurch können mehrere ECS-Services über unterschiedliche Listener-Regeln (pfad- oder hostbasiert) und verschiedene Zielgruppen einen einzelnen ALB gemeinsam nutzen – ein gängiges Muster für Microservices.

Das Verhalten von NLB-Health-Checks unterscheidet sich von dem eines ALB:

• NLB unterstützt die Health-Check-Protokolle TCP, HTTP und HTTPS unabhängig vom Listener-Protokoll
• NLB-Health-Checks werden von den IP-Adressen des NLB in jeder AZ gesendet. Stellen Sie sicher, dass Sicherheitsgruppen Datenverkehr von den Subnetz-IP-Adressen des NLB zulassen, oder verwenden Sie die Sicherheitsgruppe des NLB selbst
• Bei TCP-Health-Checks betrachtet NLB ein Ziel als gesund, wenn es eine TCP-Verbindung am angegebenen Port akzeptiert
• NLB-Ziele, die Health Checks nicht bestehen, werden pro AZ entfernt. Wenn alle Ziele einer AZ ungesund sind, kann NLB den Load Balancing über Availability Zones hinweg auf gesunde Ziele in anderen AZs verteilen (sofern Cross-Zone Load Balancing aktiviert ist)

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für die AWS Solutions Architect-Prüfung (SAA-C03).

In dieser Lektion haben Sie gelernt: Zielgruppen enthalten gesunde registrierte Ziele vom Typ Instance, IP oder Lambda, Health Checks prüfen Ziele regelmäßig, um ungesunde Ziele aus der Verteilung zu entfernen, und die Deregistrierungsverzögerung sorgt für ein kontrolliertes Auslaufen laufender Anfragen, bevor ein Ziel entfernt wird. Als Nächstes sehen wir uns Listener-Regeln und pfadbasiertes Routing auf dem ALB an.