Riktig dimensjonering og automatisk skalering

Riktig dimensjonering er prosessen med å tilpasse Azure-VM-er eller tjeneste-SKU-er til de faktiske ressurskravene for arbeidsbelastningen Deres, uten overdimensjonering (som sløser med penger) eller underdimensjonering (som kan gi dårligere ytelse). De fleste organisasjoner overdimensjonerer først med 30–50 % av forsiktighet når de migrerer fra lokale miljøer. Regelmessig analyse av riktig dimensjonering, vanligvis månedlig, kan hente inn en betydelig del av overforbruket uten å påvirke programytelsen.

Bruk Azure Monitor-måledata og VM Insights til å samle inn data om CPU, minne, disk-IOPS og nettverksgjennomstrømming over minst 30 dager. Se etter toppverdien (P95 eller P99) for utnyttelsen, ikke gjennomsnittet, for å sikre at den riktig dimensjonerte VM-en kan håndtere trafikktopper. Azure Advisors anbefaling om riktig dimensjonering bruker som standard data fra de siste 7 dagene, men De kan utvide dette til 30 eller 60 dager i Advisor-konfigurasjonen for å få mer representative data.

Azure-VM-er er organisert i SKU-familier som er optimalisert for ulike arbeidsbelastninger: D-series (generelle formål), E-series (minneoptimalisert), F-series (databehandlingsoptimalisert), N-series (GPU) og L-series (lagringsoptimalisert). Hvis CPU-bruken på en VM er lav, men minnebruken er høy, gir flytting fra D-serien til E-serien med samme antall vCPU-er mer RAM til en tilsvarende kostnad. Endring av størrelsen på en VM i Azure krever vanligvis en kort omstart på noen minutter.

Planlagt automatisk skalering er det riktige valget når arbeidsbelastningsmønstrene er forutsigbare. Et detaljhandelsprogram med høy trafikk i arbeidstiden og nesten ingen trafikk om natten kan konfigureres med en tidsplan for oppskalering kl. 07.00 og en tidsplan for nedskalering kl. 22.00. Virtual Machine Scale Sets (VMSS) og App Service støtter begge regler for planlagt automatisk skalering. Denne tilnærmingen er enklere og gir mer forutsigbare kostnader enn metrikkbasert automatisk skalering for kjente belastningsmønstre.

Metrikkbasert automatisk skalering legger til eller fjerner instanser dynamisk som svar på sanntidsmålinger, for eksempel CPU-prosent, lengden på køen av HTTP-forespørsler eller egendefinerte måledata som publiseres via Azure Monitor. De definerer regler for oppskalering (når instanser skal legges til) og regler for nedskalering (når instanser skal fjernes), med nedkjølingsperioder for å hindre raske svingninger. Det anbefales å sette terskelen for oppskalering lavere enn terskelen for nedskalering, for eksempel oppskalering ved over 70 % CPU og nedskalering ved under 30 % CPU, med en nedkjølingsperiode på 5 minutter.

Azure Spot VMs lar deg bruke ubrukt Azure-kapasitet med rabatter på opptil 90 % sammenlignet med priser etter forbruk. Ulempen er at Azure kan avslutte Spot-VM-er med 30 sekunders varsel når kapasiteten må tas tilbake. Dette gjør Spot-instanser ideelle for avbrytbare batchjobber, for eksempel gjengivelse, vitenskapelige beregninger og dataprosesseringspipelines. VMSS støtter en blanding av vanlige VM-er (for en grunnkapasitet) og Spot-VM-er (for ekstra kapasitet) i samme skaleringssett ved hjelp av en policy for prioriteringsblanding.

Azure App Service-autoskalering fungerer på nivået App Service Plan – antallet worker-instanser økes eller reduseres basert på regler du konfigurerer. Tilgjengelige metrikkutløsere omfatter lengden på HTTP-køen, CPU-prosent og minneprosent. Standard-nivået og høyere støtter manuell skalering og autoskalering, mens Basic-nivået bare støtter manuell skalering. For serverløse arbeidsbelastninger kan du vurdere Azure Functions on the Consumption Plan, som skalerer ned til null og bare belaster per kjøring, slik at kostnader for inaktive instanser elimineres helt.

Vanlige fallgruver ved autoskalering: sesjonsaffinitet – hvis appen lagrer sesjonstilstand i VM-minnet, går sesjonene tapt når du skalerer inn. Bruk i stedet Redis Cache eller sesjoner som er lagret i en database. Langsom oppstart – hvis VM-er eller containere bruker 10 minutter på å bli klare, kan ikke metrikkbasert autoskalering reagere raskt nok. Forvarm dem med planlagt utskalering før forventede toppbelastninger. For aggressiv innskalering – hvis instanser avsluttes mens forespørsler fortsatt behandles, oppstår det feil. Konfigurer connection draining og en romslig nedkjølingsperiode.

Riktig dimensjonering gjelder også PaaS-tjenester. Azure SQL Database med DTU-modellen kan dimensjoneres ned hvis DTU-prosenten konsekvent er under 50 %. vCore-modellen gjør det mulig å skalere CPU og lagring uavhengig av hverandre. Azure Cache for Redis kan nedgraderes fra Premium- til Standard-nivå hvis persistens og georeplikering ikke er nødvendig. Nodeutvalg i Azure Kubernetes Service kan bruke Cluster Autoscaler til å skalere antallet noder inn og ut basert på om pods venter eller er inaktive.

Riktig dimensjonering er ikke en engangsaktivitet. Arbeidsbelastninger endrer seg over tid – trafikkmønstre skifter, funksjoner legges til, og brukerbaser vokser eller krymper. Inkluder en månedlig gjennomgang av riktig dimensjonering i FinOps-prosessen: hent anbefalinger fra Advisor, gå gjennom de 10 mest underutnyttede VM-ene og de mest overdimensjonerte PaaS-tjenestene, og opprett arbeidsoppgaver for de ansvarlige teamene. Følg med på realiserte besparelser sammenlignet med antallet genererte anbefalinger for å synliggjøre FinOps-avkastningen for ledelsen.

Den optimale kostnadsstrategien er å dimensjonere riktig først og deretter reservere. Hvis du kjøper en Reserved VM Instance for en overdimensjonert VM, binder du deg til feil SKU. Dimensjoner først VM-en til riktig størrelse, følg deretter den nye utnyttelsen i 30 dager for å bekrefte at den er stabil, og kjøp så en reservasjon for den riktig dimensjonerte SKU-en. Denne totrinnstilnærmingen maksimerer rabatten og unngår samtidig bortkastet reservert kapasitet.

I denne leksjonen lærte du at riktig dimensjonering tilpasser VM-SKU-er til de faktiske kravene i arbeidsbelastningen ved hjelp av ytelsesmålinger, at planlagt og metrikkbasert autoskalering justerer kapasiteten dynamisk etter behov, og at Spot-VM-er gir rabatter på opptil 90 % for avbrytbare batchjobber. Neste gang ser vi på Azure Savings Plans og reservasjoner for arbeidsbelastninger med forpliktet kapasitet.