Target groups en health checks

Een doelgroep is een logische verzameling doelen waarnaar de load balancer aanvragen routeert. Elke doelgroep heeft een doeltype, een protocol/poort en een configuratie voor statuscontroles. De load balancer verdeelt aanvragen over geregistreerde doelen in de doelgroep die de statuscontroles doorstaan.

Doelgroepen worden via listenerregels gekoppeld aan listeners van load balancers. Eén listener kan aanvragen naar meerdere doelgroepen routeren op basis van kenmerken van de aanvraag. Dit is het belangrijkste mechanisme achter routering op basis van paden en hosts in ALB.

Doelgroepen ondersteunen drie doeltypen:

• instance: routeert naar EC2-instanties op basis van de instantie-ID; de load balancer stuurt verkeer naar de primaire netwerkinterface van de instantie op de opgegeven poort
• ip: routeert naar privé-IP-adressen—handig voor doelen in containers (ECS/EKS), on-premises servers die bereikbaar zijn via VPN/Direct Connect of secundaire IP-adressen van EC2-instanties
• lambda: routeert naar één Lambda-functie (alleen ALB); ALB converteert de HTTP-aanvraag naar een JSON-gebeurtenis en roept de functie synchroon aan

Het doeltype IP is vereist voor ECS-taken met de netwerkmodus awsvpc (elke taak krijgt een eigen IP-adres), voor EKS-pods en voor hybride architecturen met on-premises doelen.

Je registreert doelservers handmatig (in de console of CLI) of automatisch (via koppeling aan een Auto Scaling Group of configuratie van een ECS-service) bij een doelgroep. Handmatig geregistreerde doelservers blijven in de groep totdat je ze expliciet deregistreert.

Bij ASG's koppel je de ASG aan een doelgroep. De ASG registreert automatisch nieuw gestarte instanties en deregistreert beëindigde instanties. Deze nauwe integratie met ASG is het standaardpatroon voor elastische computelagen: nieuwe instanties komen online en ontvangen verkeer zodra ze de statuscontrole doorstaan.

Elke doelgroep heeft een bijbehorende statuscontrole die de load balancer gebruikt om te bepalen of een doelserver gezond is en verkeer mag ontvangen. De statuscontrole verstuurt periodiek verzoeken naar elke doelserver en beoordeelt het antwoord:

• Protocol: HTTP, HTTPS of TCP (voor NLB)
• Pad: het URL-pad dat moet worden opgevraagd (bijvoorbeeld /health of /ping)
• Poort: de poort die moet worden gecontroleerd (standaard de poort van de doelgroep)
• Drempelwaarde voor gezond: het aantal opeenvolgende geslaagde controles voordat de doelserver als gezond wordt gemarkeerd
• Drempelwaarde voor ongezond: het aantal opeenvolgende mislukte controles voordat de doelserver als ongezond wordt gemarkeerd
• Interval: het aantal seconden tussen statuscontroles (5–300)
• Time-out: het aantal seconden dat op een antwoord wordt gewacht

Voor HTTP/HTTPS-statuscontroles geef je op welke HTTP-antwoordcodes een gezonde doelserver aangeven. De standaardwaarde is 200, maar je kunt bereiken zoals 200-299 of door komma's gescheiden waarden zoals 200,301,302 configureren.

Best practice: maak in je applicatie een speciaal /health-eindpunt dat alleen 200 retourneert wanneer alle kritieke afhankelijkheden beschikbaar zijn (databaseverbinding, cache, downstreamservice). Gebruik de hoofdpagina (/) niet als pad voor de statuscontrole als die dure bewerkingen uitvoert of authenticatie vereist.

Na registratie doorloopt een doelserver de volgende statussen:

• initial: ELB voert de eerste statuscontroles uit
• healthy: de vereiste opeenvolgende statuscontroles zijn geslaagd; de doelserver ontvangt verkeer
• unhealthy: de vereiste opeenvolgende statuscontroles zijn mislukt; de doelserver wordt uit de verdeling verwijderd
• draining: de deregistratie is bezig; bestaande verbindingen mogen worden voltooid, maar er worden geen nieuwe verbindingen verstuurd
• unused: de doelserver is in de groep geregistreerd, maar geen enkele listenerregel routeert momenteel naar deze groep

Houd de CloudWatch-statistieken UnHealthyHostCount en HealthyHostCount in de gaten om problemen met je vloot van doelservers te detecteren.

