Auto Scaling e bilanciamento del carico dei servizi ECS

Un desired count fisso per un servizio ECS non può rispondere alle fluttuazioni del traffico: si rischia di sovradimensionare l'infrastruttura (sprecando denaro) oppure di sottodimensionarla (riducendo le prestazioni). ECS Service Auto Scaling adatta automaticamente il numero desiderato di task in risposta alle metriche di CloudWatch. Utilizza il servizio Application Auto Scaling in background, lo stesso framework usato da DynamoDB, Aurora ed ElastiCache. L'auto scaling dei servizi ECS supporta policy di target tracking, step scaling e scaling pianificato.

Prima di aggiungere le policy di scaling, registri il servizio ECS come scalable target in Application Auto Scaling. Specifichi il numero minimo e massimo di task, il nome del cluster e il nome del servizio come ID della risorsa. In questo modo definisce i limiti entro i quali opererà l'auto scaling. Il numero minimo garantisce sempre una capacità di base; il massimo impedisce che uno scaling incontrollato esaurisca la capacità Fargate o le istanze EC2.

Target Tracking è la policy di auto scaling consigliata per la maggior parte dei servizi ECS. La metrica target più comune è ECSServiceAverageCPUUtilization: imposti un target del 50-70% e ECS aggiunge o rimuove task per mantenere quel livello di utilizzo della CPU. Un'altra metrica molto utile è ALBRequestCountPerTarget: monitora il numero di richieste ALB per task e scala il servizio per mantenere un determinato tasso di richieste per istanza. AWS gestisce automaticamente lo scale-out e lo scale-in con periodi di cooldown appropriati.

Associare un Application Load Balancer (ALB) a un servizio ECS distribuisce il traffico HTTP/HTTPS tra tutti i task in esecuzione. Il target group dell'ALB registra l'IP di ogni task (per Fargate/awsvpc) o la porta del container (per la modalità bridge). ECS registra automaticamente i nuovi task nel target group quando vengono avviati e li deregistra quando vengono arrestati. L'ALB esegue health check su ogni task; i task non integri vengono messi in draining (le connessioni vengono chiuse con gradualità) prima che il servizio li termini.

Un pattern molto potente consiste nel instradare percorsi URL diversi verso servizi ECS diversi usando il routing basato sul percorso dell'ALB. Un singolo ALB con un listener HTTPS può instradare: /api/orders/* al servizio ECS Orders, /api/users/* al servizio ECS Users, /api/products/* al servizio ECS Products; ciascuno è supportato dal proprio servizio ECS con scaling indipendente. In questo modo non servono load balancer separati per ogni microservizio, riducendo i costi e semplificando la gestione del DNS.

Quando un task ECS sta per essere terminato (durante uno scale-in o un deployment), l'ALB lo contrassegna come draining e interrompe l'instradamento di nuove richieste verso di esso, consentendo però il completamento delle richieste in corso. Il deregistration delay (300 secondi per impostazione predefinita, configurabile da 0 a 3600 secondi) indica per quanto tempo l'ALB attende prima di chiudere forzatamente le connessioni. Per ECS con richieste di breve durata, imposti un deregistration delay più basso (30-60 secondi) per velocizzare i deployment e le operazioni di scale-in. Per connessioni di lunga durata (WebSocket, caricamenti di file), mantenga un ritardo maggiore.

Oltre a CPU e memoria, pubblichi metriche CloudWatch personalizzate dalla sua applicazione (profondità della coda, sessioni attive, KPI aziendali) e le utilizzi per attivare lo scaling. Ad esempio, se ogni task ECS può gestire contemporaneamente 50 messaggi in coda, pubblichi la profondità della coda SQS come metrica personalizzata e crei una policy di target tracking con un target di 50 messaggi per task. In questo modo lo scaling viene guidato direttamente dalla logica aziendale, invece di basarsi su metriche dell'infrastruttura che potrebbero non correlare con il carico dell'applicazione.

Analogamente all'Auto Scaling di EC2, ECS supporta la protezione dei task dallo scale-in. Un task in esecuzione può impostare il proprio flag di protezione dallo scale-in tramite l'API ECS, impedendo la propria terminazione durante lo scale-in mentre elabora un job critico. Questa funzione è utile per i task ECS che operano come worker SQS: un worker che ha appena estratto dalla coda un job lungo può proteggersi, completare il job e poi rimuovere la protezione. In sua assenza, lo scale-in potrebbe terminare un task durante l'elaborazione, causando la duplicazione del job o la perdita di dati.

Scelga con attenzione la metrica di scaling. CPU utilisation è l'impostazione predefinita ed è adatta ai carichi di lavoro vincolati dalla capacità di calcolo. Memory utilisation (ECSServiceAverageMemoryUtilization) è utile per le applicazioni vincolate dalla memoria, ma aumentare la memoria tramite lo scaling richiede l'aggiunta di task: se il task è limitato dalla memoria assegnata per task anziché dall'elaborazione simultanea, potrebbe essere preferibile correggere l'allocazione di memoria nella definizione del task. ALBRequestCountPerTarget correla direttamente con l'esperienza utente ed è la metrica più utile per le API web: esegua lo scaling in base al tasso effettivo di richieste per task.

ECS Deployment Circuit Breaker rileva automaticamente i deployment non riusciti ed esegue il rollback all'ultima versione stabile. Senza questa funzione, un deployment errato (con un container che non supera gli health check) porterebbe ECS a tentare indefinitamente di avviare nuovi task. Con il circuit breaker abilitato, se una determinata percentuale dei task appena avviati non supera gli health check entro una finestra di rilevamento, ECS contrassegna il deployment come FAILED ed esegue automaticamente il rollback alla revisione precedente della definizione del task. In questo modo si evita un degrado prolungato del servizio causato da deployment errati.

Un'architettura pronta per la produzione per un'API web containerizzata: Route 53 risolve il dominio nell'hostname DNS di un ALB; l'ALB termina HTTPS (certificato ACM), applica le regole WAF e instrada le richieste verso un target group del servizio ECS; i task Fargate nelle subnet private distribuite su 3 AZ gestiscono le richieste; ECS Service Auto Scaling, con target tracking su ALBRequestCountPerTarget, adatta il numero di task da 2 a 50; i task si connettono a RDS Aurora ed ElastiCache nelle subnet private. Tutti i log vengono inviati a CloudWatch Logs; le metriche alimentano dashboard e allarmi CloudWatch.

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

In questa lezione ha imparato che: ECS Service Auto Scaling utilizza Application Auto Scaling con il target tracking (CPU, richieste ALB o metriche personalizzate) per adattare il numero di task tra i limiti minimo e massimo configurati; il routing basato sul percorso dell'ALB consente a un solo load balancer di servire più microservizi ECS instradando i percorsi URL verso target group diversi; e Deployment Circuit Breaker esegue automaticamente il rollback dei deployment non riusciti prima che causino un degrado prolungato del servizio. Con questo si conclude il modulo su ECS e i container; ora esploreremo Amazon EKS per Kubernetes su AWS.