Soru

Zorluk: ZorCost-Optimized Database Design and Capacity Planning

A local events ticketing company is designing a booking system on AWS. The system receives booking confirmations that must be written to a database. The booking requests are highly spiky, reaching up to 5,0005,000 writes per second during the first 1515 minutes of a popular event launch. For the rest of the week, the booking rate is less than 1010 writes per second. The booking confirmations do not need to be processed in real-time but must be saved reliably within a few hours. The company wants to design a cost-optimized database tier. Which database design and capacity configuration is the most cost-effective?

  1. Deploy an Amazon SQS queue to buffer the incoming booking requests. Implement a fleet of consumer instances to retrieve the messages and write them to a smaller Amazon RDS database with General Purpose SSD (gp3) storage configured for the average write rate.Cevap
  2. B
    Configure an Amazon DynamoDB table in Provisioned capacity mode with Auto Scaling enabled, sizing the baseline capacity to 1010 write capacity units (WCUs) and the maximum capacity to 5,0005,000 WCUs.
  3. C
    Deploy an Amazon RDS for PostgreSQL database in a Multi-AZ configuration. Create three Read Replicas in different Availability Zones, and configure the application to distribute the write load across the standby instance and the Read Replicas during peak events.
  4. D
    Deploy an Amazon RDS for PostgreSQL database sized to handle the peak write load of 5,0005,000 writes per second, and purchase a Compute Savings Plan to reduce the hourly database instance costs.

Cevap

Deploying an Amazon SQS queue to buffer incoming booking requests and writing them to a smaller Amazon RDS database with gp3 storage configured for the average write rate.
Decoupling the database write workload using an Amazon SQS queue allows the application to ingest the peak traffic (5,0005,000 writes per second) immediately without throttling. The messages can then be processed asynchronously over a longer period, enabling the Amazon RDS database instance and its General Purpose SSD (gp3) storage to be provisioned for the average throughput (closer to the 1010 writes per second baseline) rather than the peak, resulting in significant cost savings.

Adım Adım Çözüm

1
Analyze the workload characteristics and requirements.
The workload has an extremely high peak (5,0005,000 writes/sec) for a very short duration (1515 minutes), with a very low baseline (1010 writes/sec). The processing is not time-critical (can be delayed by a few hours).
Understanding performance limits and SLA requirements determines whether synchronous scaling or asynchronous decoupling is appropriate.
2
Evaluate the cost of scaling database resources dynamically vs. decoupling.
Scaling a database (RDS or DynamoDB) to handle 5,0005,000 writes/sec is expensive and prone to throttling due to slow auto-scaling response times. Decoupling using an Amazon SQS queue allows buffering the load.
SQS is highly cost-effective for message ingestion and handles arbitrary spikes without throttling, enabling the downstream database to be sized for the average rate.
3
Assess the cost-optimization options for storage and purchasing models.
Using gp3 storage on a downsized RDS database provides a low-cost, independently scalable storage option. Compute Savings Plans cannot be used to discount RDS costs.
Correctly applying AWS billing concepts (Savings Plans scope) and storage types (gp3 vs io2) ensures maximum cost optimization.

Anahtar Kavram

Decoupling database writes with SQS to optimize database instance sizing and storage costs.
Tahmini Süre:2m 0s
Bu soruyu puanla