Dimensionamento corretto e autoscaling

Il ridimensionamento appropriato è il processo di adeguamento degli SKU delle VM o dei servizi Azure ai requisiti effettivi del carico di lavoro, evitando sia il sovradimensionamento (che comporta uno spreco di denaro) sia il sottodimensionamento (che rischia di compromettere le prestazioni). Durante la migrazione dall'ambiente locale, la maggior parte delle organizzazioni inizialmente sovradimensiona le risorse del 30–50% per prudenza. Un'analisi periodica del ridimensionamento appropriato, in genere mensile, può recuperare una parte significativa della spesa eccessiva senza compromettere le prestazioni dell'applicazione.

Utilizzi le metriche di Azure Monitor e VM Insights per raccogliere dati relativi a CPU, memoria, IOPS del disco e velocità effettiva della rete per almeno 30 giorni. Esamini l'utilizzo di picco (P95 o P99), non la media, per assicurarsi che la VM ridimensionata correttamente sia in grado di gestire i picchi di traffico. Per impostazione predefinita, la raccomandazione di Advisor sul ridimensionamento appropriato utilizza un periodo di osservazione di 7 giorni, ma può estenderlo a 30 o 60 giorni nella configurazione di Advisor per ottenere dati più rappresentativi.

Le VM Azure sono organizzate in famiglie di SKU ottimizzate per diversi carichi di lavoro: D-series (scopo generale), E-series (ottimizzate per la memoria), F-series (ottimizzate per il calcolo), N-series (GPU) e L-series (ottimizzate per l'archiviazione). Se l'utilizzo della CPU di una VM è basso, ma quello della memoria è elevato, passando da una D-series a una E-series con lo stesso numero di vCPU si ottiene più RAM a un costo simile. Il ridimensionamento di una VM in Azure richiede in genere un breve riavvio di alcuni minuti.

L'autoscaling pianificato è la scelta giusta quando i modelli di carico di lavoro sono prevedibili. Un'applicazione di vendita al dettaglio che registra traffico elevato durante l'orario lavorativo e traffico quasi nullo durante la notte può essere configurata con una pianificazione di scale-out alle 07:00 e una di scale-in alle 22:00. Sia Virtual Machine Scale Sets (VMSS) sia App Service supportano regole di autoscaling pianificate. Questo approccio è più semplice e offre costi più prevedibili rispetto all'autoscaling basato sulle metriche per modelli di carico noti.

L'autoscaling basato sulle metriche aggiunge o rimuove dinamicamente le istanze in risposta a metriche in tempo reale, come la percentuale di CPU, la lunghezza della coda delle richieste HTTP o metriche personalizzate pubblicate tramite Azure Monitor. Definisca regole di scale-out (quando aggiungere istanze) e regole di scale-in (quando rimuovere istanze), con periodi di cooldown per evitare variazioni troppo frequenti. La procedura consigliata consiste nell'impostare una soglia di scale-out inferiore a quella di scale-in, ad esempio eseguendo lo scale-out con CPU >70% e lo scale-in con CPU <30%, con un cooldown di 5 minuti.

Le Azure Spot VMs consentono di usare la capacità Azure inutilizzata con sconti fino al 90% rispetto ai prezzi con pagamento a consumo. Il compromesso è che Azure può evict le spot VM con un preavviso di 30 secondi quando ha bisogno di recuperare la capacità. Questo rende le istanze Spot ideali per carichi di lavoro batch interrompibili, come il rendering, il calcolo scientifico e le pipeline di elaborazione dati. VMSS supporta la combinazione di VM regolari (per la capacità di base) e spot VM (per la capacità aggiuntiva) nello stesso set di scalabilità, usando un criterio di combinazione delle priorità.

L'autoscaling di Azure App Service funziona a livello di App Service Plan: aggiunge o rimuove istanze worker in base alle regole configurate. Tra i trigger basati sulle metriche disponibili ci sono la lunghezza della coda HTTP, la percentuale di CPU e la percentuale di memoria. Il livello Standard e quelli superiori supportano la scalabilità manuale e l'autoscaling; il livello Basic supporta solo la scalabilità manuale. Per i carichi di lavoro serverless, consideri l'utilizzo di Azure Functions on the Consumption Plan, che scala fino a zero e addebita i costi solo per esecuzione, eliminando completamente il costo delle istanze inattive.

Problemi comuni dell'autoscaling: affinità di sessione: se l'applicazione memorizza lo stato della sessione nella memoria della VM, la riduzione della scalabilità causerà la perdita delle sessioni; usi invece Redis Cache o sessioni basate su database. Tempi di avvio lunghi: se le VM o i container impiegano 10 minuti per essere pronti, l'autoscaling basato sulle metriche non può rispondere abbastanza rapidamente; esegua il pre-riscaldamento aumentando la scalabilità in base a una pianificazione prima dei picchi previsti. Riduzione della scalabilità troppo aggressiva: terminare le istanze mentre stanno elaborando richieste in corso causa errori; configuri il connection draining e un periodo di cooldown adeguato.

Il dimensionamento corretto si applica anche ai servizi PaaS. Azure SQL Database basato sul modello DTU può essere ridimensionato se la percentuale di DTU rimane costantemente sotto il 50%. Il vCore model consente di ridimensionare separatamente CPU e spazio di archiviazione. Azure Cache for Redis può essere ridotto dal livello Premium al livello Standard se non sono necessarie la persistenza e la replica geografica. I pool di nodi di Azure Kubernetes Service possono usare Cluster Autoscaler per aumentare o ridurre il numero di nodi in base allo stato di attesa e di inattività dei pod.

Il dimensionamento corretto non è un'attività da svolgere una sola volta. I carichi di lavoro cambiano nel tempo: cambiano i modelli di traffico, vengono aggiunte funzionalità e la base utenti cresce o si riduce. Inserisca una revisione mensile del dimensionamento nel processo FinOps: recuperi le raccomandazioni di Advisor, esamini le 10 VM meno utilizzate e i servizi PaaS sovradimensionati, quindi crei attività per i team responsabili. Tenga traccia dei risparmi realizzati rispetto alle raccomandazioni generate, per dimostrare il ROI di FinOps alla direzione.

La strategia ottimale per i costi consiste nel dimensionare correttamente prima e prenotare dopo. Acquistare una Reserved VM Instance per una VM sovradimensionata vincola a uno SKU errato. Ridimensioni prima la VM alla dimensione corretta, osservi la nuova utilizzazione per 30 giorni per confermarne la stabilità, quindi acquisti una prenotazione per quello SKU dimensionato correttamente. Questo approccio in due passaggi massimizza lo sconto evitando capacità prenotata inutilizzata.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che il dimensionamento corretto associa gli SKU delle VM ai requisiti effettivi del carico di lavoro usando le metriche delle prestazioni, che l'autoscaling pianificato e basato sulle metriche adatta dinamicamente la capacità alla domanda e che le Spot VM offrono sconti fino al 90% per i carichi di lavoro batch interrompibili. Nella prossima lezione esamineremo Azure Savings Plans e le prenotazioni per i carichi di lavoro soggetti a impegno.