Examkin

Soru

Zorluk: ZorPerformance and Scalability Optimization

A global online gaming company is launching a multiplayer battle royale game designed to support 5,000,0005,000,000 concurrent users. The architecture uses Application Load Balancers (ALBs) to route traffic to matchmaking microservices running on Amazon ECS tasks using the AWS Fargate launch type. Matchmaking state is stored in an Amazon Aurora PostgreSQL Serverless v2 database, and session tracking uses Amazon ElastiCache for Redis. During global marketing events, matchmaking traffic is projected to surge from 10,000 requests/sec10,000\text{ requests/sec} to over 500,000 requests/sec500,000\text{ requests/sec} in under 60 seconds60\text{ seconds}. A solutions architect must design a highly scalable and performant solution that prevents connection failures and database bottlenecks during these sudden spikes. Which combination of actions will meet these scalability and performance requirements while minimizing connection failures and request latency? (Select TWO.)

  1. Submit a support ticket to AWS Support to pre-warm the Application Load Balancers with the expected peak traffic volume and request rate prior to the scheduled marketing events.Cevap
  2. Configure scheduled scaling policies for the ECS Service Auto Scaling to scale out the matchmaking Fargate tasks to the estimated peak capacity before the marketing events start.Cevap
  3. C
    Configure the Application Load Balancers to scale out dynamically using a target tracking scaling policy based on the RequestCountPerTarget metric, allowing the load balancers to adjust to the traffic surge in real time.
  4. D
    Scale the matchmaking database reads by configuring the ECS Fargate tasks to route read-heavy queries directly to the Amazon RDS Multi-AZ standby instance of the database during the surge.
  5. E
    Migrate the session tracking cache from Amazon ElastiCache for Redis to ElastiCache for Memcached to utilize its multi-threaded engine for faster request handling, and enable multi-AZ replication across three Availability Zones.

Cevap

Pre-warming the Application Load Balancers (ALBs) by submitting an AWS Support request and pre-scaling the Amazon ECS Fargate tasks using scheduled scaling policies prior to the events.
Pre-warming the Application Load Balancer prevents connection drops caused by the latency of the load balancer's built-in scaling algorithm when hit by sudden, massive traffic spikes. Scheduled scaling for ECS Service Auto Scaling ensures that ECS tasks are already launched, bootstrapped, and ready to receive traffic before the spike starts, avoiding container capacity exhaustion.

Adım Adım Çözüm

1
Address the load balancer scaling limitation.
By pre-warming the ALBs with AWS Support, the load balancers are provisioned with sufficient capacity in advance to absorb a 50×50\times spike in request rate without dropping connections.
Standard ALB auto-scaling is gradual and cannot scale fast enough to meet a 50×50\times traffic surge within 60 seconds60\text{ seconds}.
2
Proactively scale the ECS Fargate compute layer.
Using scheduled scaling policies for ECS Service Auto Scaling to scale out Fargate tasks ahead of the event ensures compute capacity is fully running and ready to handle requests immediately.
Target tracking scaling is reactive and introduces bootstrapping latency, which causes container resource saturation during rapid flash traffic.
3
Discard passive read routing options.
Avoid options suggesting routing queries to the Multi-AZ standby instance, as standby instances are replication targets that cannot accept user connections.
Only Aurora Replicas or RDS Read Replicas can be used for read scaling.

Anahtar Kavram

Handling extreme flash traffic spikes requires proactive capacity allocation at both the load balancing and compute layers, as reactive scaling mechanisms introduce too much latency.
Bu soruyu puanla

Konular

Performance and Scalability Optimization

Bu konudan daha fazla soru