Повышаем эффективность использования EC2 инстансов в облаке

В этой статье я расскажу про одну особенность биллинга Амазона, которую полезно учитывать если вы делаете автоматически масштабируемый проект.

Сначала цитата из официального описания сервиса EC2 http://aws.amazon.com/ec2/:

Pricing is per instance-hour consumed for each instance, from the time an instance is launched until it is terminated. Each partial instance-hour consumed will be billed as a full hour.

Эта особенность заключается в том, что минимально возможная атомарная тарификация за использование сервера EC2 — 1 час. Даже если вы включили сервер, погоняли его 5 минут и выключили, то вы все равно заплатите за полный час использования машины.

Целесообразно учитывать это в алгоритме масштабирования системы. Если запоминать время запуска каждого инстанса в вашем клауде, то вы можете воспользоваться некоторыми приемами для экономии средств. Конечно, если вы используете только встроенные механизмы Amazon Autoscaling для масштабирования (например, на базе алармов срабатывающих по состоянию какого-то CloudWatch’а или Elastic Balancer’а), то применять какие-то хитрости не получится. Однако, если размером кластера занимается ваша компонента (обычно называемая cloud manager), то все в ваших руках.

Когда ваш алгоритм понимает, что ему нужно выключить 1 машину, то имеет смысл выбрать ту машину, время работы которой с момента ее старта находится ближе всего к концу часа. Потом нужно подождать, пока это время приблизится к концу часа до какой-то дельты (например за 5 минут) и тогда уже удалять ее. 5 минут нужно для гарантии того, что мы не перешагнем границу часа, т.к. удаление машины тоже занимает какое-то время, обычно 1-2 минуты. Применение такой стратегии даст вам возможность выжимать максимум из оплаченных EC2 часов. К тому же, если вдруг в промежуток времени между принятием решения о выключения инстанса и наступлением 55 минут, нагрузка на систему снова возрастет и потребуется увеличить кластера, вам этого делать уже не придется — у вас стоит на готове “горячий” резерв. Т.е. возрастает реактивность системы.

Отдельного коментария заслуживают те случаи, когда у вашей системы очень резко изменяющаяся нагрузка, и вы по нескольку раз в час вынуждены принимать решения то добавлять, то удалять машину. Такая ситуация плоха тем, что если будет включаться и выключаться одна и та же машина, то вы постоянно будете переплачивать за несколько минут (или десятков минут) использования машины стоимость полного часа. В таких случаях имеет смысл соптимизировать критерий удаления машины, чтобы не происходило частых сжиманий и разжиманий клауда. Например, если вы используете для оценки какую-то характеристику, усредненную за какой-то промежуток времени (например состояние CPU за последние 5 минут), лучше увеличить этот промежуток (например до 15-30 минут).