Een bedrijf runt een drielaagse webapplicatie die klantorders verwerkt. De weblaag gebruikt Amazon EC2-instances achter een Application Load Balancer. De verwerkingslaag gebruikt EC2-instances. Het bedrijf heeft de web- en verwerkingslagen ontkoppeld met behulp van Amazon Simple Queue Service (Amazon SQS). De opslaglaag is Amazon DynamoDB. Tijdens piekuren melden sommige gebruikers vertragingen bij de orderverwerking. Tijdens deze vertragingen zijn de EC2-instances voor 100% bezet en loopt de SQS-wachtrij vol. Pieken zijn variabel en onvoorspelbaar. Het bedrijf moet de applicatieprestaties verbeteren. Welke oplossing voldoet aan deze vereisten?

De correcte optie is het gebruik van een Amazon EC2 Auto Scaling target tracking policy met het ApproximateNumberOfMessages-attribuut. De SQS-wachtrij loopt vol en de verwerkings-EC2-instances zijn 100% bezet, wat duidt op een knelpunt in de verwerkingslaag. Een target tracking policy kan automatisch het aantal instances aanpassen om een specifieke metrische waarde te handhaven. Door ApproximateNumberOfMessages in de SQS-wachtrij als metriek te gebruiken, schaalt Auto Scaling proactief de verwerkingsinstances op wanneer het aantal berichten in de wachtrij toeneemt, waardoor vertragingen worden voorkomen en de verwerking wordt versneld. Gepland schalen (optie 1) is niet geschikt omdat pieken variabel en onvoorspelbaar zijn. ElastiCache (optie 2) zou de DynamoDB-laag optimaliseren, maar het probleem ligt bij de verwerking van berichten uit de SQS-wachtrij. CloudFront (optie 3) cachet webinhoud en lost het knelpunt in de backend-verwerkingslaag niet op.