In Part I of our tutorial on WordPress in High Availability, we mentioned the possibility of placing a blog in a High Availability platform using Elastic Beanstalk. In this post we’ll explain how to achieve a High Availability platform and additionally, how to make it scale.
This tutorial details how to create an infrastructure similar to the one in the diagram below, where the front-end servers of the application switch on and off automatically with ease:
This platform contains a WordPress administration instance, on which code versions are managed with Git and to which changes to the servers are uploaded.
We’re continuing to update our tutorials to ensure you have the latest tricks and “how to’s” for AWS services. Now it’s the turn of high availability in WordPress. In the previous version of this tutorial, we looked at the different AWS methods and services for achieving high availability. Here in this updated version, we’ll focus on a specific solution: using GlusterFS to unify instance content.
Unfortunately, things fail from time to time, including our applications’ servers. A connectivity problem at the datacenter, a natural disaster or a hardware issue can render our blog offline. Since we cannot predict the future nor prevent failures from happening, we are leveraging the power of the cloud in order to save ourselves from them and keep our services working despite them: we’re designing our infrastructure with failure in mind so nothing fails.
It’s important that our platform isn’t dependant on any specific component in order to work or else service will be interrupted should that component fail. We have to identify our platform’s components and isolate them as much as possible: if our front web servers depend on some specific database server, then everything in our application depends on it and it becomes a dreadful single point of failure. On the other hand, if we design in a way in which we don’t depend on specific machines, we can have more than one of them serving each of our application’s layers and we won’t see any issues as a result of a single machine failing.
We already improved our WordPress performance and content loading speed using Elasticache in a previous tutorial. Now we’re going one step forward by locating those contents closer to our users in order to enhance response time even more by creating a Content Delivery Network using Amazon’s S3 and CloudFront services.
A Content Delivery Network is a fleet of servers distributed around the world which contain copies of our content. This way users visiting our site receive a response from the server closest to their location, decreasing data travel distance and intermediaries, resulting in faster access to the content. In order to enable our WordPress to take advantage of this, we’ll be making the following changes:
We’ll store our site’s images outside the web server that’s hosting WordPress, offloading any work related to image serving from our EC2 instances and allowing browsers to download them at the same time they download the text content. To do so, we’ll create an Amazon S3 bucket.
We’ll configure a CloudFront distribution that will cache our images from S3 to the edge locations Amazon has set up for us (see global infrastructure).
We’ll install a WordPress plugin that will handle the uploading of our pictures to S3 giving us a CloudFront link to them.