Question

I have a basic PHP / MySQL website stored entirely on an Amazon EC2 micro instance. Traffic is about to increase for a temporary period, and I would like to implement basic auto-scaling mainly to give me more CPU power since that seems to be the bottleneck. So the main constraints I know I have are:

  • Preserve MySQL database data
  • Preserve website files (which are at /var/www/* )

Can anyone point to the best way to do this?

P.S. Because my server setup is not that complex, I am willing to rebuild / re-upload all of it if I have to.. I just need to get the Auto Scaling in place correctly.

Was it helpful?

Solution

I had a similar problem and here's what I did.

Prepare the App server to be auto-scalable (able to run on multiple instances simultaneously):

  • I moved my SQL databases (MySQL and MSSQL) to RDS;
  • I modified my program so it does not write to the local volumes/drives and instead put all the files in an S3 bucket;

I tested this instance to make sure my app-server is totally separate from my DB and other write Storage. When it's all set:

  • pushed all my changes to a repository;
  • scheduled a task that will run when my server starts (and every 2 hours after) that will do a git pull origin master from the repository (to make sure the code on the new instances will always be the latest);
  • created a custom AMI of this Instance;
  • created a Load Balancer;
  • created a Launch configuration/Auto-scaler group that uses the AMI I created;

Now that the Auto-scaler is all set:

  • I changed the DNS entry pointing to my site to use a DNS CNAME pointing to the Load-Balancer end-point (DNS name) instead of the elastic IP I originally associated to my EC2 instance (from where we created the AMI and did the testing);

Take note: DON'T use the static IP address assigned to your Load Balancer because they will change very frequently. You really need to setup a CNAME pointing to the Load-Balancer end-point.

Some maintenance that I needed to do:

  • I cloned a copy of the repository to a local copy where I do the testing and updates. When I need to change anything on the production server, I simply push my changes to the repository and my production server picks-them-up every 2 hours.
  • When there's already too much updates on my code from the last time I created the AMI, I recreate the AMI to reduce the amount of time needed to pull from the repository.

And BTW, I'm using T1.micro instance. That's the whole idea of using Auto-scaling in the first place. We don't want to be spending on a Medium server all the time our app is on a slack.

OTHER TIPS

Caveats:

As the previous answer mentioned, you should NOT be using t1.micro instances for any production instances.

  1. As the previous answer mentioned, you should NOT be using t1.micro instances for any production instances
  2. You can't (easily) autoscale EC2 instances that are running MySQL. If you just think about it, if you have multiple DBs popping up, data would not be synchronized and it would a mess. The easiest way to do this is to use RDS and add read-replicas as you need.

Now to create a web autoscaling instance (assuming you've moved your DB to RDS) there are a few steps on the AWS side, and a few steps on your side with regards to code/deployment management.

Autoscaling involves:

  1. Creating an AMI of your current EC2 instance. With an EBS-backed instance, the data/volumes will be wrapped up with the AMI and will be deployed when you deploy this AMI. However if you've made changes to your code then obviously this code won't be up to date, we'll cover that below.
  2. Create an autoscaling launch configuration - you can do that via GUI now on the AWS console, although I'm still a fan of the CLI. The launch config specifies the AMI to use, instance sizes, etc.
  3. Create an autoscaling group and apply the launch configuration to it. When you create an autoscaling group you'll want to specify an ELB to add the instances to otherwise they won't be accessible. If you're using a roll-your-own load balancer then make sure that the instance registers itself to that when it launches (using cloud-init or something).
  4. Create Cloudwatch alarms for scale-up and scale-down actions - this can be tied to CPU, Network I/O, etc. You'll need at least 2 alarms (one for scale-up, one for scale-down).

Now once the instance is up, you'll have your web server, but it will be running old code:

  1. Assuming you're versioning your code on git, create a git deployment key and add it to the server.
  2. Use cloud-init to trigger a git pull - cloud-init code will only run once so it will make sure your server launches and runs with your latest code.

You're done! The instructions above are pretty high level. Going into step-by-step detail would entail a much longer response, but happy to provide explanation on steps where needed, let me know!

First of all, if you are wanting to run any sort of site on EC2, you should not be using micro instances. You should certainly not be using micro instance in conjunction with autoscaling. The good news is that since your micro instance is on EBS-backed volume you can just take a snapshot of that volume to S3 and use that as the basis for any number of EBS-backed instances.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top