1. Use Auto-scaling
Auto-scaling is a unique feature of cloud computing and Amazon’s EC2 offering. Setup a load balancer and a couple of webservers for your application as you normally would. Design your webserver based on a template AMI that you’ll reuse over and over. Then setup auto-scaling and set thresholds based on the traffic you forecast. When a threshold is passed, AWS will spinup a new instance of your webserver, and roll it into the load balancer pool automatically. Once traffic falls below the scale back threshold, Amazon will take a server out of the pool for you.
Be sure to monitor this activity to start with, and also run some load and stress tests on it. You want to ensure that it behaves as you expect, and no anomalous cases will cause you to spinup servers unnecessarily.
2. Horizontally Scale the Database Tier
MySQL offers a number of solutions here. You can configure MySQL in a master-master active passive cluster, also known as circular replication. In this configuration, MySQL will send all completed transactions to the other server in the cluster. Your passive server can also handle read traffic for your application. At the same time as you achieve high availability, you also get scalability by sending much of the SELECT traffic off to another server.
As the load grows further, roll in an additional read-only slave into your setup. You can then further scale out reads. As you do this, you’ll continue to send all writes to the single active master database.
As an alternative, you may wish to employ Amazon’s RDS solution, which is based on the MySQL community server, but with certain locked in settings. In this configuration you will not be able to use an alternate MySQL distribution such as Percona’s high speed server. What this configuration does offer is multi-az configuration. Keep in mind though that any MySQL server you spinup will have a region and availability zone as part of it’s configuration, so you are always free to use those features of Amazon’s network to increase availability.
If the load on the single master database continues to be a problem, you can vertically scale that node in place. Do this by spinning up a new larger EC2 instance on and EBS root volume. Then detach that root volume, stop your old instance, detach it’s root volume and move it over to the new server. Once you attach that live root volume, your new larger EC2 instance will be your original server, scaled UP in place!
3. Use Striped EBS Volumes
EBS is a great technology, as it brings the flexibility of a storage area network to each of your EC2 instances. It’s not without it’s challenges though, and at times you will experience great variability in disk I/O throughput. This can pose a challenge for the database tier especially. Keep in mind too, that Amazon’s infrastructure virtualization layer will dial up or dial down the amount of disk I/O your instance receives based on how large the instance is.
One additional way to get better EBS performance is by using Linux’s software raid technology. Since EBS already has redundancy built in, you can simply use striping or RAID 0 across a number of EBS volumes – we recommend four.
Be careful with such configurations as each of your EBS volumes won’t operate by themselves now, but require all four to be complete. This will impact EBS snapshot backups, as well.