Scalable WordPress with AWS Elastic File System (EFS) and RDS

In a previous post, we performed a test drive and benchmarking of AWS Elastic File System (EFS).  This time round, we put it to practical use by using it as a shared content tier for a scalable WordPress installation.

It’s quite common to launch a WordPress website within a single box and then expose the web front end to the internet. As the business grows however, the single box may reach capacity. It is also a single point of failure.

Most business websites can be broken down into three logical tiers:

  • Presentation :- The front end web server or reverse proxy
  • Application (Content) : – The core application or “middleware” tier
  • Database :- The backend database

It is best security practice to separate out these tiers into subnets with distinct security groups

However, the AWS best practice is taking advantage of multi-tier architecture. Since the new Elastic File System (EFS) is very cost effective, using multi-tier architecture with EFS as content storage probably will become a popular stack after EFS coming to Asia-Pacific region.

So, in this experiment, we decoupled a WordPress single box and transformed it into a robust multi-tier structure that includes EFS service. Then we carried out some regular tests to make sure the site is fully functional.

The WordPress Single Box

To start with, we use a snapshot of a typical production WordPress all-in-one-box website. The following graph illustrates the skeleton of main services inside this box.   As a regular WordPress site, it includes Apache, Content Directory and MySQL database. The Web Application Firewall is running in the same box for blocking suspicious user activities.

 

wp-in-onebox

 

Transforming

The diagram below shows the desired Multi-Tier structure after transforming.

AWS-multi-tier-WP-network-diagram

Ideally, we detach each module from the single box and then replace it with corresponding AWS service. The only exception in this test is the WAF as it is a very light weight service. We keep this service inside the box as it can scale up and down, as a part of the Web Host servers, by the Auto Scaling Group.

Firstly, we make an AMI from the snapshot of a typical production WordPress all-in-one-box site, then launch an instance with the AMI we just made on the DMZ subnet with a public IP. After it is up and running, we verified its functionality to make sure it is identical to the production site.

Then we move the WordPress content directory to EFS, and mount the EFS volume back to the content directory original path, for instance, /var/www/html. Depending on the size of your content folder, it may take a while to finish the copying, for example, 10mins for the size of 220MB. This is due to the W/R speed of EFS service as it is still in preview and the AWS guy is still tuning it. We have a detailed test on this issue in previous blog.

After confirm the site is still working good with EFS hosting the content directory, we can then dump the local MySQL server, import the dumped data to the RDS MySQL instance we launched with exact same details with genuine local database. Following the database migration, we stopped the local MySQL server and verified the site is still fully functional.

After database migration, content folder redirecting and making sure the EFS mounting setup is activated in /etc/fstab file, the current running instance is exported to a new AMI. For the convenience of expression, we name this AMI Web-Hosting-AMI.

Till now, the major decoupling process has been finished. The rest is only setup an auto scaling group with a launch configuration that using Web-Hosting-AMI on Web Application subnet and assigned to the internet facing ELB.

The Outcomes

As we expected, the site works well on the new multi-tier stack. However, please be wise in choosing the instance size on both EC2 instances and RDS.  Since multiple modules have been taken off from the initial single box, the Web Hosting instance can be smaller in the Launch Configuration. In regards to the RDS, it is one of the key components that effects site response time, so select one that suits the site’s workload.

After the transformation, we have a scalable WordPress solution with no single points of failure.