Soru

Zorluk: OrtaPerformance and Scalability Optimization

A digital ride-hailing company is launching a new carpooling service that matches passengers traveling along similar routes. The matching service runs on Amazon ECS tasks using AWS Fargate behind an Application Load Balancer (ALB). During rush hours, the platform expects requests to scale instantly from 2,0002,000 to 180,000180,000 requests per second. Passenger and ride metadata is stored in an Amazon Aurora PostgreSQL database cluster. During initial load testing, the database experiences CPU exhaustion due to read-heavy query surges, and the ALB drops incoming requests during the initial minutes of the traffic spike.

Which two actions should a Solutions Architect recommend to optimize the performance and scalability of the architecture under these conditions? (Select TWO.)

  1. Submit a support case to AWS to pre-warm the Application Load Balancer to the anticipated peak traffic volume.Cevap
  2. Provision an Amazon ElastiCache for Redis cluster to cache the passenger and ride metadata, offloading the read queries from the database.Cevap
  3. C
    Configure target tracking scaling policies on the Application Load Balancer to dynamically scale the load balancer capacity during the spike.
  4. D
    Configure the Amazon Aurora cluster to route read traffic to the standby instance of the Multi-AZ deployment during peak hours.
  5. E
    Deploy an Amazon ElastiCache for Memcached cluster with multi-region replication to persistently store and synchronize the ride and session states.

Cevap

The solutions architect should recommend submitting a support case to AWS to pre-warm the Application Load Balancer, and provisioning an Amazon ElastiCache for Redis cluster to cache the read-heavy passenger and ride metadata.
To handle sudden, extreme spikes in traffic, the Application Load Balancer must be pre-warmed by AWS Support to ensure it can immediately accept the load without scaling latency. Caching the highly repetitive passenger and ride metadata in an Amazon ElastiCache for Redis cluster offloads the read traffic from the Amazon Aurora database, preventing CPU starvation and ensuring low-latency data access.

Adım Adım Çözüm

1
Analyze the scaling characteristics of the Application Load Balancer during instant spikes.
Identified that Application Load Balancers scale gradually in response to incoming traffic, meaning a sudden surge from 2,0002,000 to 180,000180,000 requests per second will cause dropped packets during the provisioning lag.
To prevent dropped requests at the entry point, the load balancer capacity must be pre-provisioned by requesting ELB pre-warming from AWS Support.
2
Address the database CPU exhaustion caused by read-heavy matching queries.
Determined that caching passenger and ride metadata will offload highly repetitive read queries from the Aurora PostgreSQL database.
Amazon ElastiCache for Redis offers sub-millisecond latency and high-throughput read capabilities, resolving database bottlenecks.
3
Evaluate and rule out sub-optimal storage, replication, and scaling options.
Discarded Memcached due to lack of replication/persistence features, and ruled out Multi-AZ standby routing because standby nodes in RDS cannot serve reads, and dynamic replica scaling experiences spin-up lag during instant spikes.
Ensures that the final architecture adheres to AWS best practices for high-performance and low-latency workloads.

Anahtar Kavram

Handling instant flash traffic using Application Load Balancer pre-warming and database read caching with Amazon ElastiCache for Redis.
Bu soruyu puanla