Deregistratievertraging (voorheen verbindingen laten leeglopen genoemd) is de tijd die ELB wacht totdat bestaande verbindingen zijn voltooid voordat een doelserver definitief wordt gederegistreerd. De standaardwaarde is 300 seconden (5 minuten). Tijdens deze periode worden geen nieuwe verzoeken naar de doelserver in kwestie verstuurd, maar verzoeken die al worden verwerkt mogen worden voltooid.

Voor snelle implementaties en beëindigingen door automatisch schalen kun je deze waarde verlagen naar 30–60 seconden als je applicatie verzoeken snel verwerkt. Voor langlopende bewerkingen (bestandsuploads, videobewerking) houd je de waarde lang genoeg om deze bewerkingen zonder onderbreking te voltooien.

Doelgroepen ondersteunen verschillende algoritmen voor load balancing:

• Round-robin (standaard voor ALB): verzoeken worden gelijkmatig om en om verdeeld — het meest geschikt wanneer alle doelservers gelijkwaardig zijn
• Minste openstaande verzoeken (ALB): elk nieuw verzoek wordt naar de doelserver met de minste verzoeken in verwerking gestuurd — beter voor werklasten met variabele duur, waarbij sommige verzoeken langer duren dan andere
• Flow-hash (NLB): de verdeling is gebaseerd op protocol, bron- en doel-IP-adres, bron- en doelpoort en TCP-volgnummer — hierdoor gaan alle pakketten in een TCP/UDP-stroom naar dezelfde doelserver

Schakel voor sessiegebaseerde applicaties waarbij alle verzoeken van een gebruiker dezelfde doelserver moeten bereiken sticky sessions in, in plaats van te vertrouwen op een round-robinverdeling.

Met één ALB-listenerregel kun je verkeer over meerdere doelgroepen verdelen met doelgroepen met gewichten. Je kunt bijvoorbeeld 90% van het verkeer naar een stabiele doelgroep en 10% naar een canary-doelgroep routeren voor blue-green-implementaties, zonder gewogen routering van Route 53 te gebruiken.

Doelgroepen met gewichten worden geconfigureerd op regelniveau van de listener. De gewichten zijn relatief: 90/10 stuurt 90% naar de eerste groep en 10% naar de tweede. Dit verschilt van gewogen routering over meerdere ALB's; hier vindt de verdeling plaats binnen één ALB-listenerregel.

Wanneer je ECS-services achter een ALB implementeert, wordt elke ECS-task bij de ALB-doelgroep geregistreerd met het ip-doeltype (voor de netwerkmodus awsvpc). De ECS-service beheert registratie en deregistratie automatisch: nieuwe tasks worden geregistreerd nadat ze de statuscontroles hebben doorstaan, en bij het stoppen van tasks wordt vóór beëindiging de deregistratievertraging toegepast.

Elke ECS-service kan met een specifieke poortoverschrijving worden geregistreerd. Hierdoor kunnen meerdere ECS-services één ALB delen via verschillende listenerregels (op basis van pad of host) met verschillende doelgroepen — een veelgebruikt microservicespatroon.

Het gedrag van NLB-statuscontroles verschilt van dat van ALB:

• NLB ondersteunt de protocollen TCP, HTTP en HTTPS voor statuscontroles, ongeacht het listenerprotocol
• NLB-statuscontroles worden verstuurd vanaf de IP-adressen van de NLB in elke AZ — zorg ervoor dat beveiligingsgroepen verkeer vanaf de subnet-IP-adressen van de NLB toestaan, of gebruik de beveiligingsgroep van de NLB zelf
• Bij TCP-statuscontroles beschouwt NLB een doelserver als gezond wanneer die een TCP-verbinding op de opgegeven poort accepteert
• NLB-doelservers die statuscontroles niet doorstaan, worden per AZ verwijderd — als alle doelservers in een AZ ongezond zijn, kan NLB verkeer zoneoverschrijdend verdelen over gezonde doelservers in andere AZ's (als zoneoverschrijdende LB is ingeschakeld)

In deze les heb je geleerd dat doelgroepen gezonde, geregistreerde doelservers bevatten van het type instantie, IP of Lambda, dat statuscontroles doelservers periodiek controleren om ongezonde doelservers uit de verdeling te verwijderen, en dat deregistratievertraging zorgt voor het gecontroleerd leeg laten lopen van verzoeken die nog worden verwerkt voordat een doelserver wordt verwijderd. Hierna bekijken we listenerregels en routering op basis van paden op de ALB.