Что такое Spot Instances / Preemptible VM и для каких задач они подходят

Spot Instances и Preemptible VM — это прерываемые виртуальные машины, которые облачные провайдеры отдают со скидкой из свободной вычислительной ёмкости. Смысл простой: вычисления обходятся дешевле, но сам ресурс не гарантирован и может быть отозван.

На практике такие машины подходят не для “дешёвых серверов вообще”, а для задач, которые нормально переносят остановку, перезапуск или потерю отдельного узла.

Обычно это:

• Batch-обработка;
  
• CI/CD-задачи;
  
• Dev/test-окружения;
  
• Фоновые вычисления;
  
• Fault-tolerant workloads.

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

Главная мысль здесь простая: Spot / Preemptible VM — это не обычные VM “просто подешевле”, а дешёвая вычислительная мощность для задач, которые изначально спроектированы под прерывания.

Spot Instances и Preemptible VM: что это вообще такое

Spot Instances и Preemptible VM — это виртуальные машины со сниженной ценой, которые работают на свободной вычислительной ёмкости провайдера.

Их главный плюс очевиден: такие ресурсы обходятся заметно дешевле обычных VM.

Но вместе с низкой ценой приходит и ограничение. Эти машины не считаются полностью гарантированными. Если провайдеру снова понадобится эта ёмкость, инстанс могут остановить, завершить или вытеснить. У разных облаков детали отличаются, но сама логика остаётся одной и той же: вы экономите на вычислениях, однако не получаете полной гарантии, что конкретная VM проработает столько, сколько вам нужно.

То есть по своей сути это не “обычные VM, только дешевле”, а дешёвая вычислительная мощность с риском прерывания.

Считаем, что было бы ошибкой не упомянуть один очень важный и забавный нюанс: у разных облаков одна и та же идея называется по-разному. 

Почему у разных облаков разные названия

Это связано не с тем, что речь идёт о принципиально разных типах VM, а с разной терминологией и эволюцией собственных сервисов. AWS использует название Spot Instances, Azure — Spot Virtual Machines, а в Google Cloud сейчас основным названием стали Spot VMs, при том что более старый термин Preemptible VMs всё ещё встречается в документации и старых материалах. Google отдельно указывает, что Spot VMs — это более новая версия preemptible VM и рекомендует использовать именно их.

Для статьи это важно по одной причине: читатель может встретить разные названия и решить, что речь идёт о разных моделях. На практике базовая логика везде очень похожа — провайдер отдаёт вычислительную мощность дешевле, но оставляет за собой право прервать работу VM и вернуть ресурсы в общий пул.

Ниже разница в названиях видна проще:

Из этой таблицы полезно вынести простую мысль: названия различаются, но подход в основе один.

Поэтому в тексте обычно приходится использовать сразу два обозначения — Spot Instances / Preemptible VM — просто чтобы не потерять читателя, который пришёл с разной терминологией из AWS, Azure или Google Cloud. А уже дальше можно спокойно переходить не к словам, а к сути: что именно вы выигрываете по цене и каким риском за это расплачиваетесь.

Подводные камни низкой цены

Главное преимущество таких машин лежит на поверхности: они позволяют заметно снизить стоимость вычислений.

Именно поэтому Spot / Preemptible VM часто рассматривают там, где нагрузка может быть гибкой по времени, масштабироваться рывками или спокойно переживать остановку отдельных узлов.

Но низкая цена здесь всегда связана с риском.

Провайдер не обещает, что конкретная VM будет доступна столько, сколько нужно приложению. Если свободная ёмкость снова понадобится, инстанс могут остановить, вытеснить или завершить. 

Главная экономика таких машин строится на простом обмене:

Если приложение спокойно переносит остановку отдельной машины, умеет перезапускать задачи, сохранять промежуточный результат или просто не зависит от жизни одного конкретного узла, низкая цена может дать очень хороший выигрыш.

Если же нагрузка завязана на постоянную доступность, локальное состояние или жёсткое время отклика, выгода быстро перестаёт быть такой однозначной. Экономия на цене VM может легко обернуться более дорогими сбоями на уровне самого сервиса.

Именно поэтому такие машины стоит оценивать не по скидке самой по себе, а по тому, как именно ведёт себя ваша нагрузка при прерывании.

Одна задача спокойно переживёт остановку отдельного узла и просто перезапустится. Другая потеряет состояние, сорвёт выполнение или уронит сервис целиком. Отсюда и вытекает следующий практический вопрос: для каких задач Spot / Preemptible VM действительно подходят, а где их лучше не использовать вовсе.

