Let’s start off with saying that horizontally scaling a wordpress website is very easy to do but is kinda expensive. I’d say it’s about $100+ a month to leave this infra consistently standing in AWS. Most of the cost is in the DB and EC2 instances. So, beware of forgetting about infra you stand up during this tutorial.
Scaling
Scaling. What is scaling? Scaling is planning for the growth of a piece of technology or system. This can be traffic to your website like in this blog post’s case but you can use it to describe increasing the throughput of a workflow. Scaling is prepping for a typically better tomorrow.
In the best cases this doesn’t involve heavy investment. This isn’t always avoidable in the real world but software is a special case. In the best cases, a single person tippity-tap-tapping away on their keyboard can create a system that scales to millions or billions of users and not inccur massive inital capital expenditures if their idea doesn’t immediately take off. Your idea sucking? Atleast you didn’t have to buy a massive manufacturing plant, land, etc.
So when your application has a small amount of traffic, you want to only pay for enough infrastructure for a few folks buuut if your idea takes off then your system can flex to handle the additional traffic.
The Plan
The image above is essentially what we’ll build. We’ll be using AWS to deploy our infra. Conceptually it’s identical across all the cloud providers but we’ll be leveraging AWS CloudFormation to get the meaty part of our infra going. This post is AWS specific.
Requirements
Load Balancer
So what is and why do you need a load balancer? Load balancers are pretty self explanatory. They distribute the….. load. Load is the traffic that your “website” gets. 100 people go to https://feralcat.xyz. Once my infra begins to deteriorate because of the amount of traffic hitting my single instance, a new instance gets deployed in 20ish seconds and new folks get routed to the new and identical server. The load balancer isn’t handling the duplication, it’s just handling the distribution. Now my 101 user unknowingly gets routed to a second EC2 instance that’s indestinguishable from the first.
EC2
EC2 instances are where your actual application is deployed. In our case it’s WordPress which is an open source application writen in PHP developed by the community. Digital Ocean calls these droplets but you can just think of them as your own personal server. Each personal server can only take so much. Kind of like how your own computer starts tripping out after you open enough chrome tabs. In this hypothetical, we’d just get a second computer to deal with the new tabs. Same concept as why you spin up new instances as the load increases.
MySQL DB – RDS
Your database is your applications life and blood. Without it, your application would just be a bunch of photos and some colors maaaaybe. All your articles will live in the database. I’m using an AWS RDS instance which can be made scalable and multi region which increases the speed and reliability of your data.
There’s more nuance that get’s handled primarily by a cloud formation template like ingress access, egress access, security groups, etc. My current setup limits the max instances to 5 in case something wild happens and has a minimum instance count of one for those late nights my blog is nice and quiet. The value here is in the face that the number of instances is dynamic. Website traffic can vary wildly. You can go viral with some random tweet and get 24 hours worth of traffic which requires 5 instances or more but then that might die off shortly there after so you don’t want to incur the costs for all that server space.
Conclusion
So, those are the major parts of our system. There are a couple others that are much less blatant like your VPC, auto scaling group, etc. We’ll go deeper into horizontally scaling a wordpress website in the next blog post. We’ll try to keep it short this time to make these easier to consume.