You have an S3 bucket that receives photos uploaded by customers.
When an object is uploaded, an event notification is sent to an SQS queue with the object details.
You also have an ECS cluster that gets messages from the queue to do the batch processing.
Each of the batch processing job takes the same amount of time to get executed.
The queue size may change greatly depending on the number of incoming messages and backend processing speed.
Which metric would you use to scale up/down the ECS cluster capacity?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer - A.
In this scenario, the SQS queue is used to store the object details, which is a highly scalable and reliable service.
ECS is ideal for performing batch processing, and it should scale up or down based on the number of messages in the queue.
If you use a target tracking scaling policy based on a custom Amazon SQS queue metric, dynamic scaling can adjust to the demand curve of your application more effectively.
Option A is CORRECT: Users can configure a CloudWatch alarm based on the number of messages in the SQS queue and notify the ECS cluster to scale up or down using the alarm.
Option B is incorrect: Because the memory usage may not be able to reflect the workload.
Option C is incorrect: Because the number of objects in S3 cannot determine if the ECS cluster should change its capacity.
Option D is incorrect: Because the number of containers cannot be used as a metric to trigger an auto-scaling event.
An Auto Scaling group to manage EC2 instances for the purposes of processing messages from an SQS queue.
A custom metric to send to Amazon CloudWatch that measures the number of messages in the queue per EC2 instance in the Auto Scaling group.
A target tracking policy that configures your Auto Scaling group to scale based on the custom metric and a set target value.
CloudWatch alarms invoke the scaling policy.
For details, please check
https://github.com/aws-samples/ecs-refarch-batch-processing.The metric that should be used to scale up/down the ECS cluster capacity in this scenario is the number of messages in the SQS queue.
Here's why:
When an object is uploaded to the S3 bucket, an event notification is sent to an SQS queue with the object details. The ECS cluster then gets messages from the queue to do batch processing. Each of the batch processing jobs takes the same amount of time to execute.
The queue size may change greatly depending on the number of incoming messages and backend processing speed. Therefore, to ensure that there are enough resources to handle the incoming messages and process them in a timely manner, the ECS cluster needs to be scaled up or down dynamically based on the queue size.
The number of messages in the SQS queue is the most relevant metric to use for scaling the ECS cluster capacity. If the number of messages in the queue increases, it means there is more work to be done, and the ECS cluster should be scaled up to handle the increased workload. If the number of messages in the queue decreases, it means the workload is decreasing, and the ECS cluster should be scaled down to reduce costs.
The other metrics provided in the answer options are not relevant to scaling the ECS cluster in this scenario. Memory usage of the ECS cluster is not a good metric to use because it doesn't directly correlate with the workload of processing messages from the SQS queue. The number of objects in the S3 bucket is also not relevant because it doesn't give any indication of the workload of processing messages from the SQS queue. Finally, the number of containers in the ECS cluster is also not relevant because the number of containers doesn't directly correlate with the workload of processing messages from the SQS queue.