Что такое прерываемые (Spot) виртуальные машины: возможности, риски и архитектура

Microsoft Azure, AWS, Nebius, RunPod, Vast.ai — у всех в прайсе есть прерываемые виртуальные машины (Spot и Preemptible) со скидкой от 50% до 80–90% к обычному тарифу On-Demand.

Коротко: Spot-ВМ — это дешёвые вычисления, которые провайдер может отозвать в любой момент. Для пакетных задач это почти бесплатные ресурсы; для сервисов с состоянием нужна оркестрация поверх (например, microsrv).

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

1. Откуда берутся свободные мощности в ЦОД

Любому облачному провайдеру приходится держать запас незанятых вычислительных ресурсов. Без запаса не выполнить обязательства по SLA, не пережить внезапный пик спроса и не выдать новую ВМ клиенту On-Demand за разумное время.

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

Выход, к которому пришли все крупные облака: отдавать простаивающее оборудование с большой скидкой. Условие одно. Как только ресурсы понадобятся клиенту по базовому тарифу (On-Demand), провайдер их отзовёт.

2. Как устроен механизм прерывания

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

Модели ценообразования

Фиксированная скидка (Preemptible): провайдер назначает фиксированную цену, обычно на 50–70% ниже базового тарифа. Прерывание происходит, когда ресурс нужен нагрузке On-Demand.
Спот-рынок и аукцион (Spot / Max Price): в части облаков (Azure Spot, RunPod, Vast.ai) цена плавает вместе со спросом. Вы указываете максимальную ставку (Max Price); если рыночная цена превышает её, ВМ останавливается.

Уведомления об отзыве

Решив отключить хост, провайдер шлёт уведомление о прерывании через сервис метаданных или системного агента.

Время на реакцию: обычно от 30 секунд (Azure Spot, AWS) до 2 минут. В некоторых GPU-облаках при резком всплеске спроса прерывание происходит почти без паузы.
Политика остановки и отзыва:
- Stop / Deallocate: ВМ останавливается, vCPU и RAM освобождаются, конфигурация и тома остаются. Платите только за хранение тома.
- Delete / Terminate: ВМ и её локальные эфемерные диски уничтожаются полностью.

3. Главные преимущества прерываемых ресурсов

Экономия на вычислениях до 80%. Тот же объём задач обходится в несколько раз дешевле, а кластер растёт без резкого удара по бюджету.
Пригодность для пакетных задач:
- ИИ и машинное обучение: обучение моделей с регулярным сохранением контрольных точек.
- CI/CD и сборка: изолированные агенты для тестов, компиляции и сборки Docker-образов.
- Рендеринг и кодирование: обработка видео, 3D-рендеринг, сбор данных, аналитика.
- Пулы Spot-узлов в Kubernetes: дополнительные рабочие узлы K8s для фоновых задач, которые не жалко перезапустить.

4. Ограничения и подводные камни

Прямой запуск обычного сервиса на прерываемых ресурсах — это серьёзный риск:

Нет SLA на доступность. Провайдер не гарантирует, сколько проработает ВМ: может три недели, а может десять минут после запуска.
Потеря несохранённого состояния. При отключении хоста данные в RAM и на локальных временных дисках пропадают безвозвратно.
Обрыв сетевых сеансов. Публичный и частный IP освобождаются, все активные TCP-соединения, SSH-сеансы и открытые сокеты рвутся.
Массовый отзыв хостов. Во время регионального пика спроса провайдер может отозвать сразу десятки узлов кластера.

5. Как адаптировать архитектуру к прерываемым ресурсам

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

Вынос состояния. Никаких важных данных на локальном диске. Состояние живёт в базе данных, Redis или объектном хранилище (S3).
Обработка сигналов отключения. Сервис опрашивает метаданные провайдера, ловит сигнал прерывания (SIGTERM или уведомление об отзыве), прекращает приём новых запросов и корректно завершает текущие задачи.
Разнообразие конфигураций ВМ. Не привязывайтесь к одному типу или размеру ВМ. Настройте автомасштабирование на разные семейства процессоров и зоны доступности.

6. Как microsrv устраняет ключевые недостатки Spot-модели

Обычный переход на прерываемые ресурсы означает переработку архитектуры: graceful shutdown (корректное завершение), перенастройка сети, смирение с принудительными перезапусками и потерей кэша в памяти. Для многих команд затраты на разработку и эксплуатацию съедают экономию на инфраструктуре.

Платформа microsrv снимает эти ограничения на своём уровне:

Живая миграция RAM и запущенных процессов. Оркестратор в реальном времени переносит содержимое оперативной памяти. Приложение внутри ВМ не перезапускается, сохраняет состояние и продолжает работу. Подробнее в разборе живой миграции.
Защита состояния в томах. Тома непрерывно синхронизируются, все данные и файловая система сохраняются в полном объёме. Как это устроено, рассказано в статье про репликацию томов.
Непрерывность сети через eBPF. Сетевой слой прозрачно перенаправляет трафик при смене хоста. Частный IP, доменное имя <vm>.msrv.space и открытые TCP-соединения продолжают работать, клиенты не переподключаются. Архитектура слоя описана в обзоре eBPF-сети.
Не нужно переписывать код. Приложения работают как на обычной ВМ: выделенные vCPU, постоянные тома, стабильная сеть.

Итог: экономия около 25% по сравнению с крупными облаками без главных сложностей Spot-модели, с SSH, доменным именем и TLS из коробки. Разницу между скидкой в прайсе и реальной экономией с учётом простоев разбирает статья Spot vs On-Demand.

Источники и что почитать дальше

AWS — прерывания Spot-инстансов и уведомления о прерывании (2 минуты)
Microsoft Azure — Spot Virtual Machines и политика вытеснения
Google Cloud — Spot VMs — обзор
KVM/QEMU — документация по live migration

Примечание от автора: Материал основан на моём опыте эксплуатации Spot-ресурсов в проде и на оркестраторе microsrv, описанном в статьях живая миграция и репликация томов. Оценку «около −25% к обычным тарифам» я получил из публичных калькуляторов провайдеров по ссылкам /go/cloud-a и /go/cloud-b для конфигурации 3×(4 vCPU·8 ГБ·40 ГБ SSD); методология описана в статье Spot и On-Demand.