Policy di scaling: target tracking e step scaling

Una capacità desiderata statica funziona quando il carico è costante, ma il traffico reale varia. Le policy di scaling consentono a un Auto Scaling Group di modificare automaticamente la capacità desiderata in risposta alle metriche. AWS offre tre principali tipi di policy dinamiche: Target Tracking, Step Scaling e Simple Scaling. Per l'esame SAA-C03, è più importante comprendere Target Tracking e Step Scaling.

Il Target Tracking Scaling funziona come un termostato: si specificano una metrica e un valore target, quindi AWS calcola automaticamente quante istanze aggiungere o rimuovere per mantenere la metrica su quel target. Ad esempio, se si imposta come obiettivo un'utilizzazione media della CPU del 50% e l'utilizzazione sale all'80%, l'ASG aggiunge un numero sufficiente di istanze per riportare la CPU al 50%. AWS gestisce entrambe le operazioni di scale-out e scale-in.

Target Tracking supporta nativamente diverse metriche predefinite: ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut e la metrica specifica per ALB ALBRequestCountPerTarget. Per KPI specifici dell'applicazione (profondità della coda, connessioni attive, metriche aziendali personalizzate) è possibile fornire una metrica CloudWatch personalizzata. Le metriche personalizzate offrono un controllo molto più preciso sui fattori che determinano le decisioni di scaling.

Dopo un evento di scale-out, l'ASG attende un periodo di cooldown (300 secondi per impostazione predefinita) prima di valutare un altro scale-out. In questo modo le istanze appena avviate hanno il tempo di iniziare a gestire il traffico e la metrica può stabilizzarsi. Analogamente, un cooldown dello scale-in impedisce terminazioni premature subito dopo l'aggiunta di capacità. Per il target tracking, AWS raccomanda inoltre di utilizzare un periodo di warm-up, così le nuove istanze non alterano la metrica prima di essere completamente inizializzate.

Lo Step Scaling risponde agli allarmi CloudWatch aggiungendo o rimuovendo un numero specifico di istanze in base a quanto la metrica supera una soglia. Si definiscono più step adjustment: ogni intervallo copre un intervallo di valori della metrica e specifica una variazione della capacità. Ad esempio: se la CPU è tra il 60% e il 70%, aggiungere 1 istanza; se è tra il 70% e il 90%, aggiungerne 3; se supera il 90%, aggiungerne 5. In questo modo si ottengono risposte graduali e proporzionate ai diversi livelli di carico.

Lo step scaling richiede un allarme CloudWatch già esistente. L'allarme monitora una metrica e passa allo stato ALARM quando viene superata una soglia. La policy di scaling utilizza quindi gli step adjustment definiti in base al valore della metrica rispetto alla soglia dell'allarme. È possibile configurare il tipo di modifica come ChangeInCapacity (aggiunge N), ExactCapacity (imposta N) o PercentChangeInCapacity (modifica la capacità di N%).

Ogni step adjustment dispone di un MetricIntervalLowerBound e, facoltativamente, di un MetricIntervalUpperBound. I limiti sono relativi alla soglia dell'allarme. Se la soglia dell'allarme è una CPU del 60%: LowerBound=0, UpperBound=10 si attiva quando la CPU è tra il 60% e il 70%; LowerBound=10, UpperBound=null si attiva quando la CPU supera il 70%. Questo approccio a più livelli garantisce che i grandi picchi di traffico ricevano immediatamente un aumento significativo della capacità, senza attendere più cicli dell'allarme.

Il Simple Scaling è il predecessore dello step scaling. Come lo step scaling, richiede un allarme CloudWatch, ma quando viene attivato aggiunge o rimuove un numero fisso di istanze e attende poi la scadenza dell'intero periodo di cooldown prima di eseguire una nuova valutazione. Questo lo rende lento in presenza di un carico che cambia rapidamente. Lo Step Scaling è preferibile perché può continuare ad attivarsi quando le condizioni peggiorano, senza attendere il cooldown completo, e reagisce in modo proporzionale.

A volte è necessario impedire che determinate istanze vengano terminate durante lo scale-in, ad esempio un'istanza che esegue un processo batch di lunga durata. È possibile abilitare la protezione dell'istanza dallo scale-in sulle singole istanze tramite la console o la CLI. Quando l'ASG seleziona le istanze candidate alla terminazione, ignora quelle protette. È importante rimuovere la protezione al termine del processo: in caso contrario, l'ASG potrebbe non riuscire a eseguire alcuno scale-in se tutte le istanze sono protette.

È possibile collegare più policy di scaling a un unico ASG. Quando sono presenti sia una policy di target tracking sia una policy di step scaling, l'ASG utilizza la policy che raccomanda l'azione di scale-out maggiore (l'approccio più prudente). Per lo scale-in, prevale la policy che raccomanda di rimuovere il minor numero di istanze. In questo modo si impedisce al sistema di oscillare tra stati di sovraapprovvigionamento e sottodimensionamento. Un modello comune consiste nell'utilizzare una policy di target tracking per il funzionamento ordinario e una policy di step scaling per proteggersi dai picchi improvvisi.

Per la maggior parte delle applicazioni web, iniziare con il target tracking basato sulla CPU o sul numero di richieste per target: richiede una configurazione minima e AWS gestisce i calcoli. Utilizzare lo step scaling quando sono necessarie risposte graduali e proporzionate a intensità di carico diverse. Impostare sempre una capacità minima sufficiente a gestire il traffico di base senza affidarsi allo scale-out, poiché lo scaling richiede tempo. Monitorare le metriche CloudWatch GroupDesiredCapacity e GroupInServiceInstances per verificare che le policy funzionino come previsto.

Verifichi la comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che il Target Tracking Scaling calcola e applica automaticamente le operazioni di scale-out e scale-in per mantenere una metrica su un valore desiderato (ad esempio il 50% di CPU); lo Step Scaling attiva risposte proporzionalmente più ampie quando una metrica supera soglie crescenti, utilizzando step adjustment basati sugli allarmi CloudWatch; e la combinazione di policy nello stesso ASG è sicura: l'ASG utilizza la raccomandazione di scale-out più prudente e quella di scale-in meno aggressiva. Nella prossima lezione verranno esaminati lo scaling pianificato e quello predittivo per i modelli di traffico noti.