Soru

Zorluk: OrtaPerformance and Scalability Optimization

A media company is launching a live voting application for a popular television show finale. During the 1010-minute voting window, concurrent user connections are expected to spike instantaneously from a baseline of 100100 requests per second to 120,000120,000 requests per second. The application must perform a read-heavy database query to verify a voter's eligibility before recording their vote. The application runs on Amazon ECS with Amazon Aurora MySQL as the database. Which architectural design will meet these scalability requirements with the lowest latency?

  1. A
    Rely on the default Application Load Balancer auto-scaling to dynamically handle the traffic spike. Configure the Amazon Aurora database with Multi-AZ deployment and route the eligibility checks to the standby instance to distribute the load.
  2. B
    Rely on the default Application Load Balancer auto-scaling to scale out as traffic increases. Pre-provision the required number of Aurora Replicas before the voting window opens and configure the application to query the reader endpoint.
  3. Submit a support request to AWS to pre-warm the Application Load Balancers (ALBs) to the expected traffic volume before the event. Manually provision the required number of Aurora Replicas prior to the voting window and use the reader endpoint for eligibility checks.Cevap
  4. D
    Submit a support request to AWS to pre-warm the Application Load Balancers (ALBs) to the expected traffic volume before the event. Route eligibility checks to the Aurora primary instance and rely on Multi-AZ standby instances to dynamically scale read capacity during peak load.

Cevap

Submit a support request to AWS to pre-warm the Application Load Balancers (ALBs) to the expected traffic volume before the event. Manually provision the required number of Aurora Replicas prior to the voting window and use the reader endpoint for eligibility checks.
The correct answer recommends pre-warming the Application Load Balancers (ALBs) and manually pre-provisioning Aurora Replicas. An instantaneous traffic spike from 100100 to 120,000120,000 requests per second exceeds the default scaling rate of ALBs, leading to dropped requests unless they are pre-warmed by AWS Support. Furthermore, database auto-scaling is too slow to react to an instantaneous surge, meaning database replicas must be manually provisioned in advance. Using the reader endpoint properly distributes the read-heavy query load across these replicas.

Adım Adım Çözüm

1
Identify the scaling limits of Application Load Balancers during instantaneous traffic spikes.
Recognize that ALBs scale gradually and cannot handle a sudden jump from 100100 to 120,000120,000 requests per second without dropping requests, necessitating ELB pre-warming.
Pre-warming configures the load balancer's capacity beforehand to absorb the immediate surge.
2
Determine how to handle the read-heavy database workload under rapid scaling constraints.
Identify that dynamic Auto Scaling for database replicas is too slow for instantaneous spikes, so pre-provisioning Aurora Replicas is required.
Manually scaling the database replicas before the window opens ensures the capacity is available immediately.
3
Evaluate the role of standby instances in high availability configurations.
Recognize that Multi-AZ standby instances do not serve read traffic or scale dynamic query loads in Aurora or standard RDS, and only reader replicas can be used for read scaling.
Routing read traffic to a standby instance fails because standby instances are reserved for failover and cannot accept read queries.

Anahtar Kavram

Handling flash traffic surges and scaling database read capacity in AWS require pre-provisioning and pre-warming because automated scaling mechanisms have a startup latency.
Bu soruyu puanla