(NewRelic diagram illustrating autoscaling from CodePen.IO)
In the past, companies would have to purchase 10 hardware servers, if at peak time 10 servers were needed to handle the traffic volume. For the rest of the day, the servers would sit idle. This is no longer needed. One big advantage of the cloud (like Amazon EC2) is elasticity, an ability to scale up and down the number of your server instances on the fly depending on the traffic load. In this article, I describe how you can automate spinning up instances when a CPU usage on your web servers exceeds 80%. I assume that you installed a typical EC2 Linux instance with a web server running on it (I used Ubuntu OS + installed Apache/MySql/PHP/Wordpress combo).
The steps to auto-scale your instance are as follows:
STEP 1. Preliminaries
Unless, your EC2 instance already contains Autoscaling command-line tool, you should download it: http://aws.amazon.com/developertools/2535 You can build the toolkit through the ./configure followed by make followed by make install incantations. Go to that directory and type.
Set up a new EC2 key + certificate and copy them to the directory. You can generate them in your management console http://aws.amazon.com/.
declare -x EC2_CERT="/home/ec2-user/AutoScaling-22.214.171.124/cert-amazon.pem"
declare -x EC2_PRIVATE_KEY="/home/ec2-user/AutoScaling-126.96.36.199/pk-amazon.pem"
STEP 2 Create a launch configuration
- Here, the input types are : image-id (AMI ID pointing to a disk image that you'd like to clone) and instance-type (which EC2 instance type you want to spawn); finally, you can reference an existing security key and security group when you create this instance.
as-create-launch-config alexLC --image-id ami-05355a6c --instance-type t1.micro --key alexkey --group AlexGroup
STEP 3 Create a group.
The key things you specify is minimum number of EC2 instances to launch upfront and maximum number. You also specify the availability zone in which to launch.
as-create-auto-scaling-group alexG --launch-configuration alexLC --availability-zones us-east-1d --min-size 2 --max-size 10
STEP 4 Policy
In this step, you specify how many instances at once do you launch, and what's the cool-down period (when no changes are made). The cool down is designed to prevent against sporadic traffic spikes.
Here, I scale up by 1 and wait 5 minutes to cool down.
as-put-scaling-policy --auto-scaling-group alexG --name scale-up --adjustment 1 --type ChangeInCapacity --cooldown 300
STEP 5 Trigger
Monday, August 26, 2013
8:33 PM Aleksandr Yampolskiy 1 comment
Finally you need to pair this up with Cloudwatch trigger to invoke the policy at an opportune moments.
The key input variables are
a) period of an event measured in seconds - here we require that a spike in CPU usage is observed for 60 seconds
b) number of evaluation periods (1 period only is enough for our purposes; again this is designed to prevent against sporadic traffic spikes resulting in instance launches)
c) threshold for CPU (70%). I highly recommend not to exceed 70% usage for production instances
d) reference to the policy URI identifier. This URI identifier will be emitted by command in step #4.
mon-put-metric-alarm --alarm-name sample-scale-up --alarm-description "Scale up at 70% load" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 60 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions InstanceId=i-8a3441ef --evaluation-periods 1 --unit Percent arn:aws:autoscaling:us-east-1:032853316404:scalingPolicy:0674edb1-6a2f-4ccb-9a66-3ec9c0d4cd72:autoScalingGroupName/alexG:policyName/scale-up
This is it! If you followed all the steps, correctly then you've created a policy and a trigger which will be fired when a CPU on a web server reaches 70%.
Option 1) One way to simulate a CPU spike is to launch a CPU-heavy activity like a clone of a large GIT/Mercurial repository.
yum install hg (install Mercurial)
hg clone http://xenbits.xensource.com/xen-unstable.hg (clone entire XEN VM repository - this will keep CPU at > 90% for minutes)
Option 2) Launch a simulated load test using Apache Benchmark, JMeter, Soasta, SIEGE or many other freely available tools.
For example, you could download SIEGE from http://www.joedog.org/siege-home/ and hammer your EC2 instance siege -c25 -t10M http://ec2-54-242-122-87.compute-1.amazonaws.com/