Examkin

Question

Difficulty: HardPerformance and Scalability Optimization

A media company is designing a real-time news analytics platform to support a major global broadcasting event scheduled for a specific date and time. The platform serves dynamic data via an API hosted on Amazon ECS tasks running on AWS Fargate behind an Application Load Balancer (ALB). The API retrieves data from an Amazon Aurora MySQL database. Baseline traffic is 1,0001,000 requests per second, but is expected to instantly surge to 400,000400,000 requests per second at the start of the event. The workload is highly read-intensive. Which of the following architecture sets provides the most performant and scalable solution to handle the traffic spike without dropping requests?

  1. Submit an AWS Support case to pre-warm the Application Load Balancer (ALB) for the expected throughput of 400,000400,000 requests per second. Configure scheduled scaling for the ECS service to scale out Fargate tasks to a pre-calculated number of instances before the event begins. Pre-provision additional Aurora Replicas in the Amazon Aurora database cluster to handle the anticipated read query load.Answer
  2. B
    Submit an AWS Support case to pre-warm the Application Load Balancer (ALB) for the expected throughput of 400,000400,000 requests per second. Configure scheduled scaling for the ECS service to scale out Fargate tasks before the event begins, specifying the host network mode for the tasks to bypass Elastic Network Interface (ENI) provisioning latency. Pre-provision additional Aurora Replicas in the Amazon Aurora database cluster to handle the anticipated read query load.
  3. C
    Configure the Application Load Balancer (ALB) with Target Tracking scaling policies based on RequestCountPerTarget to dynamically scale the load balancer during the event. Configure ECS Target Tracking policies based on CPU utilization to scale out Fargate tasks. Configure Aurora Auto Scaling to dynamically provision Aurora Replicas when the primary writer instance's CPU utilization exceeds 70%70\%.
  4. D
    Submit an AWS Support case to pre-warm the Application Load Balancer (ALB) for the expected throughput of 400,000400,000 requests per second. Configure scheduled scaling for the ECS service to scale out Fargate tasks before the event begins. Configure an Amazon RDS Multi-AZ deployment and configure the application to direct read queries to the standby database instance to handle the peak read traffic.

Answer

The correct strategy pre-warms the Application Load Balancer (ALB), uses ECS Scheduled Scaling to prepare the container tier, and pre-provisions Amazon Aurora Replicas to absorb the database read load.
Pre-warming the ALB ensures that the entry point can handle the high network throughput immediately. Scheduled scaling for ECS Fargate ensures that the compute capacity is ready before the traffic starts. Pre-provisioning Aurora Replicas ensures that the read-heavy queries do not overwhelm the database writer node, as dynamic scaling would execute too slowly to absorb the initial peak.

Step-by-Step Solution

1
Determine the scaling capabilities of the load balancing tier under an instantaneous surge.
Dynamic scaling of ALBs cannot accommodate a rapid increase from 1,0001,000 to 400,000400,000 requests per second without dropping requests. Pre-warming must be requested.
Requesting ELB pre-warming ensures that AWS pre-allocates the necessary network interfaces and load-balancing capacity prior to the event.
2
Evaluate the scaling strategy and configuration requirements for the ECS Fargate compute tier.
ECS Fargate tasks take time to provision and bootstrap. Utilizing scheduled scaling ensures that the compute resources are active and healthy before the event. Fargate tasks must use the awsvpc network mode.
Dynamic autoscaling causes provisioning latency (cold starts), which would result in request timeouts during the initial surge.
3
Address the scaling constraints of the database layer for read-heavy operations.
Aurora auto-scaling takes minutes to provision new replicas. Pre-provisioning the Aurora Replicas before the event starts ensures the read database requests are successfully processed. RDS Multi-AZ standby instances cannot be read from.
Pre-provisioning prevents database CPU exhaustion and query timeouts when the instantaneous load begins.

Key Concept

Handling sudden, high-magnitude traffic spikes requires proactive pre-warming and pre-provisioning across the networking, compute, and database tiers, rather than relying on reactive dynamic scaling.
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic