Amazon на прошлой неделе добавил в EC2 новый режим покупки мощностей – Spot Instances. До сих пор облако предлагало два варианта: почасовую оплату On-Demand и предоплаченные Reserved Instances. Spot вводит третий – биржевую цену, которая меняется в реальном времени в зависимости от спроса и свободных мощностей дата-центра. Вы называете максимальную ставку, и пока рыночная Spot-цена ниже неё, ваши инстансы работают. Как только цена превышает ставку, Amazon гасит машины. Это не маркетинговая скидка, а рынок, и работать с ним нужно как с рынком.

Как устроен механизм

Вы задаёте bid – потолок, который готовы платить за час работы инстанса. Amazon публикует текущую Spot-цену для каждого типа машин и зоны доступности. Если ваша ставка выше или равна текущей цене, инстанс запускается, и вы платите фактическую Spot-цену, а не свою ставку. Когда спрос растёт и цена пробивает ваш потолок, инстанс прерывается без гарантий завершения текущей работы.

Экономия реальна. В спокойные часы Spot-цена опускается до трети, а иногда и ниже стоимости On-Demand для того же типа машины. Платите вы за фактическое потребление, что выгодно отличается от Reserved Instances, где деньги вносятся вперёд на год. Но за низкую цену вы платите предсказуемостью: машина может исчезнуть в любой момент, и предупреждения о завершении сеанса вы не получите.

Где это применимо, а где нет

Spot подходит для задач, которые переживают внезапную остановку и перезапуск. Пакетная обработка данных, рендеринг, индексация, научные расчёты, нагрузочное тестирование, обработка очередей – всё, что дробится на независимые порции и сохраняет промежуточный результат. Архитектура должна быть готова к тому, что треть узлов кластера пропадёт за минуту: чекпоинты, идемпотентные задания, очереди с повторной выдачей.

Что под Spot не кладут – это то, что должно работать всегда. Боевые веб-серверы, основная база данных, платёжный контур, любые транзакционные сервисы с требованием доступности. Для таких нагрузок остаются On-Demand и Reserved. Разумная схема – гибрид: постоянное ядро на гарантированных мощностях, эластичная обработка на Spot.

Для корпоративных и государственных заказчиков прерываемость – не единственный вопрос. Дата-центры Amazon находятся в США и Европе, и прежде чем выносить туда рабочие нагрузки, стоит трезво оценить требования к данным. Персональные данные граждан и сведения, обрабатываемые в проектах электронного правительства, к зарубежному публичному облаку отношения иметь не должны – защита персональных данных этого не позволяет. Под Spot уместно отдавать обезличенные и расчётные задачи, а не чувствительные реестры.

Что учесть в эксплуатации

Прерываемость заставляет пересмотреть процессы. Нужен внешний оркестратор, который отслеживает Spot-цену, держит целевое число узлов и при потере машин запускает новые – возможно, в другой зоне доступности или временно через On-Demand. Доступ к API ставок и управлению инстансами разграничивайте по ролям: ставки и запуск мощностей напрямую влияют на бюджет, поэтому управление учётными записями и правами здесь не формальность.

Встроить такую модель в существующую инфраструктуру – значит спроектировать гибридную архитектуру, отделить прерываемые нагрузки от критичных и выстроить автоматизацию запуска облачных мощностей.

Вывод

Spot Instances превращают вычисления в биржевой товар с плавающей ценой. Для пакетных и масштабируемых задач это способ резко снизить затраты, если архитектура переживает прерывания. Для критичных сервисов и чувствительных данных – не вариант. Считайте экономику, проектируйте под отказ и держите границу между тем, что можно отдать рынку, и тем, что должно работать всегда.