Soru

Zorluk: ZorPerformance and Scalability Optimization

A high-traffic e-commerce company is launching a highly anticipated flash sale event. The application is hosted on Amazon ECS tasks using the AWS Fargate launch type behind an Application Load Balancer (ALB). The database tier consists of an Amazon Aurora MySQL cluster. Normal operations generate approximately 1,2001,200 requests per second, but telemetry from previous events indicates that traffic will instantly spike to 450,000450,000 requests per second within a 6060-second window at the start of the sale. The majority of the traffic consists of read-heavy product catalog searches and inventory queries, along with a high volume of order placements.

Which two architectural optimizations should the Solutions Architect implement to ensure the application scales effectively without dropping requests or suffering from high latency? (Select TWO.)

  1. Submit an AWS Support case to pre-warm the Application Load Balancer with the expected request rate, and configure scheduled scaling for the ECS tasks to scale out before the sale begins.Cevap
  2. B
    Configure a Multi-AZ standby instance in the Aurora cluster and route the read-heavy queries to the standby instance to distribute the query load.
  3. Add Aurora Replicas to the cluster and configure Aurora Auto Scaling to scale the reader instances dynamically based on average CPU utilization.Cevap
  4. D
    Rely on the Application Load Balancer to automatically scale in response to the sudden traffic spike, and configure target tracking scaling policies on the ECS service based on the ApplicationLoadBalancerRequestCountPerTarget metric.
  5. E
    Deploy an Amazon ElastiCache for Memcached cluster to cache catalog queries, relying on Memcached's native multi-AZ replication to ensure read scalability.

Cevap

Submit an AWS Support case to pre-warm the Application Load Balancer with the expected request rate, and configure scheduled scaling for the ECS tasks to scale out before the sale begins; and add Aurora Replicas to the cluster and configure Aurora Auto Scaling to scale the reader instances dynamically based on average CPU utilization.
Pre-warming the Application Load Balancer (ALB) and pre-scaling the ECS tasks using scheduled scaling ensures the infrastructure is ready to accept the massive, instantaneous spike of 450,000450,000 requests per second without causing connection timeouts or container provisioning delays. Scaling database read performance is achieved by adding Aurora Replicas and using Aurora Auto Scaling, which dynamically adjusts reader capacity based on CPU usage to distribute read-heavy query loads.

Adım Adım Çözüm

1
Analyze the scale and rate of the incoming traffic spike.
The traffic scales traffic from 1,2001,200 requests per second to 450,000450,000 requests per second within a 6060-second window.
Identifying this extremely short ramp-up window prevents the use of reactive scaling methods for front-end components.
2
Determine the scalability strategy for the ingress/routing tier.
The Application Load Balancer must be manually pre-warmed via AWS Support, and ECS tasks must be pre-scaled using scheduled scaling.
Dynamic scaling of the ALB and reactive scaling of ECS tasks based on metrics are too slow to absorb a massive spike in under a minute without causing dropped connections and latency.
3
Select the appropriate scaling mechanism for the database read capacity.
Aurora Replicas are deployed and managed with Aurora Auto Scaling linked to the reader endpoint.
Amazon Aurora requires active reader replicas to offload read-heavy query traffic, and standard standby nodes are not designed to serve read traffic.

Anahtar Kavram

Handling massive, near-instantaneous traffic spikes (flash traffic) requires pre-provisioning capacity (ALB pre-warming and scheduled task scaling) and horizontally scaling the database layer using reader replicas rather than relying on dynamic load balancer scaling or passive standby instances.
Tahmini Süre:3m 0s
Bu soruyu puanla