You are doing a load testing exercise on your application hosted on AWS. While testing your Amazon RDS MySQL DB
instance, you notice that when you hit 100% CPU utilization on it, your application becomes non- responsive. Your
application is read-heavy. What are methods to scale your data tier to meet the application’s needs? (Choose three.)
A.
Add Amazon RDS DB read replicas, and have your application direct read queries to them.
B.
Add your Amazon RDS DB instance to an Auto Scaling group and configure your CloudWatch metric based on CPU utilization.
C.
Use an Amazon SQS queue to throttle data going to the Amazon RDS DB instance.
D.
Use ElastiCache in front of your Amazon RDS DB to cache common queries.
E.
Shard your data set among multiple Amazon RDS DB instances.
F.
Enable Multi-AZ for your Amazon RDS DB instance.
I would say A,C,E.
The question explicitly states that the application is read-heavy. Sharding is a technique to scale write transactions. For read transactions you should use read-replicas which is already given in options A.
Although SQS cannot directly be used to throttle traffic, but it can be used to queue jobs for processing when DB becomes temporarily over-utilized.
A, d, e for sure
B. Cannot add asg for rds
C. Use sqs for write, not read
F. Multi AZ just for HA
C cannot be the answer because SQS would be useful in case of write operations rather than read.
A,D,E
A & D definitely. I’m doubtful b/w C & E as both seems fine. However, SQS usually works well with DynamoDB instead of RDS which makes me think that E can be the better choice
RDS is a relational database system and talks about atomic consistency in online transactional processing (OLTP) systems. SQS works in a manner of asynchronous processing to decouple and scale the running components. Using SQS with RDS will be very difficult keeping records as atomic consistency.
A, D & E seems fine
How?
A,D,E
A,D,E
B – AS for RDS not supported yet.
A – Read replica
D – Cache
E – Shard
Correct Answer : A , D , E