SAA-C03 · Question #48
A company has a three-tier web application that processes orders from customers. The web tier consists of Amazon EC2 instances behind an Application Load Balancer. The processing tier consists of…
The correct answer is D. Use an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier. The issue in this case is related to the processing tier, where EC2 instances are overwhelmed at peak times, causing delays.Option D, using anAmazon EC2 Auto Scaling target tracking policybased on theApproximateNumberOfMessagesin the SQS queue, is the best solution. Auto…
Question
A company has a three-tier web application that processes orders from customers. The web tier consists of Amazon EC2 instances behind an Application Load Balancer. The processing tier consists of EC2 instances. The company decoupled the web tier and processing tier by using Amazon Simple Queue Service (Amazon SQS). The storage layer uses Amazon DynamoDB. At peak times some users report order processing delays and halts. The company has noticed that during these delays, the EC2 instances are running at 100% CPU usage, and the SQS queue fills up. The peak times are variable and unpredictable. The company needs to improve the performance of the application Which solution will meet these requirements?
Options
- AUse scheduled scaling for Amazon EC2 Auto Scaling to scale out the processing tier instances
- BUse Amazon ElastiCache for Redis in front of the DynamoDB backend tier. Use target utilization
- CAdd an Amazon CloudFront distribution to cache the responses for the web tier. Use HTTP
- DUse an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier
How the community answered
(29 responses)- A3% (1)
- B14% (4)
- C7% (2)
- D76% (22)
Explanation
The issue in this case is related to the processing tier, where EC2 instances are overwhelmed at peak times, causing delays.Option D, using anAmazon EC2 Auto Scaling target tracking policybased on theApproximateNumberOfMessagesin the SQS queue, is the best solution. Auto Scaling with Target Tracking: Target tracking policiesdynamically scale out or in based on a specific metric. For this use case, you can monitor theApproximateNumberOfMessagesin the SQS queue. When the number of messages (orders) in the queue increases, the Auto Scaling group will scale out more EC2 instances to handle the additional load, ensuring that the queue doesn't build up and cause delays. This solution is ideal for handling variable and unpredictable peak times, as Auto Scaling can automatically adjust based on real-time load rather than scheduled times. Why Not the Other Options?: Option A (Scheduled Scaling): Scheduled scaling works well for predictable peak times, but this company experiencesunpredictable peak usage, making scheduled scaling less effective. Option B (ElastiCache for Redis): Adding a caching layer would help if DynamoDB were the bottleneck, but in this case, the issue is CPU overload on EC2 instances in the processing tier. Option C (CloudFront): CloudFront would help cache static content from the web tier, but it wouldn't resolve the issue of the processing tier's overloaded EC2 instances.
Community Discussion
No community discussion yet for this question.