Amazon just announced "S开发者_C百科pot Instances" for their EC2 based infrastructure. I was wondering what sort of workloads would be appropriate for such service?
Spot Instances enable you to bid for unused Amazon EC2 capacity. Instances are charged the Spot Price set by Amazon EC2, which fluctuates periodically depending on the supply of and demand for Spot Instance capacity.
Interesting quote:
The philosophy of JIT is simple: inventory is waste.
EDITED:
I wonder if there are applications that could sustain themselves (read: be viable) just by leveraging a large volume of those Spot instances. Think about it: imagine you get 10 instances for the price of 1 on average... of course there wouldn't be guarantees but in the case that no Spot instances are available, a number of "normal" instances could be kicked-of.
Obviously this is for any workload that doesn't need to be real-time.
Let's say on smaller scale, how this could apply to stackoverflow? For example, many badges on this site are not calculated in real-time. There is periodical process that will evaluate eligibility and it doesn't matter whether it runs at 4am or 4pm everyday as long as it runs. Doing it at 4am could be 5 cents cheaper. (obviously they don't use EC2 at all for this)
Larger scale? Search engine over large set of data might need huge computing capacity to build its indexes. If you index new data once a day and it takes 2 hours to index them on hundreds of servers, you can do it overnight and save perhaps thousands of dollars every day.
By spreading workload around the clock helps Amazon maximize utilization of their resources and therefore provide the cheapest prices on the market.
Amazon could only think of these workloads:
- Image and video processing, conversion and rendering
- Scientific research data processing
- Financial modeling and analysis
Spot Instances remind me of "double tariff electricity meters", where you pay less for energy when the demand is less. I think it is a very interesting concept, and quite an unexpected introduction to the cloud, but it will probably be difficult to apply to conventional business problems.
I am considering setting up a flexible cluster (say HADOOP) with a backbone that runs on regular instances and a few sets of additional instances at decreasing spot prices. As the price drops, additional instances become available to process work units. If the price increases, nodes will be shut down. The cluster handles this by re-issuing the work units to other nodes, just as it would in case of node failure.
Obviously this is a rather hostile environment so some adjustments need to be made. If you work with standard 3-fold replication for the global filesystem and the three nodes containing the block are shut down at the same time, you lose. Spreading the spot instance prices decreases the likelihood of losing many in one fell swoop. Increasing the replication factor will reduce the impact, and disk space is free with the instance anyway so that won't be a factor. Is this enough? We'll see.
There are obvious use cases such as batch processing or tasks that don't need to be running 24/7.
Other interesting implementations are for extra capacity. You could use a mix of on-demand and spot instance to run your website. The on-demand instances would serve as your 'core'. If your spot instances are down for a few hours here or there your on-demand instance may work a little harder but your website would still be accessible.
精彩评论