As part of a project to offset usage spikes by auto spinning up EC2 instances on the fly for added computing power during high traffic periods, I needed to answer the question how fast could I really spin up an EC2 instance. So after running several tests against small and large EC2 instances running a base CentOS 5.3 AMI this is what I found:
Small Instance 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform with a base install of CentOS 5.3 AMI
Amount of time from launch of instance to availability:
Between 5 and 6 minutes us-east-1c
Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform with a base install of CentOS 5.3 AMI
Amount of time from launch of instance to availability:
Between 11 and 18 minutes us-east-1c
Both were started via command line using Amazons tools.
Given my research instances are not so instant, so in order to accommodate for the delay calculating your usage patterns is key to avoid the gap. Having a reserve set of instances running as a buffer to carry you over the delay of launching new instances during peak load times is a must. By knowing your usage patterns you can at least make an educated decision as to how many instances you will need in the buffer. Also a system of seeing load acceleration against running capacity will be important for auto launching instances as necessary given your determined algorithm.
Hi Phil,
To the point of [automatically] determining usage patterns and unexpectedly high traffic periods:
perhaps you could use Holt-Winters Forecasting, as implemented in RRDTool, to determine when would be a good time to bring up the additional resources. This could help in two ways: (1) to determine typical load based on past observations (accommodating diurnal variation) and (2) when the load is aberrant in that it is beginning to exceed the forecast significantly, it could report this as prediction failure and provide an early indication to bring up those additional resources in anomalous load situations, such as flash crouds. This can be made to work well on the scale of tens of minutes in the default RRDTool implementation.
Jake Brutlag’s original paper is here: http://www.usenix.org/events/lisa00/brutlag.html
Dave
Hi Dave,
Thanks for the info, I will definitely check out the paper, and see if Holt-Winters Forecasting model suits our needs! I am sure I will have some questions for you after reading up on it.
Phil