Una empresa ejecuta una aplicación web de tres niveles que procesa pedidos de clientes. El nivel web utiliza instancias de Amazon EC2 detrás de un Application Load Balancer. El nivel de procesamiento utiliza instancias de EC2. La empresa desacopló los niveles web y de procesamiento utilizando Amazon Simple Queue Service (Amazon SQS). La capa de almacenamiento es Amazon DynamoDB. Durante los períodos pico, algunos usuarios informan retrasos en el procesamiento de pedidos. Durante estos retrasos, las instancias de EC2 están al 100% de CPU y la cola de SQS se acumula. Los picos son variables e impredecibles. La empresa necesita mejorar el rendimiento de la aplicación. ¿Qué solución cumple con estos requisitos?

La opción correcta es utilizar una política de seguimiento de destino de Amazon EC2 Auto Scaling para escalar horizontalmente las instancias del nivel de procesamiento, usando ApproximateNumberOfMessages como métrica. Los picos son impredecibles y la cola de SQS se acumula, lo que indica que el nivel de procesamiento no puede manejar la carga. ApproximateNumberOfMessages en SQS es una métrica directa de la carga de trabajo pendiente y permite que Auto Scaling reaccione dinámicamente para mantener un número objetivo de mensajes en la cola, asegurando que las instancias de procesamiento escalen a tiempo para evitar retrasos. Las otras opciones son incorrectas porque: El escalado programado no funciona para picos impredecibles. Amazon ElastiCache para Redis ayudaría a DynamoDB, pero el problema principal es la capacidad de procesamiento del nivel intermedio, no la base de datos. Añadir CloudFront almacenaría en caché el nivel web, pero el cuello de botella está en el nivel de procesamiento y la cola de SQS.