Soru

Zorluk: Çok zorOptimizing Compute and Storage Performance

An enterprise reporting application runs on a fleet of Amazon EC2 instances in an Auto Scaling Group behind an Application Load Balancer (ALB). The application queries an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment. At the start of every fiscal quarter, the number of concurrent users spikes from 100100 to over 50,00050,000 within a 55-minute window to run complex data extraction reports. During this peak window, the application experiences high latency and drops connections, resulting in `HTTP 504 Gateway Timeout` errors. CloudWatch metrics indicate that the RDS DB instance CPU utilization reaches 100%100\% due to read-heavy queries, while write IOPS remain negligible. The database storage is configured with a 2 TiB2\text{ TiB} General Purpose SSD (`gp3`) volume. Which strategy should a Solutions Architect implement to optimize the compute and storage layers to handle the quarterly spike with minimum latency and zero dropped requests?

  1. A
    Modify the reporting application to distribute read queries between the primary RDS DB instance and the secondary standby RDS DB instance in the alternate Availability Zone. Submit a support ticket to AWS Support to pre-warm the Application Load Balancer, and scale the RDS storage to a 3 TiB3\text{ TiB} `gp3` volume to increase the baseline performance limits.
  2. B
    Migrate the RDS PostgreSQL database to Amazon Aurora PostgreSQL. Configure Aurora Auto Scaling to scale reader instances dynamically based on CPU utilization, and update the application to route read queries to the Aurora reader endpoint. Rely on the Application Load Balancer's automatic scaling mechanisms to scale out connection capacity as the user traffic arrives.
  3. C
    Configure the Application Load Balancer to forward traffic using a TCP listener to bypass HTTP layer routing delays. Create an Amazon RDS PostgreSQL Read Replica in the same Availability Zone and configure the application to send read queries to the replica. Rely on standard Application Load Balancer automatic scaling to handle the connection burst.
  4. Migrate the RDS PostgreSQL database to Amazon Aurora PostgreSQL. Configure Aurora Auto Scaling to scale reader instances dynamically based on CPU utilization, and update the application to route read queries to the Aurora reader endpoint. Submit a support ticket to AWS Support to pre-warm the Application Load Balancer before the quarterly reporting window begins.Cevap

Cevap

Migrate the RDS PostgreSQL database to Amazon Aurora PostgreSQL, configure Aurora Auto Scaling for reader instances, route read queries to the reader endpoint, and submit a support ticket to AWS Support to pre-warm the Application Load Balancer prior to the start of the quarterly reporting window.
Migrating to Amazon Aurora PostgreSQL allows the database layer to scale out read capacity horizontally using Aurora reader replicas. Configuring Aurora Auto Scaling enables the read capacity to dynamically match the query load. Updating the reporting application to use the reader endpoint routes the heavy read queries away from the writer instance, preserving its performance. Crucially, the sudden traffic surge from 100100 to 50,00050,000 concurrent users in 55 minutes constitutes a flash traffic event. While the Application Load Balancer scales automatically, it cannot scale fast enough to prevent connection failures during such a rapid spike. Pre-warming the Application Load Balancer by contacting AWS Support ensures that the ALB has sufficient capacity provisioned beforehand, avoiding HTTP 504 errors and dropped connections.

Adım Adım Çözüm

1
Identify the database performance bottleneck.
The database bottleneck is caused by read-heavy queries reaching 100%100\% CPU utilization on the RDS primary instance.
To resolve this, we need to offload read queries to horizontal read replicas. RDS PostgreSQL supports read replicas, but migrating to Aurora PostgreSQL provides superior replication performance and native Auto Scaling for reader instances.
2
Address database read scaling and connection routing.
Migrate the database to Aurora PostgreSQL, configure reader instances with Aurora Auto Scaling, and update the application to use the reader endpoint.
This separates read and write traffic, ensuring that the primary database instance is not overwhelmed by the quarterly reporting queries.
3
Analyze the traffic pattern and network load balancing behavior.
A traffic spike from 100100 to 50,00050,000 concurrent users in 55 minutes is classified as a flash traffic event.
Standard Application Load Balancer auto-scaling is reactive and cannot scale up connection capacity rapidly enough to match this rate of increase, causing gateway timeouts.
4
Apply ALB capacity optimization.
Submit a request to AWS Support to pre-warm the Application Load Balancer before the reporting window starts.
Pre-warming provisions the necessary network and compute resources on the ALB in advance, allowing it to handle the immediate influx of connections without dropping requests.

Anahtar Kavram

Database read scaling via Aurora Replicas combined with Application Load Balancer pre-warming to mitigate flash traffic failures.
Tahmini Süre:3m 0s
Bu soruyu puanla