Un team DevOps distribuisce un'applicazione ECS dietro un ALB utilizzando CodeDeploy con blue/green all-at-once. Una recente release ha causato un grande aumento dei tempi di risposta e ha richiesto un rollback. Il team desidera un approccio di deployment che consenta di osservare una nuova versione prima di spostare tutto il traffico e di eseguire rapidamente il rollback se i tempi di risposta aumentano. Quale combinazione di passaggi soddisfa questa esigenza?

La configurazione di deployment CodeDeployDefault.ECSCanary10Percent5Minutes è corretta perché implementa una strategia canary. Questa strategia invia il 10% del traffico alla nuova versione per 5 minuti, permettendo di osservare il comportamento prima di spostare tutto il traffico. Questo soddisfa l'esigenza di osservare la nuova versione prima di un deployment completo. L'opzione CodeDeployDefault.ECSLinear10PercentEvery3Minutes è meno adatta perché, sebbene sia progressiva, non offre un periodo di osservazione prolungato prima di aumentare il traffico. Creare un allarme CloudWatch sulla metrica ALB TargetResponseTime che si attiva quando il tempo di risposta supera una soglia e associarlo al gruppo di deployment di CodeDeploy per eseguire il rollback è corretto. Questo allarme monitora direttamente l'indicatore di performance critico (tempo di risposta) e attiva un rollback automatico se la nuova versione causa un peggioramento, soddisfacendo l'esigenza di un rapido rollback in caso di problemi. L'allarme UnHealthyHostCount è meno efficace perché rileva solo host non sani, non necessariamente un aumento dei tempi di risposta. L'allarme TargetConnectionErrorCount rileva errori di connessione, non direttamente i tempi di risposta elevati.