Для каких задач они подходят на практике

Задачи, которые легко перезапустить

Самый очевидный сценарий — batch-обработка.

Если работа идёт пакетами, по частям или через очередь, остановка одной VM обычно не ломает весь процесс. Отдельный кусок можно просто запустить заново, а саму нагрузку — перераспределить между другими узлами.

Хорошо сюда же ложатся CI/CD-задачи.

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

Похожая логика работает и для фоновых вычислений.

Это могут быть асинхронные задачи, обработка данных, рендеринг, расчёты или другие процессы, где важен общий результат, а не судьба одной VM. Если система умеет повторять задачу после сбоя, дешёвая прерываемая ёмкость здесь выглядит вполне уместно.

Например, интернет-магазин газонокосилок ночью пересчитывает рекомендации, обновляет поиск и прогоняет пакетную обработку каталога. Если одна Spot VM отвалится посреди этой работы, задача просто уйдёт на повторный запуск или подхватится другим узлом. Для такого фона потеря конкретной машины неприятна, но не критична.

Сценарии, где не жалко потерять отдельный инстанс

Ещё один подходящий класс — dev/test-окружения.

Если команда поднимает временные стенды, машины для проверки изменений или среды под короткие эксперименты, постоянство конкретной VM обычно не критично. Зато экономия на вычислениях становится вполне ощутимой, особенно если таких окружений много или они создаются регулярно.

Сюда же относятся и более широкие fault-tolerant workloads.

Это нагрузки, которые изначально проектируются с мыслью, что отдельный узел может исчезнуть в любой момент. Обычно у таких систем есть очередь задач, повторный запуск, checkpoint или другое распределение работы, при котором потеря одной VM не обрушивает весь сервис.

Именно в таких сценариях Spot / Preemptible VM раскрываются лучше всего. Чем меньше система зависит от конкретного инстанса, тем проще ей превратить дешёвую, но нестабильную вычислительную мощность в реальную выгоду, а не в источник случайных сбоев.

Где их лучше не использовать

Низкая цена таких машин легко выглядит соблазнительно.

Но именно здесь и начинается главный подвох: не каждая нагрузка умеет спокойно переживать потерю VM. Если задача завязана на постоянную доступность, локальное состояние или предсказуемое время работы конкретного узла, Spot / Preemptible VM быстро превращаются из способа сэкономить в источник лишнего риска.

Сервисы, для которых важен непрерывный аптайм

Первая проблемная зона — сервисы, где важен стабильный онлайн и предсказуемая доступность.

Если приложение должно постоянно отвечать пользователям, не терять соединения и не зависеть от внезапного исчезновения узла, прерываемая VM становится слишком хрупкой основой. Да, отдельный инстанс можно заменить, но сам факт, что провайдер может забрать его в любой момент, уже делает такую схему слабее для чувствительной боевой нагрузки.

Особенно осторожно к таким VM обычно относятся для:

• Боевых API;
  
• Checkout и платёжных сценариев;
  
• Latency-sensitive сервисов;
  
• Систем с постоянными пользовательскими сессиями;
  
• Одиночных production-узлов без нормального резерва.

На бумаге может показаться, что раз инстанс стоит заметно дешевле, то на Spot / Preemptible VM можно просто перенести обычный рабочий сервер и сразу сократить расходы. Но если эта нагрузка не умеет переживать interruption или eviction, экономия быстро исчезает. Один неудачный момент вытеснения может обойтись дороже, чем вся разница в цене между обычной и прерываемой VM.

Нагрузки с привязкой к состоянию и данным

Вторая зона риска — системы, которые держатся за состояние, данные или роль конкретного узла.

Когда приложение завязано на локальные файлы, текущую сессию, незавершённую запись, данные на диске или особую роль одной машины в общей схеме, потеря VM перестаёт быть просто “неприятным рестартом”. Здесь уже можно получить потерю прогресса, разрыв соединений, ошибки записи или более тяжёлые последствия на уровне самого сервиса.

Именно поэтому такие VM особенно спорно выглядят для:

• баз данных;
• stateful-сервисов с локальным состоянием;
• систем, чувствительных к потере текущего прогресса;
• узлов, где важна согласованность данных;
• сервисов, в которых роль конкретной машины трудно быстро заменить.

