Juiste dimensionering en automatisch schalen

De juiste grootte bepalen is het afstemmen van Azure-VM- of service-SKU's op de werkelijke resourcevereisten van uw werklast — zonder te ruime inrichting (geldverspilling) en zonder te krappe inrichting (risico op slechtere prestaties). De meeste organisaties richten aanvankelijk 30–50% te ruim in uit voorzichtigheid bij de migratie vanuit hun eigen datacenter. Met een regelmatige analyse, meestal maandelijks, kunt u een aanzienlijk deel van deze overbesteding terugwinnen zonder de prestaties van toepassingen te beïnvloeden.

Gebruik metrische gegevens van Azure Monitor en VM Insights om gedurende ten minste 30 dagen gegevens te verzamelen over CPU, geheugen, schijf-IOPS en netwerkdoorvoer. Kijk naar het piekgebruik (P95 of P99), niet naar het gemiddelde, zodat de VM met de juiste grootte verkeerspieken aankan. De aanbeveling voor het bepalen van de juiste grootte in Azure Advisor gebruikt standaard een terugblikperiode van 7 dagen, maar u kunt deze in de Advisor-configuratie uitbreiden naar 30 of 60 dagen voor representatievere gegevens.

Azure-VM's zijn georganiseerd in SKU-families die zijn geoptimaliseerd voor verschillende werklasten: D-series (algemeen gebruik), E-series (geoptimaliseerd voor geheugen), F-series (geoptimaliseerd voor rekenkracht), N-series (GPU) en L-series (geoptimaliseerd voor opslag). Als een VM weinig CPU gebruikt maar veel geheugen, levert de overstap van een D-series- naar een E-series-VM met hetzelfde aantal vCPU's meer RAM tegen vergelijkbare kosten. Het wijzigen van de grootte van een VM in Azure vereist doorgaans een korte herstart van enkele minuten.

Gepland automatisch schalen is de juiste keuze wanneer patronen in de werklast voorspelbaar zijn. Een winkeltoepassing met veel verkeer tijdens kantooruren en vrijwel geen verkeer 's nachts kan worden geconfigureerd met een schema voor opschalen om 07.00 uur en een schema voor afschalen om 22.00 uur. Zowel Virtual Machine Scale Sets (VMSS) als App Service ondersteunen geplande regels voor automatisch schalen. Voor bekende laadpatronen is deze aanpak eenvoudiger en zijn de kosten beter voorspelbaar dan bij automatisch schalen op basis van metrische gegevens.

Automatisch schalen op basis van metrische gegevens voegt exemplaren dynamisch toe of verwijdert ze als reactie op realtimegegevens, zoals het CPU-percentage, de lengte van de wachtrij voor HTTP-aanvragen of aangepaste metrische gegevens die via Azure Monitor worden gepubliceerd. U definieert regels voor opschalen (wanneer exemplaren moeten worden toegevoegd) en regels voor afschalen (wanneer exemplaren moeten worden verwijderd), met afkoelperioden om snel heen-en-weer schakelen te voorkomen. Een aanbevolen werkwijze is om de drempel voor opschalen lager in te stellen dan die voor afschalen — bijvoorbeeld opschalen bij meer dan 70% CPU en afschalen bij minder dan 30% CPU — met een afkoelperiode van 5 minuten.

Azure Spot-VM's geven je de mogelijkheid om ongebruikte Azure-capaciteit te gebruiken met kortingen tot 90% ten opzichte van pay-as-you-go-prijzen. De keerzijde is dat Azure Spot-VM's met een waarschuwing van 30 seconden kan verwijderen wanneer de capaciteit weer nodig is. Daardoor zijn Spot-instanties ideaal voor onderbreekbare batchworkloads, zoals rendering, wetenschappelijke berekeningen en pijplijnen voor gegevensverwerking. Met VMSS kun je reguliere VM's (voor een basisniveau) combineren met Spot-VM's (voor piekcapaciteit) in dezelfde schaalset, met behulp van een beleid voor prioriteitsverdeling.

