Problem Statement
WordPress is one of the most widely used platform on the internet. Its estimated that about 20% of the websites in the world use WordPress. In spite of the widespread usage, it’s a known fact that it’s hard to scale WordPress. The main reason being that it was designed for a single machine system and thus does not have build-in support for cloud like horizontal scaling capabilities.
Things get even more challenging when you try to deploy a highly scalable WordPress on cloud. The client had a WordPress instance running on a single machine in a datacenter. They wanted a highly scalable WordPress installation on AWS cloud for their future growth in traffic.
Business Objective
The client did not want to move away from WordPress platform.
Also, the had a lot of processes currently on WordPress to add and update the content. They didn’t want any new processes to be introduced in managing content.
Also, cost was a consideration, and the client did not want to add considerable costs to the existing setup
Technical Objectives
1. We wanted to go away from a single machine WordPress setup and go to horizontal scaling model
2. WordPress stores a lot of data locally on hard disks. We wanted all the data stored in a highly durable manner.
3. We wanted ability to auto-scale the infrastructure to reduce the cost
Architecture Diagram
Below is the design that was devised for the new WordPress instance.
We planned to create a stateless AMI for the WordPress Servers. As WordPress stores data locally, we made changes in WordPress code to store all the data to S3 instead of storing locally. Similarly, the code that did local reads in WordPress was changed to do reading from S3 instead. This code was then deployed to an EC2 instance. As WordPress depends on sessions, the sessions were stored in ElastiCache. This ElastiCache machine was used by all the EC2 instances to store and retrieve session information.
A golden AMI created out of the EC2 instance running this software. This AMI was used to launch more such EC2 instances with WordPress code and to setup auto-scaling.
The database was migrated to RDS with Multi-AZ setup for high availability. We also created a Read-Replica in another region for Disaster Recovery perspective (DR).
We created a VPC and public and private subnets. ELB was in public subnet and all the Web EC2 instances were in private Subnet. DB was in a separate private subnet. We had a NAT instance for the Web EC2 instance to talk to the internet. A bastion host was deployed to be able to ssh into the EC2 instances. CloudFront CDN was deployed to server the WordPress images, CSS, and java script files.
Below were the tasks that were required for setting us the AWS environment.
Below were the tasks required to move the WordPress instance from onsite to AWS.
Results
We were able to move the WordPress to AWS in a highly scalable manner, with almost zero downtime during migration. The client did a marketing campaign shortly after we deployed, and it resulted in 1000 request per second to the WordPress installation. Our WordPress on AWS was able to auto-scale and handle the load without any changes to the infrastructure and without any human intervention.
Also, all the processes they had to add and modify content did not need to change. As all the data was stored centrally in RDS or S3, any changes made in WordPress EC2 instance was reflected to all the WordPress EC2 instances.