Представим игровую студию, которая хранит временные расчёты матчей, игровые сессии или куски состояния прямо на конкретном сервере. Для тестового стенда это ещё можно пережить. Но если тот же подход утащить в боевую среду на прерываемые VM, исчезновение одного инстанса уже может означать не просто перезапуск, а потерю части состояния и плохой пользовательский опыт.

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

Что выбрать, если Spot / Preemptible VM не подходят

Не каждая нагрузка готова жить на прерываемых виртуальных машинах.

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

Ниже — простой ориентир по вариантам, которые обычно рассматривают вместо чистой Spot / Preemptible-модели:

Во многих случаях команда вообще выбирает не между “дёшево” и “дорого”, а между разным уровнем риска.

Иногда разумнее оставить критичную часть нагрузки на обычных VM, а фоновые или гибкие задачи вынести на Spot. Такой смешанный подход позволяет не строить весь сервис на прерываемой ёмкости, но всё же забирать часть экономии там, где она действительно безопасна.

В других сценариях лучше работает уже не ценовая, а архитектурная альтернатива.

Если сервис слишком чувствителен к исчезновению отдельной машины, полезнее не искать “ещё более дешёвую VM”, а выбрать модель, где сама система меньше зависит от жизни конкретного узла.

На практике логика выбора обычно сводится к трём вариантам:

• Оставить критичную нагрузку на обычных VM;
  
• Сделать смешанную схему из обычных и Spot-инстансов;
  
• Перестроить сам workload так, чтобы он нормально переживал прерывания.

Последний путь особенно важен.

Если у системы появляются очередь задач, повторный запуск, checkpoint или распределение работы между несколькими узлами, часть сценариев уже можно безопаснее перевести на прерываемые VM. Но это работает только там, где приложение действительно готово к такой модели, а не просто надеется, что конкретный инстанс проживёт подольше.

Именно поэтому выбирать здесь лучше не по размеру скидки, а по характеру нагрузки.

Сначала стоит понять, насколько система чувствительна к потере узла, и уже потом решать, что ей подходит больше: обычные VM, смешанный пул или переработка архитектуры под дешёвую прерываемую ёмкость.

Заключение

Spot / Preemptible VM стоит рассматривать не как универсальный способ удешевить инфраструктуру, а как инструмент под определённый тип нагрузки.

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

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

FAQ

Spot Instances и Preemptible VM — это одно и то же?

По смыслу почти да: в обоих случаях речь о дешёвой, но прерываемой вычислительной мощности. Разница в основном в терминологии провайдеров. У Google Cloud сейчас основным названием считаются Spot VMs, а preemptible VMs — более старый вариант этой модели.

Можно ли держать на таких VM production вообще?

Иногда да, но только если сама архитектура спокойно переживает потерю отдельного узла. Для одиночных боевых серверов, критичных API или чувствительных stateful-сервисов это обычно плохая идея. Azure и Google оба привязывают такие машины к interruption-tolerant или fault-tolerant нагрузкам.

Насколько заранее предупреждают о прерывании?

Зависит от облака. В AWS для Spot есть уведомление примерно за две минуты до остановки или завершения инстанса. В Azure логика eviction зависит от сценария и политики, а для подготовки приложений используют механизмы вроде Scheduled Events. В Google Cloud Spot VM могут быть прерваны в любой момент, поэтому на длительную жизнь конкретного узла лучше не рассчитывать.

Подходят ли такие VM для Kubernetes, очередей и пакетных задач?

Да, это как раз один из самых частых сценариев. Google отдельно описывает использование preemptible/Spot VM для fault-tolerant workloads в GKE, а Azure рекомендует Spot VM для batch processing, dev/test и large compute workloads.

Если задача длинная, такие VM уже не подходят?

Не обязательно. Подходят, если сама задача умеет сохранять прогресс, перезапускаться или делиться на части. Проблема не в длине как таковой, а в том, насколько workload зависит от непрерывной жизни одной конкретной VM.

Чем Spot VM лучше обычной VM, кроме цены?

Главный плюс всё равно в цене и в возможности дешевле масштабировать гибкие нагрузки. Но вместе с этим вы получаете и архитектурный стимул проектировать систему так, чтобы она меньше зависела от одного узла. Если workload к этому не готов, обычная VM часто будет практичнее.

Список источников

1. AWS — Spot Instance interruptions

2. AWS — Spot Instance interruption notices

3. Microsoft Learn — About Azure Spot Virtual Machines

4. Google Cloud — Spot VMs