Planlagt og forudsigende skalering

Dynamiske skaleringspolitikker (target tracking og step scaling) er reaktive — de reagerer, efter at en måling allerede har overskredet en tærskel. Ved kendte og forudsigelige trafikmønstre som spidsbelastning i arbejdstiden, batchkørsler ved månedens udgang eller Black Friday-udsalg er reaktiv skalering for langsom, fordi det tager flere minutter at starte og varme instanser op. Scheduled Scaling og Predictive Scaling løser dette ved proaktivt at justere kapaciteten, før belastningen ankommer.

En Scheduled Scaling Action ændrer ASG's minimums-, maksimums- eller ønskede kapacitet på en bestemt dato og et bestemt tidspunkt eller efter en tilbagevendende cron-plan. Det er ideelt, når du ved præcis, hvornår belastningen stiger — for eksempel til forvarmning før en planlagt marketingbegivenhed eller til nedskalering om natten, når trafikken er minimal, for at spare omkostninger. Planlagte handlinger tilsidesætter den aktuelle ønskede kapacitet på det angivne tidspunkt.

Planlagte handlinger bruger Unix-cronformat: minute hour day-of-month month day-of-week. Alle tidspunkter er angivet i UTC. Almindelige mønstre omfatter 0 8 * * 1-5 (hverdagsmorgener kl. 08:00 UTC) til opskalering og 0 20 * * * (hver aften kl. 20:00 UTC) til nedskalering. Du kan oprette flere planlagte handlinger på den samme ASG, f.eks. én til at skalere op og én til at skalere ned igen hver dag.

Planlagte handlinger kan være engangshandlinger (udføres én gang på et bestemt starttidspunkt) eller gentagne (udføres efter en cron-plan). En engangshandling er perfekt til en kendt fremtidig begivenhed som en produktlancering. En gentagen handling håndterer regelmæssige mønstre som daglige eller ugentlige trafikcyklusser. Du kan også angive et starttidspunkt og et sluttidspunkt for en gentagen handling, så en plan automatisk aktiveres og deaktiveres inden for et bestemt datointerval.

Planlagte handlinger og dynamiske skaleringspolitikker kan fungere side om side. En planlagt handling angiver en ny grundkapacitet på det planlagte tidspunkt. Derefter fortsætter dynamiske politikker (målsøgning eller trinvis skalering) med at justere kapaciteten inden for de opdaterede minimums- og maksimumsgrænser. Eksempel: En planlagt morgenhandling angiver min=4, desired=8; i løbet af dagen skalerer målsøgning op til 15 under belastning; den planlagte aftenhandling nulstiller derefter til min=2, desired=2.

Forudsigende skalering bruger maskinlæring til at analysere historiske belastningsmønstre fra CloudWatch-metrikker og forudsige fremtidige kapacitetsbehov. Den planlægger proaktivt opskaleringshandlinger før den forudsagte belastning opstår – typisk 5-60 minutter i forvejen. Forudsigende skalering er bedst til arbejdsbelastninger med gentagne daglige eller ugentlige trafikcyklusser. Prognosen opdateres løbende, efterhånden som der indsamles flere data.

Du aktiverer forudsigende skalering ved at knytte en PredictiveScaling-politik til din ASG. Du angiver et metriksæt: et belastningsmetriks (det, der driver skaleringen, f.eks. CPU eller antal ALB-anmodninger) og et skaleringsmetriks (det, du overvåger på hver instans). AWS forudsiger derefter belastningsmetrikket og beregner det nødvendige antal instanser for at holde skaleringsmetrikket på din mål-værdi.

Predictive Scaling har to tilstande: ForecastOnly genererer prognoser uden faktisk at ændre kapaciteten – nyttigt til at gennemgå forudsigelser, før du aktiverer automatisk skalering. ForecastAndScale genererer både prognoser og anvender automatisk kapacitetsændringer. Start med ForecastOnly i nogle uger for at validere nøjagtigheden, og skift derefter til ForecastAndScale. AWS kræver mindst 24 timers metriksdata, før den første prognose genereres.

Forudsigende skalering udløser opskaleringshandlinger på forhånd, men du kan konfigurere en SchedulingBufferTime for at forvarme instanser endnu tidligere. En SchedulingBufferTime på 5 minutter betyder, at kapacitet tilføjes 5 minutter før prognosen forudsiger, at der bliver brug for den. Du kan også angive en MaxCapacityBuffer, så ASG kan skalere ud over det forventede behov med en procentdel og dermed skabe en kapacitetsreserve mod unøjagtige prognoser.

Det anbefalede mønster for variable, men forudsigelige arbejdsbelastninger er at kombinere begge dele: forudsigende skalering håndterer den forventede cykliske belastning ved at placere kapacitet på forhånd, mens målsøgningsbaseret skalering håndterer uventede spidsbelastninger, der overstiger prognosen. Tilsammen giver de både proaktiv og reaktiv dækning. ASG anvender sikkert den mest forsigtige anbefaling til opskalering på tværs af begge politikker.

Brug planlagt skalering, når trafikspidser er fuldt forudsigelige, og du kender de nøjagtige tidspunkter (hændelsesdrevne mønstre eller mønstre efter arbejdstid). Brug forudsigende skalering, når mønstre gentager sig, men det nøjagtige tidspunkt kan variere – maskinlæring lærer automatisk mønstret. Brug målsøgning som et dynamisk sikkerhedsnet, der altid er aktivt, til uventet belastning. Ved helt tilfældig belastning kan du nøjes med målsøgning eller trinvis skalering. Eksamen SAA-C03 beder ofte om, at du vælger den mest driftseffektive tilgang, og forudsigende skalering er det bedste valg til tilbagevendende cykliske arbejdsbelastninger.

I denne lektion lærte du, at planlagt skalering bruger cron-udtryk til at ændre ASG-kapaciteten på kendte tidspunkter, hvilket er ideelt til forudsigelige begivenheder eller tilbagevendende mønstre efter arbejdstid, at forudsigende skalering bruger maskinlæring på historiske CloudWatch-data til proaktivt at skalere, før belastningen opstår, og at en kombination af forudsigende skalering + målsøgning giver både proaktiv og reaktiv dækning og dermed den mest robuste skaleringsstrategi. Næste gang ser vi på Instance Refresh og Lifecycle Hooks til kontrollerede udrulninger.