Настройка Spot/Preemptible Instances для batch-задач

Spot инстансы обрываются на середине пакетного расчёта

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

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

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

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

Эффект от управляемых прерываний в пакетных расчётах

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

Эффект считаем тремя величинами. Время простоя на перезапуск сокращается до минут — исходные данные не перечитываются с нуля, поднимается только упавшая подзадача. Доля доведённых до конца задач выходит на 99% и выше даже при частых отзывах, потому что прогресс фиксируется постоянно, а не в конце прогона. Утилизация мощностей растёт кратно: прерываемые ресурсы дешевле простаивающих, и очередь больше не ждёт освобождения выделенного узла.

Снимается и целый класс отказов — «ресурс отозвали, пакет упал, считаем заново». Контрольные точки пишутся асинхронно и не тормозят счёт, повторный запуск идемпотентен, а оркестратор вроде Kubernetes сам перепланирует подзадачу на доступной ёмкости. Время выполнения пакета становится предсказуемым: бюджет на перезапуски известен заранее, и сроки не сдвигаются от того, что часть узлов отозвали в середине прогона.

Spot инстансы против выделенных и зарезервированных

Размещение пакетных задач редко сводится к одному режиму: узкое место — не тип инстанса, а раскладка нагрузки по пулам. Разница между пулами ровно в одном: что происходит, когда ресурс отзывают, и кто отвечает за перезапуск — вы или провайдер.

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

Порядок внедрения: от разбора нагрузки до передачи

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

1. Аудит нагрузки. Считаем очередь, распределение по длительности и ресурсам, помечаем задания, которые перезапускаются без потерь, и те, которым нужна контрольная точка.
2. Схема размещения. Определяем соотношение прерываемых и обычных машин, раскладываем по зонам доступности, задаём лимит на одновременный отзыв.
3. Настройка правил. Описываем, какие типы машин берём, как реагируем на дефицит ёмкости и рост стоимости, как быстро возвращаем задание в очередь.
4. Проверка отказов. Намеренно отзываем узлы под нагрузкой: укладывается ли задание в свой лимит на сохранение состояния, нет ли дублей и потерянных результатов.
5. Наблюдаемость. Выводим метрики — доля прерванных заданий, время до перезапуска, объём пересчётов. По ним видно, где правила работают против нас.
6. Передача в эксплуатацию. Инструкция дежурному на типовые отказы, алерты на аномалии, регламент изменения лимитов и обучение смены.

Первые недели сверяем фактические метрики с расчётными и подкручиваем пороги — после этого конфигурация живёт без постоянного вмешательства инженера.

Комплект конфигураций и регламентов на выходе

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

• Конфигурации пулов и заданий — описания прерываемых и постоянных узлов плюс манифесты пакетных заданий с ресурсами, приоритетами и предельным временем работы. Из них сразу видно, какая нагрузка вообще допускает остановку.
• Схема размещения — карта: какие задания идут на временные мощности, какие остаются на постоянных, и правила меток, не пускающие критичные сервисы на узлы, которые могут исчезнуть.
• Политики доступа — роли для дежурного и разработчиков: кто меняет размер пула, кто снимает резерв, кто читает журнал изменений. Массовое освобождение узлов становится управляемым действием, а не случайностью.
• Регламент перезапуска — обработка уведомления о прерывании: сколько времени даётся на завершение, куда пишутся промежуточные результаты, с какого шага задание продолжается после повтора.
• Документация — как пересобрать контур с нуля, что делать при одновременном освобождении узлов в одной зоне и как быстро вернуться на постоянные мощности.
• Точки контроля — метрики и пороги: доля прерванных заданий, время до повторного старта, доля прошедших с первой попытки. По ним видно, что схема держится и после ваших правок.

Комплект живёт вместе с инфраструктурой: меняются правила размещения — обновляется и регламент. Опишите задачу — вернёмся с оценкой и планом.

Кейс: расчёты на прерываемых ресурсах без потерь

Что было

Расчёты шли пакетом на несколько сотен задач в ночном окне, результат нужен к утру. Узлы держали выделенными: между запусками они простаивали, зато любой сбой разбирали вручную — инженер выяснял, какие шаги успели записать результат, и перезапускал ветку с начала. Точечные запуски на Spot инстансах заканчивались одинаково: отзыв ресурса приходился на середину пакета, и до 15% задач теряли результат.

Что изменили

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

Что стало

• Доля задач, терявших результат при отзыве ресурса: 15% → 0.
• Время повторного запуска: 25–30 минут ручной работы → 40 секунд автоматически.
• Ручные вмешательства: 3–5 за ночь → ни одного за квартал наблюдений.
• Ночное окно сократилось на треть: прерываемые узлы подхватывают пик, который раньше ждал освобождения выделенных.

Чем прерываемый инстанс отличается от зарезервированного

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

Гарантии доступности и приоритет отзыва — два ключевых различия. При дефиците ёмкости провайдер сначала освобождает прерываемые машины и лишь потом смотрит на зарезервированные. Отзыв приходит коротким предупреждением — у Amazon Web Services около двух минут, — за которые приложение должно сохранить результат и корректно завершиться.

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

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

Частые технические сомнения перед стартом

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

Придётся ли переписывать код задач?

Обычно нет. Нужны обработка сигнала об отзыве, точки сохранения прогресса и повторный запуск, который не дублирует результат. Это локальные правки в запуске и сохранении, бизнес-логика остаётся прежней.

Совместимо ли это с текущим стеком и хранилищем?

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

Кто отвечает за контроль выполнения?

Конфигурацию, политику очередей и мониторинг ведём мы, логику задачи — вы. Контроль держим на трёх метриках: доля прерываний, время до перезапуска, доля потерянных фрагментов.

Что если отзывов слишком много и прогон не укладывается в окно?

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

Обсудим вашу задачу и вернёмся с оценкой и планом

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

Дальше работа идёт по шагам:

• Разбираем профиль задач: длительность, чувствительность к потере промежуточного результата, требования к контрольным точкам.
• Делим нагрузку на ту, что безопасно отдавать на прерываемые машины, и ту, что должна оставаться на постоянных.
• Собираем состав работ: очереди, политики перезапуска, сбор логов, оповещения о массовом отзыве машин.
• Согласуем критерии приёмки — доля заданий, доведённых до конца без ручного вмешательства.
• Фиксируем порядок старта: сначала одна очередь, затем расширение на остальные.
• Смотрим результат на реальном потоке и при необходимости правим правила отбора машин.
• Передаём документацию и доступы вашей команде, чтобы запуск новых очередей не требовал нас.

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