
Answer-first summary for fast verification
Answer: Use backlog per instance metric with target tracking scaling policy
Use backlog per instance metric with target tracking scaling policy - 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. The issue with using a CloudWatch Amazon SQS metric like ApproximateNumberOfMessagesVisible for target tracking is that the number of messages in the queue might not change proportionally to the size of the Auto Scaling group that processes messages from the queue. That's because the number of messages in your SQS queue does not solely define the number of instances needed. The number of instances in your Auto Scaling group can be driven by multiple factors, including how long it takes to process a message and the acceptable amount of latency (queue delay). The solution is to use a backlog per instance metric with the target value being the acceptable backlog per instance to maintain. You can calculate these numbers as follows: Backlog per instance: To calculate your backlog per instance, start with the ApproximateNumberOfMessages queue attribute to determine the length of the SQS queue (number of messages available for retrieval from the queue). Divide that number by the fleet's running capacity, which for an Auto Scaling group is the number of instances in the InService state, to get the backlog per instance. Acceptable backlog per instance: To calculate your target value, first determine what your application can accept in terms of latency. Then, take the acceptable latency value and divide it by the average time that an EC2 instance takes to process a message. To illustrate with an example, let's say that the current ApproximateNumberOfMessages is 1500 and the fleet's running capacity is 10. If the average processing time is 0.1 seconds for each message and the longest acceptable latency is 10 seconds, then the acceptable backlog per instance is 10 / 0.1, which equals 100. This means that 100 is the target value for your target tracking policy. If the backlog per instance is currently at 150 (1500 / 10), your fleet scales out, and it scales out by five instances to maintain proportion to the target value.
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
An e-commerce company has created an API hosted on Amazon ECS. They are experiencing variable traffic spikes leading to delays in order processing. The order processing is managed through Amazon SQS queues, and monitoring reveals that the ApproximateNumberOfMessagesVisible metric frequently spikes to very high values during the day, triggering a CloudWatch alarm. However, other ECS metrics for the API containers remain within acceptable limits.
As a Developer Associate, which of the following improvements would you recommend to enhance performance while maintaining cost efficiency?
A
Use backlog per instance metric with target tracking scaling policy
B
Use Docker swarm
C
Use ECS step scaling policy
D
Use ECS service scheduler