Spot VM GCP: где ломается пакетная обработка
Пакетное окно на постоянных узлах выглядит благополучно: ночной пересчёт, отчёт, выгрузка — и дальше сутки простоя, пока железо ждёт следующего запуска. Перенос на Spot VM GCP снимает простой, но обнажает вторую проблему: прерываемые машины пакетная обработка терпит только при одном условии — задание умеет умирать, не теряя результата.
На практике условие не выполняется. Планировщик отдаёт задачу целиком, исполнитель держит состояние в памяти и пишет выход одним файлом в конце, а уведомление об изъятии узла приходит с окном в единицы минут и не всегда доходит до дочерних процессов. Прерывание в середине такой записи даёт либо пустой артефакт, либо частично перезаписанный — и повторный запуск принимает его за валидный.
Потеря результата задания дороже сэкономленного простоя. Один сорванный исполнитель означает повтор всей цепочки, включая уже посчитанные шаги, ручной разбор расхождений в агрегатах и потерянное окно до следующего цикла. Опаснее, когда потери не видны сразу: отчёт уходит с дырой, и её находят позже по жалобе на неверные цифры.
Дальше разбираем, как это закрывается: дробление работы на переигрываемые единицы, контрольные точки в объектном хранилище, идемпотентная запись по ключу задачи и настройка изъятия, при которой уход узла стоит секунд, а не целого окна.
Что даёт пул Spot-машин пакетной обработке
Пул прерываемых машин даёт пакетной обработке больше параллельных исполнителей и предсказуемую деградацию вместо потери результатов. Плата за это — уведомление об освобождении узла приходит за 30 секунд, и вся логика расчёта строится вокруг того, чтобы эти секунды не стоили пересчёта задачи. Google Cloud публикует статистику прерываний Spot-узлов: в среднем это единицы процентов ёмкости в сутки, но в часы пикового спроса доля растёт — поэтому пул проектируют не на «обычно не прерывают», а на «прерывают всегда».
Сокращение окна обработки
Длительность окна определяет не размер пула, а скорость его подстройки под длину очереди. Автомасштабирование группы машин мы привязываем к глубине очереди, а не к загрузке процессора: пакет из сотен тысяч независимых задач забирает свободную ёмкость за минуты, а после опустошения очередь пул сжимается до базового размера. Окно вместо восьми часов укладывается в два-три, и холостой расход ёмкости между запусками исчезает.
Почему прерывание узла больше не убивает посчитанное
Класс отказов, который надо убрать, выглядит так: узел забирают на середине шага, незавершённый шаг и всё посчитанное до него теряется, задача стартует заново. Лечится это разбиением расчёта на идемпотентные шаги с контрольными точками в объектном хранилище и корректной обработкой сигнала завершения: по уведомлению исполнитель дописывает промежуточный результат, снимает аренду задачи и только потом уходит. Повторный запуск продолжает с последней контрольной точки, а недостающие шаги догоняет устойчивый пул.
Доля пересчитанной работы падает со всего шага до последних минут — прерывание перестаёт быть инцидентом и становится штатным событием, которое держит под контролем доля прерываний и глубина очереди на дашборде.
Варианты выделения ресурсов: когда что подходит
Профиль пакетной обработки почти никогда не бывает однородным: часть заданий можно оборвать и перезапустить, часть держит состояние и координирует остальных. Поэтому выбор между прерываемыми и постоянными узлами решается не вкусом, а профилем нагрузки — и часто правильный ответ это их комбинация. Ниже три схемы, между которыми реально выбирают при развёртывании пула в Google Cloud.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Только прерываемые узлы (Spot VM) | Очереди без жёсткого срока; задачи идемпотентны, разбиты на короткие порции и умеют перезапускаться | Узел отзывается с коротким предупреждением; нужны контрольные точки, дробление работы и повторный вход без побочных эффектов |
| Только постоянные узлы | Задания с обещанным сроком, состояние в памяти, потоковые вычисления, общий доступ к одному ресурсу | Платите за простой между пиками; масштабирование пула вручную, пик держит лишние машины постоянно |
| Гибридная схема пула | Ядро держит состояние и координацию, а массовые пиковые задачи уходят на прерываемые | Сложнее в управлении: нужны правила размещения, разделение очередей и контроль версий образов между группами |
Выбор режима под профиль нагрузки
Решающий признак — что произойдёт с заданием при отзыве узла. Если задача идемпотентна и нарезана на короткие порции, отзыв стоит только перезапуска; если она пишет в один общий файл или держит состояние в памяти, отзыв ломает результат целиком. Второй признак — предсказуемость очереди: там, где важен обещанный срок, прерываемые узлы дают сбои именно в час пика.
Гибридная схема с ядром на постоянных узлах
Ядро пула выносим на постоянные узлы: планировщик, координатор заданий, брокер очереди, шлюз к хранилищу. Прерываемые узлы подключаются как рабочие и живут ровно столько, сколько нужно. Автоматическое масштабирование пула считаем по длине очереди и числу задач в работе, а не по средней загрузке — иначе пик уходит в постоянный парк.
Порядок внедрения пула: от аудита до передачи
Работа идёт этапами: каждый следующий шаг опирается на данные предыдущего, поэтому пул не приходится переделывать после запуска. Ниже — порядок внедрения с точками, где мы останавливаемся и согласуем результат с вашей командой.
Аудит нагрузки и профиль прерываний
Сначала снимаем фактическую картину: суточный график заданий, длительность одной задачи, чувствительность к повторному запуску. Отдельно собираем профиль прерываний — как часто облако забирает узлы Spot и что при этом происходит с очередью. Без этих данных расчёт числа узлов будет гаданием.
- Аудит нагрузки — разбираем очереди, типы заданий и требования к времени обработки.
- Профиль прерываний — считаем, какая доля задач выдерживает остановку узла и сколько времени нужно на повтор.
- Схема пула — состав узлов, запас, правила распределения заданий, хранение промежуточных результатов.
- Настройка пула — конфигурация, разметка узлов, автоматический перезапуск прерванных задач, привязка к очереди.
- Проверка отказоустойчивости — намеренно выключаем узлы и смотрим, как задачи возвращаются в очередь и восстанавливаются.
- Регламент и передача в эксплуатацию — метрики, оповещения, инструкции для дежурной смены, обучение команды.
Приёмочные проверки перед передачей
Приёмка — не отчёт, а серия управляемых отказов: массово выводим узлы и смотрим, что задачи не теряются и не считаются дважды, а очередь разбирается за ожидаемое время. Передаём пул вместе с регламентом, метриками и понятным порядком действий дежурной смены.
Состав поставки: конфигурации, политики, регламенты
Поставка по пулу на GCP — это не только работающая пакетная обработка, но и комплект артефактов, по которым команда заказчика сама меняет конфигурацию, разбирает сбои и передаёт дежурство. Всё лежит в репозитории заказчика и обновляется вместе с кодом — без устных договорённостей и знания, которое держится в голове одного инженера.
- Шаблоны конфигурации пула — параметры набора машин, правила масштабирования по длине очереди, лимиты на прерывания и порядок возврата к обычным машинам при дефиците ресурсов.
- Схема размещения узлов — какие зоны и типы машин отданы под разные классы заданий и как перераспределяется нагрузка, когда часть машин забирает платформа.
- Политики доступа — роли сервисных учётных записей, минимально необходимые права, разделение сред и запрет ручных правок пула в рабочие часы.
- Схема обработки заданий — разметка очереди на независимые части, повтор незавершённых фрагментов, требования к повторяемости операций записи.
- Регламент реагирования — пороги оповещений, порядок действий дежурного, критерии переключения обработки на резервный пул.
- Инструкции для дежурной смены — пошаговые сценарии: перезапуск обработки, снятие зависших заданий, проверка очереди и состояния пула.
- Описание типовых сбоев — разбор «симптом → причина → действие», собранный по итогам испытаний и первых недель работы.
- Документация по пулу — карта ресурсов, владельцы сервисов, порядок изменения конфигурации и журнал принятых решений.
Комплект считается принятым, когда дежурный инженер заказчика проходит по инструкциям сценарий отказа без нашей подсказки, а изменения в пул вносятся через те же шаблоны, что используются в основном контуре.
Кейс: пакетная обработка на прерываемых узлах
Проект: ночной пересчёт аналитических витрин — десятки тысяч коротких независимых заданий, результат нужен к началу рабочего дня. Пул держали на постоянных узлах, рассчитанных на пик: ночью они работали на пределе, а днём простаивали. Мы перевели пакетную обработку на прерываемые узлы Google Cloud: пул Spot VM с автоматическим масштабированием и распределением по нескольким зонам.
До и после
- Окно обработки: 9–11 часов → 4–5 часов.
- Одновременно выключаемые узлы: до 40% пула → 8–10% за счёт диверсификации по зонам и типам машин.
- Задания на повторный запуск: около трети → 2–3%.
Ключевое изменение — не сам тип узлов, а готовность к их исчезновению. Каждый шаг стал идемпотентным, промежуточные результаты пишутся в объектное хранилище контрольными точками, а узел получает сигнал остановки заранее и успевает корректно завершить текущую порцию. Прерываемые узлы в работе перестали быть риском: повторный запуск задания продолжается с последней контрольной точки, а не с нуля.
«Пока не появились контрольные точки, половина ночи уходила на перезапуски — теперь это несколько процентов заданий, и их не видно в утреннем отчёте», — инженер, вёл внедрение.
Окно пересчёта устойчиво влезает в ночь, а очередь сама добирает освободившиеся узлы вместо ожидания нового пула.
Чем прерываемые машины отличаются от постоянных узлов
Постоянный узел выключается по вашему сигналу: трафик снимается, соединения дренируются, процесс останавливается. Прерываемую машину провайдер отзывает сам, как только под обычные экземпляры освобождается ёмкость, — сигнал приходит заранее, но окно на аккуратное завершение измеряется десятками секунд. Поэтому режимы сравнивают по поведению при отзыве и по тому, что успевает сохранить задание, а не по стоимости владения.
| Критерий | Постоянные узлы | Прерываемые машины |
|---|---|---|
| Момент выключения | по вашему решению | по решению провайдера |
| Окно на завершение | не ограничено | десятки секунд после сигнала |
| Пригодная нагрузка | пользовательские сервисы, брокеры сообщений, хранилища состояния | пакетные задания, пересчёты, разбор логов |
| Защита результата | сессия и состояние на диске | контрольные точки, внешнее хранилище |
| Возврат в пул | ручной ввод и вывод | пересоздание из шаблона |
Вывод для планирования: прерываемым узлам отдают разовые и пересчётные задачи — всё, что режется на короткие независимые порции и повторяется без побочных эффектов. Долгие транзакции, хранилища состояния и интерактивные сервисы на них не размещают: отзыв в середине такой операции обходится дороже любого выигрыша от режима.
Защита строится на трёх уровнях. Обработчик сигнала дописывает контрольную точку и снимает машину из пула, очередь хранит признак завершённой порции, а повторный запуск идемпотентен — пересчёт той же порции не даёт дублей. В смешанном пуле постоянные узлы держат оркестратор и хвост очереди, а прерываемые разбирают основную массу порций и пересоздаются из шаблона по меткам.
Механика отзыва, окно уведомления и правила автоматического пересоздания описаны у провайдера: Google Cloud публикует официальное описание прерываемых машин — с ним и сверяют тайминги обработчиков.
Ограничения, лимиты и типовые сбои пула
Пул на Spot-узлах ломается не «в среднем», а конкретными сценариями: отзыв узла посреди записи части, упор в квоту на машины в регионе, повторный запуск уже обработанных частей после перезапуска. Ниже — частые вопросы, которые всплывают при разборе ограничений пула и типовых сбоев.
Что происходит с заданием при выключении узла?
Обработчик ловит сигнал остановки, дописывает текущую часть атомарно — перезапуск берёт только незавершённое. Части, не успевшие закрыться в окне до выключения, пересчитываются.
Можно ли держать обычные и Spot-узлы в одном пуле?
Да, но лучше разными пулами или метками узлов: иначе планировщик поставит критичный шаг на узел, который вот-вот отзовут.
Как избежать повторной обработки готовых частей?
Идемпотентный ключ на часть и журнал готовых задач: обработчик сверяется с ним перед стартом, и повторный проход стоит только чтения.
Какую нагрузку не стоит переводить на Spot?
Всё, что держит состояние дольше отзыва узла: базы данных, брокеры сообщений, координаторы и потоковая запись данных — их размещают на постоянных узлах, а на прерываемые отдают только пересчётные и разовые порции работы.
