Examkin

Question

Difficulty: MediumPerformance and Scalability Optimization

A media company is launching a live interactive voting feature during a weekly television broadcast. The platform expects an immediate traffic spike of 300,000300,000 concurrent requests within the first 3030 seconds of the voting window opening. The application retrieves user profiles and records votes. The current architecture consists of an Application Load Balancer (ALB) routing traffic to an Amazon ECS service running on AWS Fargate, backed by an Amazon Aurora PostgreSQL DB cluster. During load testing, the ALB drops requests with 503503 Service Unavailable errors during the first minute of the spike, and the database becomes unresponsive due to read contention on the user profiles table. Which combination of actions will resolve these performance and scalability issues?

  1. Request AWS Support to pre-warm the ALB to the expected traffic volume before the broadcast, and create Aurora Replicas with Aurora Auto Scaling enabled to scale the read capacity of the database cluster.Answer
  2. B
    Enable target tracking scaling policies on the ALB based on active connections, and enable Amazon RDS Multi-AZ deployment to route read queries to the standby database instance.
  3. C
    Request AWS Support to pre-warm the ALB to the expected traffic volume before the broadcast, and enable Amazon RDS Multi-AZ deployment to distribute the read query load to the standby instance.
  4. D
    Configure ECS scheduled scaling to pre-provision Fargate tasks, increase the instance size of the primary Aurora DB instance to handle the read query volume, and rely on the ALB's default automatic scaling.

Answer

Request AWS Support to pre-warm the ALB to the expected traffic volume before the broadcast, and create Aurora Replicas with Aurora Auto Scaling enabled to scale the read capacity of the database cluster.
The correct solution addresses the load balancer bottleneck by pre-warming the Application Load Balancer (ALB) via AWS Support to ensure it is pre-provisioned for the anticipated spike. It addresses the database bottleneck by adding Aurora Replicas and enabling Aurora Auto Scaling, which scales read capacity horizontally to handle the user profile queries.

Step-by-Step Solution

1
Address the load balancer scaling limitation for flash traffic.
By pre-warming the Application Load Balancer (ALB) before the scheduled broadcast, the ALB is provisioned with sufficient capacity to handle the sudden burst of 300,000300,000 concurrent requests, preventing 503503 errors.
Standard ELB scaling is gradual and cannot keep pace with instant spikes of this magnitude.
2
Address the database read query contention.
By creating Aurora Replicas and configuring Aurora Auto Scaling, read queries can be offloaded from the primary instance and distributed across multiple replicas that scale dynamically.
Offloading reads to replicas resolves database contention, and Aurora Auto Scaling ensures capacity matches the load.

Key Concept

Horizontal scalability of load balancing and database read layers to handle predictable flash traffic spikes.

Alternative Method

Instead of relying on database query scaling, user profiles could be cached using Amazon ElastiCache for Redis or offloaded to a high-throughput NoSQL database like Amazon DynamoDB if the data structure permits. However, within the relational DB context, scaling reads horizontally via Aurora Replicas is the standard primary solution.
Estimated Time:2m 30s
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic