Examkin

Soru

Zorluk: Çok zorCost-Optimized Database Design and Capacity Planning

A company runs a core transactional retail application on AWS. The application database is deployed on Amazon RDS for PostgreSQL in a Multi-AZ configuration using a 2 TB2\text{ TB} `io2` storage volume provisioned at 30,00030,000 IOPS. Database metric analysis shows that during normal operations (2525 days of the month), the workload is steady, consuming an average of 3,0003,000 write IOPS and 2,0002,000 read IOPS. During a 55-day monthly flash sale event, read queries scale dramatically, requiring up to 28,00028,000 read IOPS, while write IOPS remain steady at 3,0003,000 IOPS. The system must maintain high availability with automatic failover at all times. Which database design modification is the most cost-effective solution to handle this workload?

  1. Migrate the database to Amazon Aurora PostgreSQL. Deploy a Multi-AZ cluster consisting of one writer instance and one reader instance. Configure Aurora Auto Scaling for the reader instances to dynamically scale out up to five reader instances during the flash sale events, and scale back down to a single reader instance afterwards.Cevap
  2. B
    Convert the Amazon RDS for PostgreSQL database to a Single-AZ deployment using `gp3` storage with 3,0003,000 provisioned IOPS to minimize baseline costs. Deploy an Amazon RDS Read Replica in a different Availability Zone to handle the read query spikes during flash sales, and configure custom scripts to promote this replica to the primary instance in the event of a failure.
  3. C
    Migrate the relational database schema and data to Amazon DynamoDB. Configure the DynamoDB table with Provisioned Capacity Mode and enable Auto Scaling. Set the minimum Read Capacity Units (RCUs) to 5,0005,000 and the maximum to 30,00030,000 to automatically handle the flash sale spikes while keeping costs low during normal operations.
  4. D
    Modify the existing Amazon RDS for PostgreSQL Multi-AZ deployment's storage type from `io2` to `gp3` and provision 30,00030,000 IOPS. Create an AWS Budgets alert to notify the operations team when costs exceed the baseline threshold, and manually scale the provisioned IOPS down to 5,0005,000 after each flash sale event ends.

Cevap

Migrate the database to Amazon Aurora PostgreSQL. Deploy a Multi-AZ cluster consisting of one writer instance and one reader instance. Configure Aurora Auto Scaling for the reader instances to dynamically scale out up to five reader instances during the flash sale events, and scale back down to a single reader instance afterwards.
Migrating the database to Amazon Aurora PostgreSQL with a Multi-AZ cluster consisting of one writer and one reader instance, and configuring Aurora Auto Scaling for the reader instances, is the most cost-effective solution. Since Aurora's storage architecture automatically scales performance and storage space without requiring provisioned IOPS, the company avoids the high cost of provisioned `io2` storage. Because the flash sale spikes are read-heavy, Aurora Auto Scaling can dynamically provision additional reader instances to handle the 28,00028,000 read IOPS and scale them down when the event ends, aligning instance capacity and cost with actual demand while maintaining full Multi-AZ high availability.

Adım Adım Çözüm

1
Analyze the workload characteristics and requirements
The database requires high availability (Multi-AZ) and automatic failover. The workload is highly read-heavy (90%90\% reads) with a predictable 55-day spike of 28,00028,000 read IOPS, while the remaining 2525 days require only 3,0003,000 write IOPS and 2,0002,000 read IOPS.
Understanding the ratio of reads to writes and the predictability of the spikes allows for target capacity scaling of the correct database tier.
2
Evaluate storage and database options for handling IOPS dynamically
Amazon RDS PostgreSQL requires provisioning storage volumes like `io2` to guarantee high IOPS, which must be paid for 24/7. Amazon Aurora PostgreSQL decouples compute from storage; its storage auto-scales performance dynamically without provisioning IOPS. Furthermore, Aurora supports native Auto Scaling of reader instances to handle read-heavy spikes.
Comparing RDS and Aurora storage cost models identifies that Aurora eliminates the need to provision expensive `io2` storage for peak capacity.
3
Select the most cost-effective capacity scaling strategy
By deploying a baseline Aurora PostgreSQL Multi-AZ cluster (one writer, one reader) and enabling Auto Scaling for readers, the system automatically scales out reader instances to absorb the 28,00028,000 read IOPS during the 55-day flash sale. The instances scale back down to one reader for the other 2525 days, minimizing compute costs.
Aligning instance capacity with the database query patterns minimizes both compute and storage costs while maintaining the high availability SLA.

Anahtar Kavram

Cost-optimized database capacity planning leverages Aurora's decoupled storage and Auto Scaling read replicas to handle periodic read-heavy spikes, avoiding the high cost of provisioned database storage.
Bu soruyu puanla

Konular

Cost-Optimized Database Design and Capacity Planning