Reverted edits by Galactic Radiance (Talk); changed back to last version by Vipul Naik
| ←Older revision | Revision as of 17:13, 25 June 2016 | ||
| Line 38: | Line 38: | ||
# Note that some types of instances are not available on the spot market. In particular, the t2.micro instance, a small instance type that is ideal if you just want an instance for basic testing, is not available as a spot instance. However, this instance is available for free in the AWS Free Tier. | # Note that some types of instances are not available on the spot market. In particular, the t2.micro instance, a small instance type that is ideal if you just want an instance for basic testing, is not available as a spot instance. However, this instance is available for free in the AWS Free Tier. | ||
=== Understanding Bidding Strategies === | === Understanding Bidding Strategies === | ||
| − | # Understand the key trade-off in bidding strategies. | + | # Understand the key trade-off in bidding strategies.[[Image:Spot price spikes brief and persistent.png|thumb|Spot price spikes in U.S. East over a week. Some spikes are brief, while others persist for a day]] |
#* Higher bids insulate you against interruption of your instances, and reduce the pressure on you to develop better interruption management strategies. | #* Higher bids insulate you against interruption of your instances, and reduce the pressure on you to develop better interruption management strategies. | ||
#* Lower bids help you cap the maximum amount you are willing to pay for instances, thereby providing a better upper bound on your instance costs. | #* Lower bids help you cap the maximum amount you are willing to pay for instances, thereby providing a better upper bound on your instance costs. | ||
| − | #* If all price spikes were brief, then high bids would be the better strategy, because the high bid would help you survive the price spike without having to pay more on average | + | #* If all price spikes were brief, then high bids would be the better strategy, because the high bid would help you survive the price spike without having to pay more on average. In fact, if the spike is very brief, you may not have to pay anything at all because you only pay the price that is charged at the completion of an integer number of hours after your spot request is fulfilled. |
| − | + | #* If, on the other hand, price spikes generally tended to persist, it would make sense to bid only as high as you are willing to pay for persistently#* In practice, the situation is mixed: most price spikes are brief, but sometimes price spikes can last several hours. This is what makes it hard to come up with an optimal bidding strategy. | |
| − | #* In practice, the situation is mixed: most price spikes are brief, but sometimes price spikes can last several hours. This is what makes it hard to come up with an optimal bidding strategy. | + | |
#* What you would ideally like to do is describe your bid not just in terms of the maximum price you will pay, but also in terms of how long you will be willing to keep a bid at the maximum price. This can help get the best of both worlds: bid high enough that your instances aren't interrupted, but if the price actually stays that high for a nontrivial length of time, then gracefully save your work, terminate the instance, and transition to a different way of executing the workload. Unfortunately, Amazon does not itself support such strategies, so you will need to use the API to write code to execute this sort of strategy, or use a third-party service that handles graceful workload transitioning. | #* What you would ideally like to do is describe your bid not just in terms of the maximum price you will pay, but also in terms of how long you will be willing to keep a bid at the maximum price. This can help get the best of both worlds: bid high enough that your instances aren't interrupted, but if the price actually stays that high for a nontrivial length of time, then gracefully save your work, terminate the instance, and transition to a different way of executing the workload. Unfortunately, Amazon does not itself support such strategies, so you will need to use the API to write code to execute this sort of strategy, or use a third-party service that handles graceful workload transitioning. | ||
# Understand the different types of bidding strategies. Amazon defines four types of bidding strategies.<ref>[https://aws.amazon.com/ec2/spot/spot-tutorials/ Amazon EC2 Spot Instance Curriculum]</ref> | # Understand the different types of bidding strategies. Amazon defines four types of bidding strategies.<ref>[https://aws.amazon.com/ec2/spot/spot-tutorials/ Amazon EC2 Spot Instance Curriculum]</ref> | ||
| Line 64: | Line 63: | ||
#* If any of the spot instances is interrupted (i.e., terminated by Amazon) then Amazon automatically triggers the termination of all instances in the launch group. However, user-initiated termination of any instance does not cause the remaining instances to be terminated. | #* If any of the spot instances is interrupted (i.e., terminated by Amazon) then Amazon automatically triggers the termination of all instances in the launch group. However, user-initiated termination of any instance does not cause the remaining instances to be terminated. | ||
#* Note that launch groups differ from availability zone groups. For availability zone groups, multiple spot instances are requested together but any one of them getting interrupted does not initiate termination of the others. | #* Note that launch groups differ from availability zone groups. For availability zone groups, multiple spot instances are requested together but any one of them getting interrupted does not initiate termination of the others. | ||
| − | # If using spot instances for front ends with variable traffic loads, understand how to create autoscaling groups of spot instances.<ref>[http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US-SpotInstances.html Launching Spot Instances in Your Auto Scaling Group]</ref> A typical setup for handling variable traffic loads is to have a small number of (reserved) on-demand instances for the baseline capacity and then have an autoscaling group of spot instances to handle the variable additional capacity. | + | # If using spot instances for front ends with variable traffic loads, understand how to create autoscaling groups of spot instances.<ref>[http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US-SpotInstances.html Launching Spot Instances in Your Auto Scaling Group]</ref> A typical setup for handling variable traffic loads is to have a small number of (reserved) on-demand instances (either standalone or in their own autoscaling group) for the baseline capacity and then have an autoscaling group of spot instances to handle the variable additional capacity.[[Image:Autoscaling with spot instances and variable traffic.png|center]] |
#* The autoscaling group can include instances across multiple availability zones. This helps safeguard not only against hardware and network failures but also against spot market price fluctuations in one availability zone. | #* The autoscaling group can include instances across multiple availability zones. This helps safeguard not only against hardware and network failures but also against spot market price fluctuations in one availability zone. | ||
#* A single autoscaling group can either be comprised entirely of spot instances or comprised entirely of on-demand instances. However, multiple autoscaling groups (as well as instances outside of autoscaling groups) can be attached to the same load balancer, so it is possible to mix and match spot instances and on-demand instances to handle the same production workload. | #* A single autoscaling group can either be comprised entirely of spot instances or comprised entirely of on-demand instances. However, multiple autoscaling groups (as well as instances outside of autoscaling groups) can be attached to the same load balancer, so it is possible to mix and match spot instances and on-demand instances to handle the same production workload. | ||
| − | #* The general wisdom with autoscaling groups is to scale up quickly and scale down slowly. This is for multiple reasons. First, since billing is by hour, frequently deleting and restarting spot instances is financially wasteful. Since multiple spikes often occur close in time, it's better to wait a bit before scaling capacity down. Second, not only is it financially wasteful, it also means more possible downtime or poor performance if not enough capacity is available right when the load starts increasing.<ref>[http://techblog.netflix.com/2012/01/auto-scaling-in-amazon-cloud.html Auto Scaling in the Amazon Cloud]</ref> | + | #* The general wisdom with autoscaling groups is to scale up (also known as "scale out" in AWS lingo) quickly and scale down (also known as "scale in" in AWS lingo) slowly. This is for multiple reasons. First, since billing is by hour, frequently deleting and restarting spot instances is financially wasteful. Since multiple spikes often occur close in time, it's better to wait a bit before scaling capacity down. Second, not only is it financially wasteful, it also means more possible downtime or poor performance if not enough capacity is available right when the load starts increasing.<ref>[http://techblog.netflix.com/2012/01/auto-scaling-in-amazon-cloud.html Auto Scaling in the Amazon Cloud]</ref> |
| + | #* A slight variant of the above idea of having a few on-demand instances and an autoscaling group of spot instances is to have two autoscaling groups: one for on-demand instances and one for spot instances. The autoscaling group of on-demand instances has a minimum number of instances equal to the number of reservations, and the autoscaling group of spot instances is intended to handle variability in traffic. Further, the autoscaling group of on-demand instances has a very hard-to-trigger scale-out policy: it can scale out, but only in dire circumstances (i.e., when the load goes really high, which will usually happen if the spot market has no available additional instances to handle the load). The additional instances created in the on-demand autoscaling groups would not be covered by reservations, and would therefore cost more. | ||
#* Amazon's termination policy for autoscaling groups is designed to give you the maximum cost savings while accounting for availability: it terminates the spot instance in the availability zone with the maximum capacity, with the oldest launch configuration, and that is closest to completing its billable hour. The savings can be significant if instances are frequently being created and terminated.<ref>[http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingBehavior.InstanceTermination.html Choosing a Termination Policy for Your Auto Scaling Group]</ref> It is also possible to customize the termination policy. | #* Amazon's termination policy for autoscaling groups is designed to give you the maximum cost savings while accounting for availability: it terminates the spot instance in the availability zone with the maximum capacity, with the oldest launch configuration, and that is closest to completing its billable hour. The savings can be significant if instances are frequently being created and terminated.<ref>[http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingBehavior.InstanceTermination.html Choosing a Termination Policy for Your Auto Scaling Group]</ref> It is also possible to customize the termination policy. | ||
# Consider using spot fleets. These are a new offering from Amazon (announced in May 2015) where you can ask for a spot fleet with multiple instance types.<ref>[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html How Spot Fleet Works]</ref> | # Consider using spot fleets. These are a new offering from Amazon (announced in May 2015) where you can ask for a spot fleet with multiple instance types.<ref>[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html How Spot Fleet Works]</ref> | ||
| Line 73: | Line 73: | ||
#* Amazon offers two spot fleet allocation strategies. The lowestPrice strategy picks a single configuration and as many instances of that as needed, and it picks the configuration with the lower price. For instance, suppose you need 11 units of capacity, and you have set a weight of 1 for m4.2xlarge and 2 for m4.4xlarge. The lowestPrice strategy will either give you 11 m4.2xlarge instances or 6 m4.4xlarge instances, whichever is cheaper. The other strategy, called the diversified strategy, allocates equal shares of the overall capacity to the different instance types, which in this case would mean 6 m4.2xlarge instances and 3 m4.4xlarge instances. Note that in both cases, Amazon limits the maximum amount you pay per unit to your global maximum big price. | #* Amazon offers two spot fleet allocation strategies. The lowestPrice strategy picks a single configuration and as many instances of that as needed, and it picks the configuration with the lower price. For instance, suppose you need 11 units of capacity, and you have set a weight of 1 for m4.2xlarge and 2 for m4.4xlarge. The lowestPrice strategy will either give you 11 m4.2xlarge instances or 6 m4.4xlarge instances, whichever is cheaper. The other strategy, called the diversified strategy, allocates equal shares of the overall capacity to the different instance types, which in this case would mean 6 m4.2xlarge instances and 3 m4.4xlarge instances. Note that in both cases, Amazon limits the maximum amount you pay per unit to your global maximum big price. | ||
#* The spot fleet also launches replacement instances if a particular instance gets terminated, with the type of replacement instance being launched dependent on the strategy used. | #* The spot fleet also launches replacement instances if a particular instance gets terminated, with the type of replacement instance being launched dependent on the strategy used. | ||
| − | + | # Consider using autoscaling groups for long-lived spot instances executing predefined workloads. | |
| − | + | #* Although autoscaling groups were originally designed to handle variable traffic capacity, it is possible to have an autoscaling group of fixed size one. The advantage of placing your spot instance in such an autoscaling group is that Amazon will automatically spin up the instance again if it gets interrupted for price, capacity, or other reasons.<ref>[https://cloudonaut.io/5-aws-mistakes-you-should-avoid/ 5 AWS mistakes you should avoid]</ref> | |
| + | #* It is possible to have persistent storage so that, when the new spot instance is spun up, it retrieves data from wherever the previous spot instance checkpointed it. | ||
| + | #* One key challenge with using autoscaling groups this way is that any custom actions you do upon launch (or revival) must be placed in the user-data of the script and cannot be run through separate scripts. This additional automation usually requires additional investment and may be worthwhile only after you have ironed out other process details. | ||
| + | #* Using autoscaling groups in conjunction with CloudFormation can be helpful for handling upgrades or changes to your configuration. | ||
| + | |||
=== Understanding Spot Instance Pricing History and Trends === | === Understanding Spot Instance Pricing History and Trends === | ||
| − | # Keep in mind that spot markets are very hard to predict. The purpose of looking at spot instance pricing history is not to be able to accurately predict future prices, but to get a sense of the uncertainty, variability and comparison in prices. | + | # Keep in mind that spot markets are very hard to predict. The purpose of looking at spot instance pricing history is not to be able to accurately predict future prices, but to get a sense of the uncertainty, variability and comparison in prices.[[Image:Screen Shot 2016 06 25 at 9.13.02 AM.png|center]] |
| − | # Understand how to interpret spot instance pricing history. | + | # Understand how to interpret spot instance pricing history.[[Image:One month long spot instance price graph.png|center]] |
#* One useful measure is the average instance price over a reasonably long time horizon. This is the rate you pay for long-lived spot instances where you bid sufficiently high that your instance is uninterrupted. However, also keep in mind that new spikes can occur in spot markets that have so far been free of spikes. | #* One useful measure is the average instance price over a reasonably long time horizon. This is the rate you pay for long-lived spot instances where you bid sufficiently high that your instance is uninterrupted. However, also keep in mind that new spikes can occur in spot markets that have so far been free of spikes. | ||
#* Another useful measure is the peak value of spot price. This is the price above which you would need to have bid to have a long-lived spot instance running continuously. | #* Another useful measure is the peak value of spot price. This is the price above which you would need to have bid to have a long-lived spot instance running continuously. | ||
| Line 106: | Line 110: | ||
# Monitor for termination notices and act on them. Amazon offers two-minute spot instance termination notices.<ref>[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html Spot Instance Interruptions]</ref><ref>[http://blog.fugue.it/2015-01-06-spot-termination-notices.html Handling AWS Spot Instance Termination Notices]</ref> These notices can be detected by monitoring an endpoint on the spot instance itself. You can use this information to gracefully disconnect the instance from the load balancer and then gracefully shut down and checkpoint the instance. | # Monitor for termination notices and act on them. Amazon offers two-minute spot instance termination notices.<ref>[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html Spot Instance Interruptions]</ref><ref>[http://blog.fugue.it/2015-01-06-spot-termination-notices.html Handling AWS Spot Instance Termination Notices]</ref> These notices can be detected by monitoring an endpoint on the spot instance itself. You can use this information to gracefully disconnect the instance from the load balancer and then gracefully shut down and checkpoint the instance. | ||
# Make sure that when using scripts frequently that spin up spot instances, you use an AMI and launch setting where the associated EBS volume is set to delete on termination of the instance. | # Make sure that when using scripts frequently that spin up spot instances, you use an AMI and launch setting where the associated EBS volume is set to delete on termination of the instance. | ||
| + | # Move to a more defined architecture with AWS where possible, and where the investment is worthwhile. | ||
| + | #* Rather than having custom scripts running from your own instance to launch and terminate, use AWS autoscaling groups, launch configurations, user data scripts, and CloudFormation. | ||
| + | |||
=== Monitoring and Debugging Costs === | === Monitoring and Debugging Costs === | ||
# Monitor your spot instance costs. | # Monitor your spot instance costs. | ||
Aucun commentaire:
Enregistrer un commentaire