How to deploy highly available and scalable wordpress with RDS on AWS
WordPress is a popular Content Management Systems (CMS) that is used by many. In fact recent studies show that WordPress powers about 25% of all websites on the Internet. This blog is on howto deploy a highly available and scalable wordpress with RDS on AWS. It will help anyone intending to migrate an existing WordPress or build a 2-tier topology that is highly available, redundant and scalable WordPress site on the AWS platform, using the diagram below.
As always, be sure to use AWS cost calculator to have an idea of the estimated cost of the topology though if you are within the AWS free tier, you will almost be fine without paying anything to test this out.
First things first, WordPress can be easily deployed on a single EC2 instance and in fact as small as a t2.micro instance is often sufficient for a basic install. However, this does not create a highly available and scalable wordpress with RDS on AWS. In a basic setup, both the WordPress and mysql database are installed on a single instance but for scalable WordPress, wordpress and the mysql database must be installed on separate virtual instances. The 2-tier topology used for this tutorial is shown in the above diagram. The emphasis on making sure that both wordpress and the database are on different virtual instances is important because you will be using ELB with Austoscaling, as indicated in the diagram. For autoscaling, its important that the web instances do not maintain individuals states. In other words, you want stateless wordpress instances connected to a centralized stateful database. In this way, all the stateless instances have access to the same database backend. This is the right way to build a highly available WordPress. Autoscaling will not work properly if the DB resides on the same virtual instances as wordpress.
A key part of this design are ELB and Auto scaling. These are the services that creates a highly available and scalable wordpress with RDS on AWS.
In the words of AWS: Elastic Load Balancing(ELB) automatically distributes incoming application traffic across multiple Amazon EC2 instances. It enables you to achieve fault tolerance in your applications, seamlessly providing the required amount of load balancing capacity needed to route application traffic.
In other words, ELB enables you to create a single front-end access to a pool of virtual instances. This is useful for the performance of the web application residing on the virtual instances. For example, if one virtual instance can handle traffic of say 200 concurrent connections, 5 servers of the same capacity can potentially handle concurrent connections of 1000 when load is distributed across all the virtual servers. This feature is desirable in modern web applications since web applications are designed for horizontal scalability rather than vertical scalability.
On Auto scaling, AWS has the following to say: Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define. You can use Auto Scaling to help ensure that you are running your desired number of Amazon EC2 instances. Auto Scaling can also automatically increase the number of Amazon EC2 instances during demand spikes to maintain performance and decrease capacity during lulls to reduce costs. Auto Scaling is well suited both to applications that have stable demand patterns or that experience hourly, daily, or weekly variability in usage.
Austocaling uses Cloudwatch alarms to continuously monitor the load of the instances and can trigger policies to either scale up or down the required number of virtual instances. The Cloudwatch metrics that are often used for auto-scaling are cpu_utilization and memory_utilzation. This architecture is cost effective as you don’t have to second guess the required workload since Autoscaling will handle that automatically.
This is a multi-path blog that will take you through all the stages of the implementation to realize the above topology. While this first part explains the architecture, in the next blog, we will look at the practical steps in implementing the Scalable WordPress topology above.
The workflow of the topology in deploying a highly available and scalable wordpress with RDS on AWS is as follows:
The Internet users contact the web URL (e.g example.com) which points to the ELB public URL that is automatically generated when you create an ELB. The web to ELB URL can be resolved by Route 53 or by a DNS server outside of AWS e.g. the DNS server of your web host. If hosted outside AWS by a web host, you will need to create 2 entries:
- Use redirect feature to redirect from example.com to www.example.com
- Create a CNAME record to point www to the ELB public URL
The ELB will attempt to contact the available instances, which are hosted inside a VPC, for greater security. Before the instances can be reached, both:
- The network ACL and
- The security groups must allow this to happen
Note that the role of Auto Scaling is to increase or decrease the workload as required. After the increase or decrease of the instances, the ELB is notified to increase or decrease the pool of virtual instances accordingly. Instances controlled by AS can spread across 2 or more AZ for fail-over and redundancy. This implies that the ELB is able to see instances across different AZ within the same Region. Security groups are visible within the same region and only needs to be created once–for example, the web security group will be used across all the available AZs. The network ACLs exists per every subnet created.
Once the web server is contacted, it will need to contact the backend DB, hosted by Relational and Database Service (RDS). The major difference between the web and the DB tier is that the DB tier does not require an ELB. To provide redundancy, the RDS is created in a master/slave configuration where RDS ensures that both the master and the slaves are hosted in different AZ to provide fail-over and redundancy.
Here, you are using RDS which relieves you the responsibility of systems administration tasks of the DB tier. Tasks such as patch install, DB backup, scaling, etc are performed by AWS. You will just have to login to the DB and manage your DB configurations by yourself while AWS takes care of the DB heavy lifting. You have the option to install your own DB of choice on a separate instance and manage it yourself though not recommended by AWS.
One thing to note with this setup is that AWS gives you a public DNS URL of your ELB but not the IP address and in fact you may never have access to the IP address of your ELB because it changes from time to time. Technically, a changing IP address is not a very good thing for SEO and since you are building a wordpress site, this could be a point of concern. However, Google had addressed this in a chat forum long time ago as posted below, verbatim, and I believe it is still the case that ELB will not affect your site’s ELB ranking.
There are many reasons why a site might change IP addresses from time to time, and that’s fine with us. We don’t automatically assume that they’re doing shady things 🙂
The main issue that can sometimes arise is that Googlebot might take a bit of time to figure out how fast to crawl your pages. If the IP address changes regularly (say outside of a small set of IP addresses), that could look like your site is moving servers each time. In cases like that, we may crawl a bit more conservatively than if we’ve figured out that your server is sturdy enough to be crawled at higher rates. That also depends on how your website is set up, and if there’s really content there that would need to be crawled at such a rate (eg if this is for a blog that’s mostly static with a few hundred pages, then the crawl rate will not be that important, at least compared to a large news publisher that publishes hundreds of new articles a day).
If you should see issues with regards to the crawl rate not being as high as you would need it, I’d recommend submitting feedback in Webmaster Tools (Settings / Crawl Rate / Learn More / Report a problem with Googlebot). The team regularly reviews that feedback, and will generally be able to tweak the crawl rate accordingly.
Hope it helps!John
This concludes part-1 on highly available and scalable wordpress with RDS on AWS. Next is part-2 in the next blog.