Målgrupper og helsesjekker

De registrerer mål i en målgruppe manuelt (i konsollen eller CLI) eller automatisk (via tilknytning til en Auto Scaling-gruppe eller konfigurasjon av en ECS-tjeneste). Mål som registreres manuelt, forblir i gruppen til De eksplisitt avregistrerer dem.

For ASG-er knytter De ASG-en til en målgruppe, og ASG-en registrerer automatisk nye instanser og avregistrerer terminerte instanser. Denne tette integrasjonen med ASG er standardmønsteret for elastiske databehandlingslag – nye instanser blir tilgjengelige og begynner å motta trafikk så snart de består helsesjekken.

Hver målgruppe har en tilknyttet helsesjekk som lastbalansereren bruker til å avgjøre om et mål er friskt og kvalifisert til å motta trafikk. Helsesjekken sender periodiske forespørsler til hvert mål og evaluerer svaret:

• Protokoll: HTTP, HTTPS eller TCP (for NLB)
• Bane: URL-banen som skal forespørres (f.eks. /health eller /ping)
• Port: porten som skal kontrolleres (som standard porten til målgruppen)
• Grense for frisk: antall sammenhengende vellykkede kontroller før målet markeres som friskt
• Grense for usunn: antall sammenhengende mislykkede kontroller før målet markeres som usunt
• Intervall: antall sekunder mellom helsesjekkene (5–300)
• Tidsavbrudd: antall sekunder det skal ventes på et svar

For HTTP-/HTTPS-helsesjekker angir De hvilke HTTP-svarkoder som indikerer at et mål er friskt. Standardverdien er 200, men De kan konfigurere områder som 200-299 eller kommaseparerte verdier som 200,301,302.

Beste praksis er å opprette et eget /health-endepunkt i applikasjonen som bare returnerer 200 når alle kritiske avhengigheter er tilgjengelige (databasetilkobling, hurtigbuffer og nedstrømstjeneste). Ikke bruk rot-URL-en (/) som bane for helsesjekken hvis den utfører kostbare operasjoner eller krever autentisering.

Et mål går gjennom disse tilstandene etter registrering:

• initial: ELB utfører de første helsesjekkene
• healthy: har bestått det påkrevde antallet sammenhengende helsesjekker og mottar trafikk
• unhealthy: har ikke bestått det påkrevde antallet sammenhengende helsesjekker og er fjernet fra rotasjonen
• draining: avregistrering pågår; eksisterende tilkoblinger får fullføre, men ingen nye tilkoblinger sendes
• unused: er registrert i gruppen, men ingen lytterregel ruter for øyeblikket til denne gruppen

Overvåk CloudWatch-metrikkene UnHealthyHostCount og HealthyHostCount for å oppdage problemer med målparken.

Forsinkelse ved avregistrering (tidligere kalt connection draining) er tiden ELB venter på at eksisterende tilkoblinger skal fullføres før et mål endelig avregistreres. Standardverdien er 300 sekunder (5 minutter). I denne perioden sendes ingen nye forespørsler til målet som avregistreres, men forespørsler som allerede er under behandling, får fullføre.

Ved raske utrullinger og termineringer på grunn av automatisk skalering kan De vurdere å redusere dette til 30–60 sekunder hvis applikasjonen behandler forespørsler raskt. For langvarige operasjoner (filopplastinger og videobehandling) bør De beholde en tilstrekkelig lang forsinkelse til at operasjonene kan fullføres uten avbrudd.

Målgrupper støtter ulike lastbalanseringsalgoritmer:

• Round robin (standard for ALB): forespørsler fordeles jevnt etter tur – best når alle mål er likeverdige
• Least outstanding requests (ALB): hver ny forespørsel sendes til målet med færrest forespørsler under behandling – bedre for arbeidsbelastninger med varierende lengde, der noen forespørsler tar lengre tid enn andre
• Flow hash (NLB): fordeler basert på protokoll, kilde-/destinasjons-IP, kilde-/destinasjonsport og TCP-sekvensnummer – sikrer at alle pakker i en TCP-/UDP-flyt går til samme mål

For øktbaserte applikasjoner der alle forespørsler fra en bruker må nå samme mål, bør De aktivere sticky sessions i stedet for å stole på round-robin-fordeling.

Én ALB-lytterregel kan fordele trafikk på tvers av flere målgrupper med vektede målgrupper. De kan for eksempel rute 90 % av trafikken til en stabil målgruppe og 10 % til en canary-målgruppe ved blågrønne utrullinger – uten å bruke vektet ruting i Route 53.

Vektede målgrupper konfigureres på lytterregel-nivå. Vektene er relative: 90/10 sender 90 % til den første gruppen og 10 % til den andre. Dette skiller seg fra vektet ruting på tvers av flere ALB-er; her skjer fordelingen innenfor én ALB-lytterregel.

Når De distribuerer ECS-tjenester bak en ALB, registreres hver ECS-oppgave i ALB-målgruppen ved hjelp av ip target type (for nettverksmodusen awsvpc). ECS-tjenesten håndterer registrering og avregistrering automatisk: nye oppgaver registreres etter at de har bestått helsesjekkene, og oppgaver som stoppes, utløser en forsinkelse ved avregistrering før terminering.

Hver ECS-tjeneste kan registreres med en bestemt portoverstyring. Dermed kan flere ECS-tjenester dele én ALB via ulike lytterregler (bane- eller vertsbaserte) med ulike målgrupper – et vanlig mikrotjenestemønster.

Helsesjekkatferden til NLB skiller seg fra ALB:

• NLB støtter helsesjekkprotokollene TCP, HTTP og HTTPS, uavhengig av lytterprotokollen
• NLB-helsesjekker sendes fra NLB-ens IP-adresser i hver AZ – sørg for at sikkerhetsgruppene tillater trafikk fra IP-adressene til NLB-ens delnett, eller bruk sikkerhetsgruppen til selve NLB-en
• For TCP-helsesjekker anser NLB et mål som friskt hvis det godtar en TCP-tilkobling på den angitte porten
• NLB-mål som ikke består helsesjekkene, fjernes per AZ – hvis alle mål i en AZ er usunne, kan NLB utføre lastbalansering på tvers av soner mot friske mål i andre AZ-er (hvis lastbalansering på tvers av soner er aktivert)

I denne leksjonen har De lært at målgrupper inneholder friske, registrerte mål av typen instans, IP eller Lambda, at helsesjekker undersøker mål med jevne mellomrom for å fjerne usunne mål fra rotasjonen, og at forsinkelse ved avregistrering sørger for kontrollert tømming av forespørsler som er under behandling, før målet fjernes. Neste gang skal vi se nærmere på lytterregler og bane- basert ruting på ALB.