AWS Partner Network (APN) Blog
How to Deploy a High Availability Web Service on AWS Using Spotinst
Working as a solutions architect with AWS Partners, one of my many areas of focus is on reducing the cost of infrastructure for members of the AWS Partner Network. I review infrastructure design and methodologies in order to improve operational efficiencies with an emphasis on cost reduction. A part of that review identifies the optimal instance types and billing model for instances used by the partner.
We find that many partners are initially primarily using On-Demand Instances where they could benefit from the lower costs associated with Reserved Instances. There is another purchasing option that was previously targeted for short-lived or more flexible workloads: Amazon EC2 Spot Instances.
You can find a breakdown of these Amazon Elastic Compute Cloud (Amazon EC2) offerings from the Amazon EC2 Purchasing Options webpage.
Amazon EC2 Spot Instances
Spot Instances allow partners and customers to bid on spare Amazon EC2 computing capacity in order to reduce costs associated with Amazon EC2 On-Demand prices, without the commitment of purchasing Amazon EC2 Reserved Instances.
Spot Instances run for the length of time that you choose, as long as your bid price is greater than the current Spot price for a given Amazon EC2 Instance size, family, and specific Availability Zone within an AWS Region. Spot Instance prices fluctuate based upon Spot utilization, supply, and bid prices set by other partners and customers. In the event that the Spot price exceeds your bid price, your instance is terminated.
AWS provides customers and partners with tools to facilitate the management of Spot Instances including AWS Spot Bid Advisor along with Spot Fleet which is used to manage groups of Spot Instances and Spot Blocks which run Spot Instances on a defined time duration.
Introducing Spotinst
Spotinst is an AWS Partner who provides Spot Instance management and automated provisioning of Amazon EC2 instances within customer accounts. They are responsible for setting the optimal Spot bid price and identifying the most efficient instance type that provides the best performance for your application at the lowest price.
Spotinst identifies a recommended solution by assigning a score for each instance type, size, and operating system in each AWS Region. This score is calculated from three criteria:
- Price – Spotinst looks for Spot markets (Availability Zones or instance types) with fewer fluctuations in price in order to reduce the chance of sudden termination due to Spot market changes.
- Specifications – Spotinst sets scoring per CPU and GiB of RAM per instance type and tries to provision the most efficient results first.
- Performance – Spotinst identifies the application-specific performance results per instance type and provisions the instance types that generates greater performance for the specific Spotinst Elasticluster.
Spotinst has three different pricing models. The product is free for customers who have a single Spotinst Elastigroup, allowing for up to five instances and providing basic support. For larger implementations, Spotinst will charge a percentage (between 15% – 25%) of the savings provided by their platform. If your AWS bill would have been $100 for a month of use but you pay only $20 due to the efficiencies created with Spotinst, you would pay SpotInst between $12 and $20 (15% to 20% of your $80 cost savings).
This provides an incentive for Spotinst to provide the most efficient use of resources by AWS customers. For implementations larger than 50 Elastigroups and/or in excess of 500 instances, Spotinst provides enterprise custom pricing.
In our example today, we will be using the free offering from Spotinst. This demonstration will deploy a single Spotinst Elastigroup with a maximum of five instances. If you’re following along, be aware that you will be charged for the use of the Amazon EC2 instances along with the use of Elastic Load Balancing (ELB).
AWS Configuration
Our first step will be to create the ELB load balancer. You can download an AWS CloudFormation template that simplifies this process here.
Follow the instructions in the AWS CloudFormation documentation to create a stack with this template.
Once your AWS CloudFormation stack is running, choose the Outputs tab in the AWS CloudFormation service console. This tab lists useful information like the name of the AWS security group and the public DNS of the load balancer.
Configuring Spotinst
To use Spotinst, sign up for a new account at https://spotinst.com. Choose Join in the upper right to open the following registration form.
Follow the instructions to create an account. You can follow the on-screen wizard to complete the Spotinst initial configuration. Make sure to choose Amazon Web Services from the Cloud Provider list.
Once setup is complete, choose Elastigroups in the top menu on the dashboard.
Choose Create.
Enter a name associated with this group and the AWS Region you’d like to use, and then choose Next. In our example, I chose the name SpotInst-ASG-Spot and the US West (N. California) region.
You will now be asked to make some decisions on strategy and capacity. I used 60 seconds for connection draining, 1 as the target capacity, 1 as the minimum capacity, and set the maximum number of servers at 5. I left all other options at their default values.
When you’ve completed the fields, choose Next.
In the next segment, you can specify the details for the implementation. I chose my default AWS VPC ID under the VPC setting.
This example will demonstrate web server auto scaling using a Linux web server with a demonstration application. You should select multiple Availability Zones to ensure multiple AWS Spot pricing options as well as a high availability deployment.
We also choose an On-Demand Instance type, in case we need to use one. I chose m4.large, but you can choose an alternative.
Next, we want to identify the different instance types we are willing to use with our application. Spotinst will pursue the best decisions as to which of the selected instance types and Availability Zones to use to ensure that our application scales to meet demand at the lowest cost using variable AWS Spot pricing and On-Demand Instances.
We now scroll down to the Launch Specification section. Select the load balancer created earlier. Select a key pair as well as the security group we created. For the image, you will need to enter the Amazon Machine Image (AMI) ID for Amazon Linux, which is region-specific. To find the current AMI ID, follow the instructions in the Amazon EC2 documentation.
Finally, select the check box for Add Detailed Monitoring.
The next section of the screen allows you to enter user data, which will facilitate the configuration of the instances for deployment. Copy the following lines into the User Data text area, and then select Next:
#!/bin/bash
yum -y update
yum -y install httpd24 php56 php56-mbstring php56-mcrypt php56-mysqlnd php56-xml
chkconfig httpd on
/etc/init.d/httpd start
mkdir /var/tars
cd /var/tars
wget https://github.com/awslabs/aws-demo-php-simple-app/archive/master.zip
unzip master.zip
sed -i 's/loadGenUse = 0/loadGenUse = 1/g' aws-demo-php-simple-app-master/config.php
cp -a aws-demo-php-simple-app-master/* /var/www/html/
We must now identify the scaling policies used to decide when to add or remove instances. Under UP Scaling Policies, choose Add Policy. Click the plus sign next to Up Scaling Policy 1.
Fill out the information to specify that whenever the average of CPU utilization is greater than or equal to 50% for 2 consecutive periods of 1 minute, add one instance to the group, and then wait 60 seconds for the next scaling activity.
Now create the scaling down instructions in a similar fashion. Choose the Add Policy button below Down Scaling Policies, and then click the plus sign next to Down Scaling Policy 1.
Fill out the form to specify that whenever the average CPU utilization is less than or equal to 15% for 2 consecutive periods of 1 minute, remove a single instance, and then wait 120 seconds before making an additional scaling decision. When the form is complete, choose Next.
Spotinst now displays a JSON configuration of our infrastructure requirements. Review the configuration to ensure there are no issues, and then choose Create.
Once the first instance is initialized and running, you should be able to view the running demo application on the new Spotinst Elastigroup by opening the public DNS address of your ELB load balancer in a web browser.
Testing Auto Scaling with Spotinst
Now that we have our infrastructure defined and ready, we can test the auto scaling capabilities by running a load generator against the application we installed on each instance. This application was installed and enabled via the user data scripts defined earlier.
To test the scaling ability and to demonstrate the use of different Spot pricing and instance type utilization, we’ll need to drive load on the instances of the SpotInst Elastigroup in order to trigger scaling events. To generate traffic, you can use any Amazon EC2 load-testing utility. We’ll use a utility developed by the Chicago Tribune called Bees with Machine Guns!
Bees with Machine Guns
Bees with Machine Guns is not affiliated with AWS. Rather, I personally find this application fun as a powerful and scalable tool for traffic generation.
Please note this utility will create new Amazon EC2 instances to issue web requests for load testing. You’re responsible for charges associated with those new instances. Source code and instructions for the installation and use of the application can be found at https://github.com/newsapps/beeswithmachineguns.
After you install the utility, you can start up your swarm of bees (Amazon EC2 instances) by using the following command:
bees up –k <key name> -g <security group> -z <region>
where:
· <key name>
is the key pair name used for SSH authentication to instances.
· <security group>
is any AWS security group name that allows at least SSH access.
· <region>
is the AWS Region used for instance deployment. I used us-east-1a
in the example.
You can list your available bees with the bees report command.
You can now start the attack with the following command:
bees attack -n 50000 -c 100 -u http://<ELB DNS>/www/loadTest/
where <ELB DNS>
is the public DNS for the ELB load balancer you created earlier.
Spotinst Dashboard and Results
You can now observe the CPU load starting to build on the initial server through either the Spotinst dashboard or the Amazon CloudWatch console.
Once the scaling threshold we set earlier is triggered, Spotinst will begin to launch additional instances. You can view the status within the Spotinst console as well as the AWS Management Console. You should see a new instance launched every two minutes until the attack is complete.
Once complete, the load will drop and you will see instances removed at the rate of roughly one every four minutes.
You can view your cost and savings by looking at the dashboard specific to your Elastigroup as well as the overall dashboard.
Closing Out
Once you have completed this demonstration, you must delete the Spotinst Elastigroup from within the Spotinst console so you’re not billed for further instance use.
Additionally, you should also delete the ELB load balancer along with any other AWS resources created for this demonstration. If you used Bees with Machine Guns, make sure that your bees have all been shut down with the command:
bees down
Conclusion
As this example deployment demonstrates, there are cost-saving opportunities to using AWS Spot Instances. Using Spotinst, we were able to realize the cost benefit of AWS Spot Instances without the additional overhead associated with price management, and we were able to mitigate concerns regarding resource availability.
Spotinst is continually improving their deployment and pricing logic to the benefit of AWS customers, and this will continue to reduce Spotinst client costs. With their pricing model dependent upon cost savings of their customers, Spotinst have aligned themselves with the best interests of their clients.
To learn more about Spotinst, visit the company’s website here.