Scaling Out: WordPress and Amazon’s Relational Database Service (RDS)

In my next few posts, I’m going to talk about scaling WordPress to crazy huge levels using various services. Chances are you could replace WordPress with any other CMS (Drupal, Joomla, etc) or custom framework/application.

Like most “modern” content management systems, WordPress relies on a MySQL Database to store content. In most cases, this database is rather small. Only text like Posts, Pages, Custom Post Types, and general settings are stored in this database. Images and other files are stored on the server by default. As sites grow, so does the content and, consequently, so does the number of queries to the database. MySQL is a very resilient system, but like most things, there is a point when it can’t get any bigger, faster, or safer.

So, what do you do when you’re reaching the limits of your MySQL database? Amazon has a service called the Relational Database Service (RDS). In a nutshell, RDS is a:

“…web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizable capacity for an industry-standard relational database and manages common database administration tasks.” More information on RDS is available on the AWS website.

Here is how to start a new WordPress site using RDS.

Before we begin, this is really only going to help you if you’re site is getting +10,000 hits a day! This is overkill for 99% of websites.

1. Login to the AWS Management Console. Select RDS and “Launch Instance”. We’ll select “MySQL”.
   
2. Here, we’re going to select some standard settings. I recommend using the default version of MySQL (unless you have a good reason not to). Important things to note, I’ve selected “Yes” to “Multi-AZ Deployment”. Multi Availability Zone mean Amazon creates an exact copy of your database (which is always in sync) and puts it in a different zone. If something happens to the AWS datacenter this database is hosted in (or your database needs to go down for maintenance), it will failover to the Multi-AZ backup. This setting is an additional fee.
   
3. Here we need to select the name of the database, the connection port, and the security group.
   
4. Next are the backup settings. I left these at the defaults.
   
5. Finally, we get to the review page. Double check to make sure everything looks in order. Then click “Launch DB Instance”
   
6. It takes a while for the database to become usable (Mine took about 15min). While it’s starting up, there are a few more things you need to do. First, you’ll want to find the “endpoint” address **. We’ll point our install of WordPress to this address. (*Important note: for this example we will only have 1 node in our cluster. If you’re planning to have several nodes in the cluster, you’re going to want to use route 53 to create your own endpoint address);
   
7. Next we need to allow the webserver’s IP. I’m hosting this site from 3rd party, so I know what my static IP is. If your webserver is running on an EC2 instance, you can connect it directly (see the dropdown).
   
8. Once the database is up and running, we can install WordPress. The Database Name, User Name, and Password come from step 2 and 3. The database host is the “endpoint” from step 6.
   

Hurray! You are up and running.

Additional recommendations: Having a database that is not on the same server as the webserver can make your site pretty slow. I recommend installing W3 Total Cache if you are running WordPress with a setup like this.