Thursday, 12 October 2017

Wordpress AWS Part 1 - An Overview

Goal: To make a Wordpress site support 4000 concurrent connections using AWS

An overview of the things needed, and a brief explanation of how these AWS things work.

An overview of the AWS things needed

1. RDS
This is a MySQL / Aurora database. This is for the Wordpress database.
We need not install MySQL, etc. Amazon will ask us what we want to call our database. We get access to a database, not the database server that Amazon is running our database on. This is good because, if we need to make this database highly available / clustered, we just use click here and there, Amazon will handle the rest. No messing around with servers. We just use the database.

2. Elastic File System
An NFS folder for storing files that need to persist across EC2 instances' reboots. (This point will become clearer when I talk about the ephemeral nature of EC2 instances that are managed via Elastic Beanstalk.)
Again, we will not be actually be given a server. We merely get a "File System ID" and a FQDN, which is needed to make the EC2 instance connect to it.

3. EC2 instances (managed via Elastic Beanstalk)
The EC2 instance is the actual virtual machine that runs the Apache and executes the PHP scripts.
Elastic Beanstalk is the AWS thing that will spin up more EC2 instances when the load is high, and tear down EC2 instances when the load is low, according to thresholds we configure.

Important concept to note: EC2 instances that are managed by Elastic Beanstalk are ephemeral. That is to say, after an EC2 instance has been deployed and running, any changes made to it will be lost when it stops. That is why all changes made by Wordpress (for example, plugin installations, posts, image uploads) need to be stored in a database, and an NFS folder outside the EC2 instance itself.

How then do we upload those Wordpress PHP scripts into those ephemeral EC2 instances? Rsync? SCP? Answer: We do not upload anything into the EC2 instance itself.

In Elastic Beanstalk, we create an "Application", not EC2 instances. We then tell Elastic Beanstalk that our "application" is going to be run in an "environment" that has (for example) "t2.large" EC2 instances, minumum 2 instances, maximum 5 instances, spin up / tear down instances when whatever threshold is reached.

We then "deploy" the PHP scripts into our "environment".What actually happens in a "deploy":
i. We manually zip up all the PHP scripts into a single zip file first, in our own computer.

Manually zip up the files first...

ii. We then "deploy" our application, which actually uploads the zip file into some S3 location automatically created and managed by Elastic Beanstalk when we create the "application".

Deploy.

When Elastic Beanstalk creates the EC2 instances, it will take that zip file, and extract its contents into the the EC2 instances that it creates. And that is why we do not upload into the EC2 instance itself. There is no need to. When Beanstalk creates more EC2 instances, the PHP scripts will be there. When we need to make changes to the scripts, we create another zip file, "deploy" it, and all running EC2 instances will be updated as well.

Notice that Beanstalk can...
When load is high, create an EC2 instance and put in your scripts.
When load is low, destroy an EC2 instance (any changes made to that destroyed EC2 instance will be gone).
When load is high again, create an EC2 instance and put in your scripts.

Thus we see the ephemeral nature of EC2 instances managed via Elastic Beanstalk.

Wordpress is not designed to work in an environment like this. That is why we need an NFS folder to store all the uploaded images, plugins, etc. (There will be more details on how we going to accomplish this later.)

4. TCP Load Balancer
By default, when Elastic Beanstalk creates an environment, it also creates a load balancer for us. But that load balancer cannot sustain 4000 concurrent connections reliably (it is related to it being a HTTP load balancer). So, we will be creating a TCP load balancer (which in theory, can handle 20,000++ concurent connections, according to some screenshots I see from the Internet).

Part 1 - Overview
Part 2 - RDS
Part 3 - EFS
Part 4 - Key Pairs
Part 5 - Beanstalk
Part 6 - ebextensions Folder
Part 7 - Deploy Wordpress
Part 8 - 4000 Concurrent Connections