Un'azienda esegue un'applicazione interna basata su browser su istanze EC2 dietro un Application Load Balancer. Le istanze si trovano in un gruppo Auto Scaling distribuito su più zone di disponibilità. Il gruppo scala fino a 20 istanze durante l'orario di lavoro e scala a 2 istanze durante la notte. Il personale afferma che l'applicazione è molto lenta all'inizio della giornata, anche se funziona bene a metà mattina. Come dovrebbe essere modificata la scalabilità per risolvere i reclami mantenendo bassi i costi?

L'opzione corretta è implementare un'azione di target tracking con una soglia di CPU inferiore e diminuire il periodo di cooldown. Il target tracking è ideale per mantenere un utilizzo specifico della CPU, garantendo che le istanze siano pronte prima che il carico di lavoro aumenti significativamente. Una soglia di CPU inferiore (es. 40% invece di 60%) farebbe scalare il gruppo più proattivamente. Diminuire il periodo di cooldown ridurrebbe il tempo di attesa tra le azioni di scalabilità, permettendo al sistema di reagire più rapidamente all'aumento della domanda mattutina. Le azioni pianificate (impostando la capacità desiderata o minima/massima a 20) sono utili per scenari prevedibili, ma potrebbero non essere abbastanza dinamiche per gestire fluttuazioni impreviste o per ottimizzare i costi se il traffico non raggiunge sempre il picco massimo. Il problema descritto è che l'applicazione è lenta all'inizio della giornata, suggerendo che il sistema non scala abbastanza velocemente per soddisfare la domanda iniziale. Il target tracking, con le modifiche suggerite, affronta direttamente questo problema in modo più efficiente rispetto a una scalabilità basata su step scaling con una soglia di CPU inferiore e un periodo di cooldown ridotto, poiché il target tracking è progettato per mantenere un utilizzo medio specifico, rendendolo più adatto per carichi di lavoro che variano.