Scaling your Relational Database Service (RDS) Instance
Lately, I’ve had this question come up quite often, so I figured an article about the most common ways to scale RDS would be helpful.
My most preferred method of ‘scaling’ a Relation Database (RDS) instance is to offload as much as possible from the master instance. I’ve listed how I commonly do that in order of my preference.
Before making any decisions (or changes), please ensure that you have setup both the maintenance and backup windows using the most appropriate time. In the past, I have seen misconfiguration here affect performance. For example, AWS performs a backup of your RDS instance during business hours - probably not what you wanted to happen.
Read Replicas
Depending on your application there is usually an excellent opportunity to lessen the workload on the master database by creating one or more read replicas. The ability to use (and the number of) read replicas is dependent on your database engine, so this option may not be applicable. Make sure you review the overview of RDS Read Replicas and which engines support Read Replicas.
Using MySQL as an example, I can create up to a maximum of five Read Replicas per master database instance.
A couple of things to keep in mind when deciding if Read Replicas are the way to go. First, synchronization is asynchronous, so you will need to account for that, and you’ll need to update your application connection strings to point to the appropriate database instance.
A side benefit of using Read Replicas is their ability to be cross-region. So, if you’re looking to increase the availability and reliability of your database, then Read Replicas may also help in that department.
Caching
I ranked caching behind Read Replicas because you’re already caching right? Sure you are. For those of you aren’t, why not? Your goal should always be to deliver the best customer experience as you can and caching is a great way of doing that. By using AWS ElastiCache in your infrastructure, you’re able to serve requests via high-speed in-memory data stores rather than the slower disk-based systems used by RDS.
DynamoDB?
In many cases, over time we end up storing non-relational data in our relational databases. Examples of this include things like leaderboards, or maybe high scores. You may be able to lessen the workload on the master database by migrating some data to a NoSQL solution like DynamoDB. Remember, this option means that you’ll have to make changes to your application logic.
Provisioned IOPS Storage
Are you sure that the problem you’re having is related to a lack of resources - CPU or memory? You can use Cloudwatch to help identify the cause of the slugging performance of your RDS instance. If you discover that it’s a disk I/O related issue you could consider using Provisioned IOPS storage. PIOPS storage will allow you to specify exactly the amount of IOPS you require for your database.
A couple of things to keep in mind. First, Provisioned IOPS costs more, so make sure it’s needed before making any changes. Also, depending on the database engine you are using you may or may not be able to change storage types. Check the documentation to be sure.
One last thing, you seem a boost in disk performance by allocating more storage (General Purpose SSD). It may be worth a shot.
Vertical Scaling
As a last resort, you can always vertically scale your RDS instance. Selecting a larger instance means that you can throw more CPU and memory at the problem. Again, this would be my last choice.
Just a quick note to wrap up. As is the case with all AWS services, make sure that you review the latest documentation and service limits, before making any decisions on changes to your architecture.