Target groups og health checks

En målgruppe er en logisk samling af mål, som load balanceren router forespørgsler til. Hver målgruppe har en måltype, en protokol/port og en konfiguration for tilstandstjek. Load balanceren fordeler forespørgsler til registrerede mål i målgruppen, som består tilstandstjekkene.

Målgrupper knyttes til load balancer-lyttere gennem lytteregler. Én lytter kan route til flere målgrupper baseret på forespørgselsattributter. Dette er den centrale mekanisme bag sti-baseret og værtsbaseret routing i ALB.

Målgrupper understøtter tre måltyper:

• instance: router til EC2-instanser efter instans-ID; load balanceren sender trafik til instansens primære netværksinterface på den angivne port
• ip: router til private IP-adresser—nyttigt til mål i containere (ECS/EKS), lokale servere, der kan nås via VPN/Direct Connect, eller sekundære IP-adresser på EC2-instanser
• lambda: router til en enkelt Lambda-funktion (kun ALB); ALB konverterer HTTP-forespørgslen til en JSON-hændelse og kalder funktionen synkront

Måltypen IP er påkrævet for ECS-opgaver med netværkstilstanden awsvpc (hver opgave får sin egen IP), for EKS-pods og for hybride arkitekturer med lokale mål.

Du registrerer mål i en målgruppe manuelt (i konsollen eller CLI'en) eller automatisk (via tilknytning af en Auto Scaling Group eller konfiguration af en ECS-tjeneste). Mål, der registreres manuelt, forbliver i gruppen, indtil du eksplicit afregistrerer dem.

For ASG'er knytter du ASG'en til en målgruppe, hvorefter ASG'en automatisk registrerer nye instanser og afregistrerer afsluttede instanser. Denne tætte integration med ASG er standardmønsteret for elastiske computerlag – nye instanser kommer online og begynder at modtage trafik, så snart de består sundhedstjekket.

Hver målgruppe har et tilknyttet sundhedstjek, som load balanceren bruger til at afgøre, om et mål er sundt og kan modtage trafik. Sundhedstjekket sender periodiske anmodninger til hvert mål og evaluerer svaret:

• Protokol: HTTP, HTTPS eller TCP (for NLB)
• Sti: den URL-sti, der skal anmodes om (f.eks. /health eller /ping)
• Port: den port, der skal kontrolleres (som standard målgruppens port)
• Tærskel for sund: sammenhængende vellykkede tjek, før målet markeres som sundt
• Tærskel for usund: sammenhængende mislykkede tjek, før målet markeres som usundt
• Interval: sekunder mellem sundhedstjek (5–300)
• Timeout: sekunder, der skal ventes på et svar

For HTTP-/HTTPS-sundhedstjek angiver du, hvilke HTTP-svarkoder der angiver et sundt mål. Standardværdien er 200, men du kan konfigurere intervaller som 200-299 eller kommaseparerede værdier som 200,301,302.

Bedste praksis er at oprette et dedikeret /health-slutpunkt i din applikation, som kun returnerer 200, når alle kritiske afhængigheder er tilgængelige (databaseforbindelse, cache, downstream-tjeneste). Brug ikke rod-URL'en (/) som sti til sundhedstjekket, hvis den udfører ressourcekrævende handlinger eller kræver godkendelse.

Et mål gennemløber disse tilstande efter registrering:

• initial: ELB udfører de første sundhedstjek
• healthy: har bestået det krævede antal sammenhængende sundhedstjek og modtager trafik
• unhealthy: har ikke bestået det krævede antal sammenhængende sundhedstjek og fjernes fra rotationen
• draining: afregistrering er i gang; eksisterende forbindelser får lov til at afslutte, men der sendes ingen nye forbindelser
• unused: er registreret i gruppen, men ingen listener-regel sender i øjeblikket trafik til denne gruppe

Overvåg CloudWatch-metrikkerne UnHealthyHostCount og HealthyHostCount for at opdage problemer med din målinfrastruktur.

Afregistreringsforsinkelse (tidligere kaldet forbindelsesafvikling) er den tid, ELB venter på, at eksisterende forbindelser afsluttes, før et mål endeligt afregistreres. Standardværdien er 300 sekunder (5 minutter). I denne periode sendes ingen nye anmodninger til det mål, der afregistreres, men anmodninger, der allerede er under behandling, får lov til at afslutte.

Ved hurtige udrulninger og afslutning af instanser på grund af automatisk skalering kan du overveje at reducere dette til 30–60 sekunder, hvis din applikation håndterer anmodninger hurtigt. Ved langvarige handlinger (filuploads, videobehandling) bør du beholde en tilstrækkelig lang forsinkelse til, at handlingerne kan afsluttes uden afbrydelser.

Målgrupper understøtter forskellige load balancing-algoritmer:

• Round robin (ALB-standard): anmodninger fordeles jævnt efter tur – bedst, når alle mål er ens
• Færrest igangværende anmodninger (ALB): sender hver ny anmodning til det mål, der har færrest anmodninger under behandling – bedre til arbejdsbelastninger med varierende længde, hvor nogle anmodninger tager længere tid end andre
• Flow-hash (NLB): fordeler baseret på protokol, kilde-/destinations-IP, kilde-/destinationsport og TCP-sekvensnummer – sikrer, at alle pakker i et TCP-/UDP-flow sendes til det samme mål

For sessionsbaserede applikationer, hvor alle anmodninger fra en bruger skal nå det samme mål, skal du aktivere sticky sessions i stedet for at være afhængig af round-robin-fordeling.

En enkelt ALB-listenerregel kan fordele trafik på tværs af flere målgrupper med vægtede målgrupper. Du kan f.eks. sende 90 % af trafikken til en stabil målgruppe og 10 % til en canary-målgruppe ved blue-green-udrulninger – uden at bruge vægtet routing i Route 53.

Vægtede målgrupper konfigureres på listenerregel-niveau. Vægtene er relative: 90/10 sender 90 % til den første gruppe og 10 % til den anden. Det adskiller sig fra vægtet routing på tværs af flere ALB'er; her foregår det inden for en enkelt ALB-listenerregel.

Når du udruller ECS-tjenester bag en ALB, registreres hver ECS-opgave i ALB-målgruppen ved hjælp af ip-måltypen (for awsvpc-netværkstilstand). ECS-tjenesten håndterer registrering og afregistrering automatisk: nye opgaver registreres, når de har bestået sundhedstjek, og stoppede opgaver udløser afregistreringsforsinkelsen før afslutning.

Hver ECS-tjeneste kan registreres med en specifik tilsidesættelse af porten, så flere ECS-tjenester kan dele en enkelt ALB via forskellige listenerregler (sti- eller værtsbaserede) med forskellige målgrupper – et almindeligt mikrotjenestemønster.

NLB-sundhedstjek fungerer anderledes end ALB-sundhedstjek:

• NLB understøtter sundhedstjekprotokollerne TCP, HTTP og HTTPS uanset listenerens protokol
• NLB-sundhedstjek sendes fra NLB'ens IP-adresser i hver AZ – sørg for, at sikkerhedsgrupper tillader trafik fra NLB-undernettets IP-adresser, eller brug selve NLB'ens sikkerhedsgruppe
• Ved TCP-sundhedstjek anser NLB et mål for sundt, hvis det accepterer en TCP-forbindelse på den angivne port
• NLB-mål, der ikke består sundhedstjek, fjernes pr. AZ – hvis alle mål i en AZ er usunde, kan NLB udføre load balancing på tværs af zoner til sunde mål i andre AZ'er (hvis load balancing på tværs af zoner er aktiveret)

I denne lektion har du lært, at målgrupper indeholder sunde, registrerede mål af typen instans, IP eller Lambda, at sundhedstjek med jævne mellemrum kontrollerer mål for at fjerne usunde mål fra rotationen, og at afregistreringsforsinkelse sikrer en kontrolleret afvikling af anmodninger under behandling, før mål fjernes. Næste gang undersøger vi listenerregler og stibaseret routing på ALB'en.