Question

Difficulty: HardOptimizing Compute and Storage Performance

A geophysics research firm runs a seismic data processing pipeline on AWS. The pipeline consists of a fleet of Amazon EC2 instances in an Auto Scaling group (ASG) that ingest sensor telemetry logs, perform complex spatial transformations, write intermediate results to local scratch spaces, and update metadata in an Amazon RDS PostgreSQL DB instance. The processed datasets are ultimately uploaded to Amazon S3 for long-term research.

During daily calculation cycles, the solutions architect observes the following performance issues:
- The EC2 instances encounter severe disk write latency while writing intermediate sensor logs to local storage. The instances use Amazon EBS gp2 volumes, which frequently exhaust their I/O burst credits.
- The RDS PostgreSQL DB instance experiences high CPU utilization and query timeouts due to a sudden influx of read-heavy telemetry lookup queries.
- The final archive process to S3 fails with HTTP 503503 (Slow Down) errors when uploading thousands of small datasets concurrently to a single path: `s3://seismic-data-archive/raw-outputs/`.

Which two actions should the solutions architect take to resolve these performance bottlenecks? (Select two.)

  1. Upgrade the EC2 instance root and scratch volumes to gp3, configure them with sufficient provisioned IOPS and throughput, and modify the application to upload archives to S3 using key paths prepended with a hash of the sensor identifier.Answer
  2. Add RDS PostgreSQL Read Replicas to offload the read-heavy telemetry lookup queries from the primary database instance, and update the application's lookup queries to connect to the replica endpoints.Answer
  3. C
    Configure the RDS PostgreSQL DB instance for Multi-AZ deployment and configure the application to route read queries to the standby replica to balance the query load during peak calculation cycles.
  4. D
    Request that AWS Support pre-warm the application's entry-point load balancer to support the high rate of concurrent S3 PUT requests and eliminate the HTTP 503503 (Slow Down) responses.
  5. E
    Deploy an AWS Snowball Edge Storage Optimized device to locally cache the intermediate sensor logs and periodically ship the device to AWS to bypass S3 prefix constraints.

Answer

The correct actions are to upgrade the EC2 scratch volumes to gp3 with provisioned performance while prepending a partition hash to S3 archive paths, and to add RDS PostgreSQL Read Replicas to offload read-heavy lookup queries from the primary database.
Optimizing local storage write performance is achieved by migrating from gp2 to gp3 volumes, which allows provisioning specific IOPS and throughput values independently of capacity to eliminate I/O queuing. S3 write performance is optimized by prepending a hash to the S3 bucket paths. This distributes concurrent writes across multiple S3 partitions, bypassing the limit of 3,5003,500 write requests per second per prefix. Database read performance is scaled by adding RDS PostgreSQL Read Replicas and routing read-heavy queries to the replica endpoints, reducing CPU contention on the primary writer.

Step-by-Step Solution

1
Analyze local disk write latency on the EC2 nodes.
The EBS gp2 volumes are identified as exhausting their I/O burst credit bucket during calculation cycles.
EBS gp2 volumes scale performance based on size. Under high write loads, small or medium gp2 volumes deplete their burst credits, dropping performance to a low baseline and causing latency.
2
Optimize the local disk write performance and S3 upload throughput.
EBS volumes are upgraded to gp3 with customized IOPS and throughput. S3 upload key paths are modified to prepend a partition hash.
gp3 volumes allow provisioning performance parameters independently of size, guaranteeing consistent throughput. Introducing a hash prefix in S3 partitions writes across multiple prefixes, bypassing the 3,5003,500 write requests per second limit per prefix and resolving the HTTP 503503 errors.
3
Analyze RDS PostgreSQL DB high CPU utilization and query timeouts.
High CPU utilization is traced to read-heavy telemetry lookup queries hitting the primary writer database instance.
Mixing high-volume read traffic with transactional updates on the primary database instance exhausts CPU resources, leading to query delays and execution timeouts.
4
Deploy RDS PostgreSQL Read Replicas.
Read Replicas are created and the application configures read queries to use the replica endpoints.
Read Replicas asynchronously replicate data and remain active for read-only queries, freeing up the primary writer instance for transactional metadata updates.

Key Concept

Identifying storage performance limits (EBS gp2 vs gp3 and S3 prefix request limits) and scaling compute database queries horizontally via Read Replicas.
Estimated Time:3m 0s
Rate this question