Un'azienda gestisce un'applicazione web a tre livelli che elabora gli ordini dei clienti. Il livello web utilizza istanze Amazon EC2 dietro un Application Load Balancer. Il livello di elaborazione utilizza istanze EC2. L'azienda ha disaccoppiato i livelli web e di elaborazione utilizzando Amazon Simple Queue Service (Amazon SQS). Il livello di storage è Amazon DynamoDB. Durante i periodi di punta, alcuni utenti segnalano ritardi nell'elaborazione degli ordini. Durante questi ritardi, le istanze EC2 sono al 100% della CPU e la coda SQS si accumula. I picchi sono variabili e imprevedibili. L'azienda deve migliorare le prestazioni dell'applicazione. Quale soluzione soddisfa questi requisiti?

La soluzione corretta è utilizzare una policy di target tracking di Amazon EC2 Auto Scaling per scalare orizzontalmente le istanze del livello di elaborazione, usando l'attributo ApproximateNumberOfMessages di SQS. Questo perché la coda SQS che si accumula indica che il livello di elaborazione non riesce a processare i messaggi abbastanza velocemente. Scalare le istanze EC2 del livello di elaborazione in base al numero di messaggi in coda garantisce che la capacità si adatti dinamicamente al carico di lavoro imprevedibile, risolvendo i ritardi. Le altre opzioni sono meno efficaci: Lo scaling pianificato non è adatto a picchi variabili e imprevedibili. ElastiCache per Redis migliorerebbe le prestazioni di DynamoDB, ma il problema principale è la capacità di elaborazione dei messaggi SQS, non la latenza del database. CloudFront migliorerebbe le prestazioni del livello web, ma il collo di bottiglia è il livello di elaborazione, come indicato dalla coda SQS che si accumula.