What Started It All - Oldschool WordPress Architecture

Learn about the cloud deployment that started my cloud computing hobby!

If you know me or have read some of my other posts, you have established that I quite love cloud computing. It is one of my biggest hobbies and it’s something I don’t mind sitting down and doing on the weekends to entertain myself. I thought I would look back to one of the first large scale architecture and deployments I did. It was this kind of stuff that really got my interests going and I think gave me the initial experience to get in the door of where I work today. At its core, this is a rather simple, distributed WordPress installation. Believe me, it definitely needs some improvements looking back. But for what it was back in the day several years ago, it definitely did its job and comfortably served an estimated 50,000 monthly visitors for close to a year and a half. I consider this quite impressive given some of the now obvious shortfalls that I see along with balancing the cost per month of the setup as there was not a whole lot of funds available

Compute

For Compute, I went with a T2.Medium instance that was the primary machine which ran 24/7/365 and did most of the work. It’s something to love about the T family of instances with their burstable CPU. The instance would accrue credits as normal and could comfortably burst in a traffic surge while auto scaling kicked in. As hinted by the previous setting, there was two Auto Scaling Groups involved with the backend. The first ASG, was responsible for that primary instance. It maintained the desired capacity of one and only kicked in if the instance ever failed, launching a replacement instance and terminating the existing one. The second ASG, was our primary scale out group. It was using M4.Large instances and would scale either with load on the primary instance or on a schedule. Given the nature of the website, traffic was quite predictable, so we could afford to plan a little bit. The evenings was when we would scale out to three M4.Large instances to really beef up capacity. Again, with cost saving, we were using Spot instances during these blocks, but I had monitoring in place on Spot pricing and we never really ran in to an issue with Spot. So much so I would consider it again today as at least one of the options for scale out with a large website.

Database

With the database, it’s WordPress so the engine of choice here is MySQL. If you’re unfamiliar with a distributed configuration of WordPress, you need a separate database in order to effectively scale your compute for requests. Else you’re just in for a bad time. In this scenario, I was using RDS and a db.t2.micro instance. This was in a single AZ configuration and again looking back, just screams nope for a production website of this size. There was the odd time where DB connections got exhausted, but that was handled by a quick restart. Fortunately, it worked but later on in this post, I’ll detail what I would do today if I had to do something like this again.

Storage

Storage was actually something I nearly completely forgot about when we were going live. Sure, I was aware of the local EBS volumes attached to the instances. But what I didn’t realise was when we were scaled out to 1+N instances, file uploads for say blog posts would only go to one of those instances, not all. So, we had an issue initially where sometimes a blog post would have its image and other times it wouldn’t, obviously with the load balancer picking a different backend instance that didn’t have the file upload. Fortunately, the solution was relatively simple. I just ended up syncing the uploaded files to an S3 bucket. Good thing with WordPress you can generally say “there’s a plugin for that!”. So, the plugin would handle the syncing of content and also rewriting the URL to be in the S3 format for the post. It was a very nice solution but like most things, this could very much be improved.

Networking

Networking and DNS is probably one of the relatively easiest bits with all of this. There were some quirks with DNS but when isn’t there quirks with DNS. Security groups ensured a pretty simple flow of the Application Load Balancer only being able to talk to the EC2 instances and the EC2 instances only being able to talk to the RDS database. The ALB was awesome since it also meant I could eventually support a little webstore that was asked of me along the same infrastructure footprint. DNS was handled by Route 53 and since I had the alias record to the ALB, there was no charge for the DNS queries to that ALB. Win!

What could have been done better?

Oh man so many things could have been done better…Let’s start with the basic, latest generation instances. So, our T2s become T3s and our M4s become M5s, etc. T3 Unlimited is quite nice all things considered, and I would definitely have it on. I would think any surplus credits used could get paid back by the passive regen of credits in off peak hours so any extra cost there would be minimum. I think as well, if I still was using a T3.Medium in this case, I could at least do two, T3.Smalls for equivalent resources and be running compute in two availability zones. Sure, it’s not all three, but two is better than one.

For the database, I could probably still stay in the T family and just bump up the instance size, while also enabling Multi-AZ just for that additional peace of mind. Honestly something I would have loved to try would have been Amazon Aurora MySQL edition with WordPress. The performance would be exceptionally interesting to see, if it is a big bump or just similar to what things were like before.

For storage, I know someone is probably thinking oh use Elastic File System (EFS) but I’ve yet to hear that this is good call. I think in the past WordPress would just exhaust the EFS share and you’d be left with rock bottom performance. Could be wrong there, but in my mind, I still have Avoid EFS with WordPress in there. The S3 bucket still works, but it could probably do a lot better if I had CloudFront in there too for some additional caching. Given the audience at the time was mostly Europe based, I could adjust the price class too.

Networking the only thing that comes to mind is what I ended my last point with, CloudFront. I just could never figure out what I should cache with CF and what should just have gotten passed through. I’m sure I could figure it out now, but yeah ultimately, I think more caching would have made things a lot smoother. Potentially using CloudFlare instead of CloudFront for the DDoS mitigation is an option there too.

In Conclusion

While I’m not rushing out to build my next distributed WordPress architecture, I do look back at this setup with pride, even with its flaws. It worked in more ways than one, in serving the website it needed to serve and was the gateway to my cloud computing hobby. Inevitably, the cloud computing hobby lead to my current job today and that definitely counts for something!