Un'applicazione Java è stata distribuita su AWS Elastic Beanstalk utilizzando un ambiente a istanza singola per risparmiare sui costi durante lo sviluppo. I test mostrano un utilizzo sostenuto della CPU superiore all'85%, causando colli di bottiglia nelle prestazioni. È necessario mitigare il collo di bottiglia della CPU prima della produzione con il minor overhead operativo. Cosa dovresti fare?

La modifica della configurazione della capacità dell'ambiente Elastic Beanstalk esistente è l'opzione con il minor overhead operativo. Permette di passare da un ambiente a istanza singola a un ambiente con bilanciamento del carico, abilitare più Availability Zone per la resilienza e configurare una policy di auto-scaling basata sull'utilizzo medio della CPU. Questo risolve il problema del collo di bottiglia della CPU e migliora la disponibilità senza ricreare l'intera applicazione o gestire deployment complessi. Le opzioni che prevedono la creazione di una nuova applicazione o un secondo ambiente Elastic Beanstalk introducono un overhead operativo maggiore, poiché richiedono la gestione di più ambienti o l'implementazione di strategie di deployment più complesse. L'opzione di utilizzare "Rebuild environment" con una singola Availability Zone non offre la resilienza necessaria e "utilizzo totale della CPU" non è una metrica standard per l'auto-scaling in Elastic Beanstalk.