By using AWS re:Post, you agree to the Terms of Use

High-Traffic, Load-Balanced Wordpress Site - Optimal DevOps setup for deployment?

0

TLDR: I inherited a Wordpress site that I now manage that had a DevOps deployment pipeline that worked when the site was low to medium traffic, but now the site consistently gets high-traffic and I'm trying to improve the deployment pipeline.

The site I inherited uses Lightsail instances and a Lightsail load balancer in conjunction with one RDS database instance and an S3 bucket for hosted media. When I inherited the site, the deployment pipeline from the old developer was:

Scale site down to one instance, make changes to that one instance, once changes are complete, clone that updated instance as many times as you need

This worked fine when the site mostly ran with only one instance except during peak traffic times. However, now at all times we have 3-5 instances as even our "off-peak" traffic is really high requiring multiple instances.

I'd like to improve the deployment pipeline to allow for deployment during peak-traffic times without issues. I'm worried about updating multiples instances behind the load balancer one by one sequentially because we have Session Persistence disabled to allow for more evenly distributed load balancing. And I'm worried a user hopping to different instances that have a different functions.php file will cause issues.

Should I just enable session persistence when I want to make updates and sequentially updates instances behind the load balancer one by one? Or is there a better suited solution? Should I move to a containers setup? I'm admittedly a novice with AWS so any help is greatly appreciated. Really just looking for general advice and am confident I can figure out how to implement a suggested best-practice solution. Thanks!

  • Hi, @Invex09 Where and how is your DevOps pipeline built? Are you planning to destroy them all once?

  • @iwasa thanks for the reply, really not concerned about the transition from the old system to the new one. And the current system is insanely low-fi, probably not even worth calling "DevOps". We just have the whole site in a git repo and scaled down to one instance whenever we pull code changes into production/live. We have a staging environment for testing and going from local up through staging is fine. Its just pulling changes into production that's the issue because traffic is really too high where we shouldn't be scaling down to just one instance ever anymore. Because even for 5-10m, being scaled down to one instance spikes the CPU usage of that one instance to almost 100% very quickly

1 Answer
0

These docs provide info on best practices as it relates to using Wordpress on AWS, and I'd highly recommend you take a look: https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/welcome.html (I would ignore the reference architecture diagrams though, those are a bit overkill for your use case).

I would not use session persistence as you described (i.e. to direct traffic to instances with the newer software version during deployments), since session persistence is not designed to be used in that way. The more conventional approach is to take down a subset of your instances (for example, half of your instances), deploy the newer software version to those instances, and then bring them back up to handle traffic; then repeat the process for your remaining instances. This way, you'll be able to deploy your updates without significantly sacrificing availability (since multiple instances will always be available to handle traffic).

However, this means that at a certain point during the deployment, some of your instances will be serving traffic with the new code and some serving traffic with the old code, and for a brief period of time it's possible that requests may hit both old and new instances. You mentioned that this may cause issues; could you provide more detail? This may mean that the updates you're making to your software are not backwards- or forwards-compatible, and should be changed such that they are.

Instead of the manual process you've described to make changes to your webservers, I'd recommend taking advantage of CodePipeline/CodeDeploy to automate the deployment process. Here's a blog post with details on an example setup that uses CodePipeline/CodeDeploy to automatically deploy changes to a Lightsail instance whenever you push changes to a GitHub repo, and may be a good starting point: https://aws.amazon.com/blogs/compute/using-aws-codedeploy-and-aws-codepipeline-to-deploy-applications-to-amazon-lightsail.

Hope that helps!

answered 5 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions