1

I manage a website that is essentially just a news/blog powered by WordPress. Average users on the site is somewhere between 8-15. But we occasionally break news in our niche where we'll have anywhere from 1.5-5,000 people on. Up until today we were hosting the website on a VPS through Dreamhost. We moved to AWS/EC2 because I thought the scalability would be nice to have.

I backed up our entire server, started an EC2 instance (t2.micro running WordPress for AWS by Bitnami), created a storage drive for it, gave it an elastic IP, migrated and restored all our data (using UpdraftPlus). I was then happy the server was acting reasonable, took down our previous server, and created a DNS Record pointing to the IP for the AWS instance.

However, today we ran into an issue where the CPU was pegged at 100% utilization, with CPU Credits still available. I thought available CPU credits would scale the server so that it wasn't pegged at 100% usage. I guess I misunderstood. So I thought I needed to setup an auto-scaling group. So I created an AMI from the instance I already had setup, created a launch config, and created a load balancer. I then set the auto-scaling group to have 1 Desired, 1 Minimum, and 5 Maximum instances, to launch an instance if CPU => 85%, and to close one if CPU =< 35%.

I thought that would have been good, but I ran into an issue where once I set that up. It terminated the instance I setup earlier and took my entire website down. I then ran around in a panic until I realized it didn't delete the storage, and I launched another one and attached that drive.

Am I missing something here? How can I setup AWS/EC2 to handle a couple thousand users using the exact same data/website, and always have it up, not have it terminate my original instance?

Any help would be greatly appreciated.

1

2 Answers 2

0

A bit more reading on AWS and practicing outside of production would be a good idea. There are many guides, and AWS themselves provide great information, it's not difficult. You should really test in another VPC or region before you work on production sites.

t2.micro is limited to one core only regardless of CPU credits. Auto scaling takes time to kick in depending on alert / monitoring intervals. You can add existing instances to an elb, but I would tend to set it up, add them, then let it add its own instance(s) and stop the original.

An auto scaling group, "golden" AMI, and RDS would be the simple option. However you could end up with different Wordpress versions, so this requires more thought. You could set up caching at the web server level, Nginx is excellent and would reduce your load hugely - by at least an order of magnitude.

I have a tutorial that might be some use to you here. It doesn't go into autoscaling as I haven't needed that myself, but it's simple to set up - I've done it many times.

0

When you start working with Auto Scaling, you need to get used to a single fact: EC2 instances will launch and EC2 instances will terminate. Even with Min = Max = 1, your instance may terminate at any time and be replaced. Don't think of this as a bad thing, just get used to it and play along. In the long run, it's a very good thing.

To begin Auto Scaling, you need to move your database off your Auto Scaled instances. The data could be on another EC2 instance, or it can be on an RDS instance. It does not matter. But it should not be on the EC2 instances that are launching and terminating. There are two main reasons for this:

  • As previously mentioned, your single EC2 instance may be terminated and replaced, or
  • You may end up with 2 or more EC2 instances that require access to the same set of data.

Once you have your data off your EC2 instances, you'll setup a "master" EC2 instance. This "master" will be the EC2 instance that you SSH (or RDP) to update your WordPress site from a code/version perspective. It will be stopped for 99% of it's lifetime. It's sole purpose is to generate a new AMI image when you update your WordPress site's version or code. You:

  • start it
  • sign-in and update your site
  • stop the instance
  • create the AMI
  • update your Auto Scaling group with the new AMI
  • rolling-terminate your existing Auto Scaling EC2 instances, they will be replaced with fresh EC2 instances from your new AMI. Note that during this time, there may be EC2 instances running different versions of your site.

If you can, I would recommend the following:

  • Use multiple AZs for your Auto Scaling group, and
  • Have a minimum of 2 instances, not 1.

This way, you don't have a single EC2 instance that will take the entire site down if it goes down.

There are other ways of handling Auto Scaling, updates, etc. But for a beginner, the above framework is pretty easy to wrap your head around.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .