Что такое прерываемые (Spot) виртуальные машины: возможности, риски и архитектура
+----------------------------------------------------------------------------+
| SPOT INSTANCE EVICTION VS MICROSRV LIVE MIGRATION |
+----------------------------------------------------------------------------+
| |
| [1] ПРЯМОЕ ИСПОЛЬЗОВАНИЕ SPOT-ИНСТАНСА (Без оркестрации) |
| |
| +-----------+ |
| | Host-17 | --- Сигнал выселения / Хост отключён ---> X |
| +-----------+ |
| | |
| +-- Оперативная память (RAM) --------- СБРОШЕНА |
| +-- Процессы приложения -------------- УБИТЫ |
| +-- Внутренний и внешний IP ---------- УТЕРЯНЫ |
| +-- Сетевые соединения ---------------- ОБОРВАНЫ |
| +-- Итог ----------------------------- ПРОСТОЙ И ПЕРЕЗАПУСК |
| |
| [2] ЖИВАЯ МИГРАЦИЯ В MICROSRV (Платформа автоматизации) |
| |
| Host-17 (Прерывается) Host-42 (Новый Spot) |
| +-----------+ Миграция RAM на лету +-----------+ |
| | ВМ Гостя | ========================> | ВМ Гостя | |
| +-----------+ Диски & eBPF-сеть +-----------+ |
| | | |
| +-- Память (RAM) и процессы ------------ СОХРАНЕНЫ И АКТИВНЫ |
| +-- Приложение внутри ВМ ------------- РАБОТАЕТ БЕЗ ПЕРЕЗАПУСКА |
| +-- Сетевой IP и домен (app.ru) ------- БЕЗ ИЗМЕНЕНИЙ |
| +-- Открытые TCP-соединения ---------- СОХРАНЕНЫ |
| |
+----------------------------------------------------------------------------+
Облачные провайдеры — от Microsoft Azure и AWS до специализированных платформ вроде Nebius, RunPod и Vast.ai — предлагают прерываемые виртуальные машины (Spot / Preemptible VMs) со скидкой от 50% до 80–90% по сравнению со стандартными тарифами On-Demand.
Разбираемся, откуда у облаков берутся эти мощности, почему они стоят так дешево, какие ограничения накладывают на разработчиков и как с ними правильно работать.
1. Откуда берутся Spot-мощности в ЦОД
Любой облачный провайдер вынужден держать запас свободных вычислительных ресурсов (unallocated capacity). Он нужен, чтобы выполнять обязательства по SLA, справляться с внезапными пиками спроса и быстро выдавать новые ВМ по требованию (On-Demand).
Если физический сервер стоит в стойке, подключён к питанию и сети, но не занят клиентом, провайдер несёт убытки на его амортизацию и охлаждение.
Чтобы свободное оборудование не простаивало, облака предлагают его с большой скидкой, но с одним условием: как только ресурсы понадобятся клиенту по базовому тарифу (On-Demand), провайдер заберёт сервер обратно.
2. Как устроена механика прерывания (Eviction / Preemption)
Прерываемые ВМ работают до тех пор, пока в конкретной зоне доступности или пуле серверов есть избыточная ёмкость.
Модели ценообразования
- Фиксированная скидка (Preemptible): Провайдер задаёт фиксированную цену (обычно −50% … −70% от базового тарифа). ВМ прерывается только тогда, когда ресурсы требуются под On-Demand нагрузку.
- Спот-рынок и аукцион (Spot / Max Price): В некоторых облаках (Azure Spot, RunPod, Vast.ai) цена меняется динамически в зависимости от спроса. Вы можете указать максимальную ставку (Max Price), которую готовы платить. Если текущая рыночная цена превысит вашу ставку, ВМ будет остановлена.
Сигналы выселения (Eviction Notices)
Когда провайдер решает забрать хост, он отправляет уведомление о прерывании через внутренний сервис метаданных (Metadata Service) или системного агента.
- Время на реакцию: обычно провайдер даёт от 30 секунд (Azure Spot, AWS) до 2 минут. В некоторых GPU-облаках при мгновенном всплеске спроса прерывание может произойти почти без паузы.
- Политика выселения (Eviction Policy):
- Stop / Deallocate: ВМ останавливается, её vCPU и RAM освобождаются, но конфигурация и диски сохраняются. Вы платите только за хранение диска.
- Delete / Terminate: ВМ и её локальные эпифемерные диски полностью уничтожаются.
3. Главные преимущества прерываемых ресурсов
- Экономия на вычислениях до 80%: тот же объём задач обходится в несколько раз дешевле, а кластер можно увеличить без резкого роста бюджета.
- Подходит для пакетных задач (Batch Workloads):
- ИИ и машинное обучение: обучение моделей с регулярным сохранением контрольных точек (checkpointing).
- CI/CD и сборка: изолированные раннеры для тестов, компиляции и сборки Docker-образов.
- Рендеринг и кодирование: обработка видео, 3D-рендеринг, сбор данных и аналитические задачи.
- Spot Node Pools в Kubernetes: вторичные рабочие узлы K8s для фоновых задач, которые можно легко перезапустить.
4. Ограничения и подводные камни
При всех плюсах прямой запуск обычных сервисов на Spot-инстансах связан с серьёзными рисками:
- Нет SLA на доступность: провайдер не гарантирует, сколько проработает ВМ. Она может работать три недели без остановки, а может быть отозвана через десять минут после запуска.
- Потеря несохранённого состояния: при отзыве узла данные в оперативной памяти и на локальных временных дисках теряются.
- Обрыв сетевых сессий: При остановке ВМ её публичный и приватный IP-адреса освобождаются, а все активные TCP-соединения, SSH-сессии и открытые сокеты рвутся.
- Риск массовых прерываний (Mass Eviction): во время регионального пика спроса провайдер может отозвать сразу десятки узлов кластера.
5. Как адаптировать архитектуру под Spot-ресурсы
Чтобы приложения выдерживали внезапные отключения, их проектируют по принципам Stateless & Fault-Tolerant:
- Вынос состояния (Stateless): никаких важных данных на локальном диске. Состояние следует хранить в базе данных, Redis или объектном хранилище (S3).
- Обработка сигналов отключения: сервисы должны опрашивать адрес метаданных провайдера, обрабатывать сигнал прерывания (SIGTERM / Eviction Notice), прекращать приём новых запросов и корректно завершать текущие задачи (Graceful Shutdown).
- Разнообразие типов ВМ (Instance Diversity): Не привязывайтесь к одному типу или размеру ВМ. Настраивайте автомасштабирование так, чтобы оно использовало разные типы процессоров и разные зоны доступности.
6. Как microsrv устраняет ключевые недостатки Spot-модели
Обычный переход на Spot-инстансы требует переработать архитектуру: внедрить Graceful Shutdown, перестроить сеть и смириться с принудительными перезапусками приложения и потерей кэша в памяти. Для многих команд затраты на разработку и эксплуатацию съедают экономию на инфраструктуре.
Платформа microsrv убирает эти ограничения на уровне самой инфраструктурной платформы:
- Живая миграция RAM и запущенных процессов: оркестратор переносит содержимое оперативной памяти на лету. Приложение внутри ВМ не перезапускается, сохраняет состояние и продолжает работу без сбоев.
- Защита от потери состояния на дисках: microsrv постоянно синхронизирует состояние дисковых томов. Все данные и файловая система сохраняются в полном объёме.
- Непрерывность сети через eBPF: Сетевой слой прозрачно перенаправляет трафик при смене хоста. Внутренний IP-адрес, доменное имя
<vm>.microsrv.ruи открытые TCP-соединения продолжают работать без переподключения клиентов. - Не нужно переписывать код: приложения работают как на обычной ВМ — с выделенными vCPU, постоянными дисками и стабильной сетью.
Вы получаете экономию около 40% по сравнению со стандартными облачными тарифами без основных сложностей и рисков Spot-модели.
Запускайте виртуальные машины на 40% дешевле облачных тарифов
microsrv автоматически управляет прерываемыми ресурсами облаков: переносит ВМ до отключения хоста, сохраняя диски, IP-адреса и открытые соединения.