Automatisk skalering og lastbalansering av ECS-tjenester

Et fast ønsket antall for en ECS-tjeneste kan ikke håndtere trafikkvariasjoner – enten overdimensjonerer De (og kaster bort penger) eller underdimensjonerer De (og svekker ytelsen). ECS Service Auto Scaling justerer automatisk ønsket antall tasker som svar på CloudWatch-målinger. Tjenesten bruker Application Auto Scaling i bakgrunnen – det samme rammeverket som brukes av DynamoDB, Aurora og ElastiCache. Automatisk skalering av ECS-tjenester støtter policyer for målsporing, trinnvis skalering og planlagt skalering.

Før De legger til skaleringspolicyer, må De registrere ECS-tjenesten som et skalerbart mål i Application Auto Scaling. Angi minimums- og maksimumsantall tasker, klyngenavnet og tjenestenavnet som ressurs-ID. Dette oppretter grensene som den automatiske skaleringen skal operere innenfor. Minimumsantallet sikrer at De alltid har en grunnkapasitet, mens maksimumsantallet hindrer ukontrollert skalering som kan tømme kapasiteten i Fargate eller EC2-instanser.

Target Tracking er den anbefalte policyen for automatisk skalering for de fleste ECS-tjenester. Den vanligste målverdien er ECSServiceAverageCPUUtilization – angi et mål på 50–70 %, så legger ECS til eller fjerner tasker for å opprettholde dette CPU-nivået. En annen nyttig måling er ALBRequestCountPerTarget: Følg med på antallet ALB-forespørsler per task, og skaler for å opprettholde en målverdi for forespørselsraten per instans. AWS håndterer automatisk både oppskalering og nedskalering, med passende nedkjølingsperioder.

Ved å koble en Application Load Balancer (ALB) til en ECS-tjeneste fordeles HTTP/HTTPS-trafikk på alle taskene som kjører. ALB-målgruppen registrerer IP-adressen til hver task (for Fargate/awsvpc) eller containerporten (for bridge-modus). ECS registrerer automatisk nye tasker i målgruppen når de starter, og avregistrerer dem når de stopper. ALB utfører helsesjekker av hver task. Tasker som ikke er friske, tømmes (tilkoblinger lukkes på en kontrollert måte) før tjenesten avslutter dem.

Et effektivt mønster er å rute ulike URL-stier til forskjellige ECS-tjenester ved hjelp av ALB path-based routing. Én ALB med én HTTPS-lytter kan rute: /api/orders/* til Orders ECS-tjenesten, /api/users/* til Users ECS-tjenesten og /api/products/* til Products ECS-tjenesten – hver med sin egen ECS-tjeneste og uavhengige skalering. Dette eliminerer behovet for separate lastbalanserere for hver mikrotjeneste, reduserer kostnadene og forenkler DNS-administrasjonen.

Når en ECS-task skal avsluttes (under nedskalering eller en utrulling), markerer ALB den som draining og slutter å rute nye forespørsler til den, samtidig som pågående forespørsler får fullføres. deregistration delay (standardverdien er 300 sekunder, og den kan konfigureres til 0–3600 sekunder) angir hvor lenge ALB venter før tilkoblinger lukkes med tvang. For ECS med korte forespørsler bør De angi en lavere avregistreringsforsinkelse (30–60 sekunder) for å fremskynde utrullinger og nedskalering. For lange tilkoblinger (WebSocket, filopplastinger) bør De beholde en høyere forsinkelse.

I tillegg til CPU og minne kan De publisere egendefinerte CloudWatch-målinger fra applikasjonen (kødybde, aktive økter, forretnings-KPI-er) og bruke dem som grunnlag for skalering. Hvis hver ECS-task for eksempel kan håndtere 50 kømeldinger samtidig, kan De publisere dybden i SQS-køen som en egendefinert måling og opprette en målsporingspolicy med et mål på 50 meldinger per task. Dette gir en direkte, forretningslogikkstyrt skalering i stedet for å basere seg på infrastrukturmålinger som kanskje ikke samsvarer med belastningen på applikasjonen.

I likhet med EC2 Auto Scaling støtter ECS task scale-in protection. En task som kjører, kan angi sitt eget flagg for beskyttelse mot nedskalering via ECS API-et for å hindre at den avsluttes under nedskalering mens den behandler en kritisk jobb. Dette er nyttig for ECS-tasker som fungerer som SQS-arbeidere – en arbeider som nettopp har hentet en langvarig jobb fra køen, kan beskytte seg selv, fullføre jobben og deretter fjerne beskyttelsen. Uten dette kan nedskalering avslutte en task midt i behandlingen, noe som kan føre til at jobben utføres flere ganger eller at data går tapt.

Velg skaleringsmålingen med omhu. CPU-utilisering er standardvalget og fungerer godt for CPU-intensive arbeidsbelastninger. Minneutilisering (ECSServiceAverageMemoryUtilization) er nyttig for minneintensive applikasjoner, men økt minnekapasitet krever at De legger til tasker. Hvis tasken er begrenset av minne per task og ikke av samtidig behandling, kan det være bedre å korrigere minnetildelingen i taskdefinisjonen. ALBRequestCountPerTarget samsvarer direkte med brukeropplevelsen og er den mest handlingsrettede målingen for web-API-er – skaler basert på den faktiske forespørselsraten per task.

ECS Deployment Circuit Breaker oppdager automatisk mislykkede utrullinger og ruller tilbake til den siste stabile versjonen. Uten denne funksjonen ville en feilaktig utrulling (for eksempel en container som ikke består helsesjekker) føre til at ECS fortsetter å forsøke å starte nye tasker på ubestemt tid. Når kretsbryteren er aktivert, og en bestemt andel av de nylig startede taskene ikke består helsesjekkene innenfor et deteksjonsvindu, markerer ECS utrullingen som FAILED og ruller automatisk tilbake til den forrige revisjonen av taskdefinisjonen. Dette hindrer at feilaktige utrullinger fører til langvarig svekket tjenestekvalitet.

En produksjonsklar arkitektur for en containerisert web-API: Route 53 løser domenet til et ALB-DNS-navn. ALB avslutter HTTPS (ACM-sertifikat), bruker WAF-regler og ruter forespørsler til en ECS service target group. Fargate-tasker i private subnett på tvers av tre AZ-er håndterer forespørslene. ECS Service Auto Scaling med målsporing på ALBRequestCountPerTarget justerer antallet tasker fra 2 til 50. Taskene kobler til RDS Aurora og ElastiCache i private subnett. Alle logger sendes til CloudWatch Logs, mens målinger brukes i CloudWatch-dashbord og alarmer.

I denne leksjonen har De lært at ECS Service Auto Scaling bruker Application Auto Scaling med målsporing (CPU, ALB-forespørsler eller egendefinerte målinger) for å justere antallet tasker mellom konfigurerte minimums- og maksimumsgrenser, at ALB path-based routing gjør det mulig for én lastbalanserer å betjene flere ECS-mikrotjenester ved å rute URL-stier til ulike målgrupper, og at Deployment Circuit Breaker automatisk ruller tilbake mislykkede utrullinger før de fører til langvarig svekket tjenestekvalitet. Dette avslutter modulen om ECS og containere. Deretter utforsker vi Amazon EKS for Kubernetes på AWS.