Examkin

Soru

Zorluk: OrtaPerformance and Scalability Optimization

A gaming company is launching a multiplayer mobile game. The game includes a daily leaderboard challenge that ends at exactly 18:0018:00 UTC. For a 1010-minute window immediately following the event's end, active user traffic increases from a baseline of 2,0002,000 requests per second to 150,000150,000 requests per second as players check their final rankings. The application is hosted on Amazon ECS tasks running on AWS Fargate behind an Application Load Balancer (ALB), with an Amazon Aurora MySQL database cluster storing player scores. Which two actions should the solutions architect take to ensure the application scales efficiently and handles the sudden traffic spike without dropping requests?

  1. Submit a support case to AWS to pre-warm the Application Load Balancer to the expected peak of 150,000150,000 requests per second.Cevap
  2. Configure Scheduled Scaling for the Amazon ECS service and pre-provision Amazon Aurora Replicas to scale out resources before 18:0018:00 UTC.Cevap
  3. C
    Rely on the Application Load Balancer's automatic scaling and configure ECS Service Auto Scaling with target tracking policies to scale out container instances dynamically as the spike occurs.
  4. D
    Enable Amazon RDS Multi-AZ on the database cluster and configure the application to redirect read traffic to the standby DB instance during the peak window.
  5. E
    Deploy an Amazon ElastiCache for Memcached cluster to cache the leaderboard data, configuring multi-AZ replication to ensure high availability for the read cache during the peak window.

Cevap

Submit a support case to AWS to pre-warm the Application Load Balancer, and configure Scheduled Scaling for the Amazon ECS service along with pre-provisioning Amazon Aurora Replicas before the daily peak event.
For predictable daily spikes that scale up instantly, reactive target tracking scaling is ineffective. Pre-warming the Application Load Balancer ensures that AWS provisions the underlying resources necessary to route the 150,000150,000 requests per second without dropping packets. Simultaneously, using Scheduled Scaling on ECS and pre-provisioning Aurora Replicas guarantees that the compute and database tiers are fully scaled out before the traffic arrives at 18:0018:00 UTC.

Adım Adım Çözüm

1
Analyze the nature of the traffic surge.
The surge is instantaneous (from 2,0002,000 to 150,000150,000 requests per second) and occurs at a predictable daily time (18:0018:00 UTC).
This predictability dictates that scheduled scaling is superior to reactive dynamic scaling, which takes several minutes to boot up instances.
2
Determine the scaling requirements for the entry point (Application Load Balancer).
The ALB must be pre-warmed by submitting a support ticket to AWS.
ALBs scale gradually based on traffic. A sudden 75x increase will cause connection timeouts and dropped requests unless the load balancer is pre-warmed to the expected capacity.
3
Address compute scaling for the containerized application layer.
Schedule the ECS service to scale out tasks ahead of 18:0018:00 UTC.
Target tracking scaling policies cannot react fast enough to instantiate new containers within the short 1010-minute window.
4
Address read scaling for the database layer.
Pre-provision Aurora Replicas to handle the surge in query volume.
Aurora Replicas handle read scaling, whereas RDS Multi-AZ standby instances are passive and cannot serve read traffic.

Anahtar Kavram

Handling predictable flash traffic requires proactive resource scheduling and pre-warming of edge/load balancing services, rather than relying on reactive auto-scaling policies.
Bu soruyu puanla

Konular

Performance and Scalability Optimization

Bu konudan daha fazla soru