Automatisch schalen van Azure App Service werkt op het niveau van het App Service-plan: er worden worker-instanties toegevoegd of verwijderd op basis van regels die je configureert. Beschikbare metriektriggers zijn onder andere de lengte van de HTTP-wachtrij, het CPU-percentage en het geheugenpercentage. De laag Standard en hoger ondersteunt handmatig schalen en automatisch schalen; de laag Basic ondersteunt alleen handmatig schalen. Overweeg voor serverloze workloads Azure Functions in het Consumption-plan. Dit schaalt naar nul en brengt alleen kosten per uitvoering in rekening, waardoor kosten voor niet-gebruikte instanties volledig worden geëlimineerd.

Veelvoorkomende valkuilen bij automatisch schalen zijn: sessieaffiniteit — als je app sessiestatus opslaat in het geheugen van een VM, gaan sessies verloren wanneer er wordt afgeschaald; gebruik in plaats daarvan Redis Cache of sessies die door een database worden ondersteund. Lange opstarttijden — als VM's of containers 10 minuten nodig hebben om op te warmen, kan automatisch schalen op basis van metriek niet snel genoeg reageren; warm ze vooraf op door vóór verwachte pieken volgens een schema op te schalen. Te agressief afschalen — het beëindigen van instanties terwijl aanvragen nog worden verwerkt, veroorzaakt fouten; configureer het gecontroleerd afbouwen van verbindingen en een ruime afkoelperiode.

Juiste dimensionering is ook van toepassing op PaaS-services. Azure SQL Database volgens het DTU-model kan kleiner worden gedimensioneerd als het DTU-percentage voortdurend lager is dan 50%. Met het vCore-model kun je CPU en opslag onafhankelijk schalen. Azure Cache for Redis kan van de laag Premium naar Standard worden verkleind als persistentie en geografische replicatie niet nodig zijn. Knooppuntgroepen van Azure Kubernetes Service kunnen de Cluster Autoscaler gebruiken om knooppunten in en uit te schalen op basis van pods die in behandeling zijn en inactieve pods.

Juiste dimensionering is geen eenmalige activiteit. Workloads veranderen in de loop van de tijd: verkeerspatronen verschuiven, functies worden toegevoegd en gebruikersgroepen groeien of krimpen. Neem een maandelijkse beoordeling van de dimensionering op in je FinOps-proces: haal aanbevelingen uit Advisor op, beoordeel de 10 meest onderbenutte VM's en overgedimensioneerde PaaS-services en maak werkitems voor de verantwoordelijke teams. Houd de gerealiseerde besparingen bij ten opzichte van de gegenereerde aanbevelingen om het rendement op FinOps voor het management aan te tonen.

De optimale kostenstrategie is: eerst juist dimensioneren en daarna reserveren. Als je een Reserved VM Instance aanschaft voor een overgedimensioneerde VM, leg je een verplichting vast voor de verkeerde SKU. Dimensioneer de VM eerst naar de juiste grootte, observeer vervolgens 30 dagen lang het nieuwe gebruik om de stabiliteit te bevestigen en schaf daarna een reservering aan voor die SKU met de juiste dimensionering. Deze aanpak in twee stappen maximaliseert de korting en voorkomt verspilde gereserveerde capaciteit.

In deze les heb je geleerd dat juiste dimensionering VM-SKU's afstemt op de werkelijke vereisten van workloads met behulp van prestatiemetrieken, dat automatisch schalen volgens een schema en op basis van metriek de capaciteit dynamisch aanpast aan de vraag en dat Spot-VM's kortingen tot 90% bieden voor onderbreekbare batchworkloads. Hierna bekijken we Azure Savings Plans en reserveringen voor workloads waarvoor je een verbintenis aangaat.