Почему Spot Fleet AWS прерывает пакетную обработку
Spot Fleet AWS собирает пул из свободной спотовой ёмкости и держит его, пока цена не уйдёт выше порога, заданного в запросе. Как только свободных машин у провайдера становится меньше, ёмкость отзывается: узлу дают короткое окно, около двух минут, и забирают его. Сервису, который отвечает на запросы, этого хватает на дренаж соединений, а пакетной обработке, где одна задача считается десятки минут, такое окно не даёт ничего.
Задача, которая в момент отзыва считалась на узле, обрывается на середине. Промежуточные результаты лежат в памяти или на локальном томе и уходят вместе с инстансом, если обработка не пишет контрольные точки во внешнее хранилище, — а по умолчанию не пишет. Работа не продолжается с места обрыва, а начинается заново.
Дальше сбой разворачивается каскадом. Задания уже выданы рабочим узлам, которых больше нет, брокер очереди не получает подтверждения и держит их до истечения времени ожидания — зависшая очередь задач растёт, новые задания ждут, а планировщик тем временем пытается добрать пул и попадает под следующий отзыв. Потеря промежуточных результатов умножается на повторные проходы: часть пакета считается по два-три раза, и общее время обработки набора уезжает далеко за расчётное.
Отсюда типичная картина: ночной пересчёт не успевает к утру, отчёты приходят с задержкой, дежурный раз за разом добирает ёмкость вручную. Проблема не в самой спотовой ёмкости, а в том, что задание не спроектировано под её отзыв. Разбираем, как это закрывается.
Что даёт управляемый пул спотовой ёмкости
Управляемый пул спотовой ёмкости в Amazon Web Services — это не «включить спот и ждать», а набор правил: сколько семейств узлов и зон доступности участвуют, по какой стратегии берётся свободная ёмкость и что делать в момент её отзыва. Мы фиксируем целевую долю спота в общем пуле, а остаток держим на обычных узлах — окно обработки не встаёт целиком, даже если спотовые машины уходят почти одновременно.
Первый измеримый эффект — время прохождения окна обработки. Когда пул привязан к одной зоне и одному типу узлов, значительная часть окна уходит на ожидание освободившейся ёмкости; после распределения по нескольким зонам тот же объём очереди закрывается заметно быстрее, и график обработки перестаёт дрейфовать к утру.
Второй — доля успешно завершённых задач. Отозванный в середине вычисления узел раньше означал перезапуск с нуля или испорченный результат; теперь задача получает предупреждение об отзыве, снимает контрольную точку и отдаёт незавершённую часть другой машине. Класс отказов «внезапный отзыв узла» просто исчезает из журнала сбоев: вместо разбора ночных инцидентов команда смотрит на одну метрику — долю завершённых задач.
«Раньше каждое утро начиналось с разбора, какие окна не доехали, — говорит наш инженер. — Сейчас пул сам перекладывает задачи, и в отчёте стабильно одна и та же доля успешных — любое расхождение видно сразу».
Варианты распределения спотовой ёмкости в AWS
Спотовую ёмкость нельзя запрашивать одним пулом в одной зоне доступности: при дефиците нужного типа экземпляров планировщик прервёт часть задач, и очередь встанет. Рабочая схема — распределять запрос сразу по нескольким зонам и семействам инстансов: дефицит приходит в них в разное время, поэтому суммарная доступность ёмкости выше, чем у любого отдельного пула.
Выбор между тремя подходами сводится к одному вопросу: какая доля работы обязана дойти до конца, а что допустимо прервать и перезапустить. Ниже — сравнение по этому признаку.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полностью спотовый пул | Прерываемая обработка: разбор логов, пересчёт индексов, прогоны моделей, пакетные задания без жёсткого срока | Нет гарантии ёмкости — при всплеске спроса задачи ждут в очереди. Прерывание посреди шага требует контрольных точек и повторного запуска, который не портит результат |
| Смешанный пул с базовой долей постоянных ресурсов | Есть этап, который обязан работать всегда: координатор очереди, база метаданных, приём и сборка результатов | Постоянная часть простаивает в спокойные часы; нужно следить, чтобы спотовая доля росла, а базовая не раздувалась «на всякий случай» |
| Пул с резервом в нескольких зонах доступности | Жёсткое окно завершения и требование к отказоустойчивости: одна зона недоступна — расчёт продолжается в остальных | Сложнее настройка: стратегию распределения и вес зон подбирают под профиль нагрузки, иначе резерв простаивает |
На практике чаще берут смешанный пул с резервом в двух-трёх зонах: базовая доля держит координацию и завершение заданий, а основную часть работы забирает спотовая ёмкость. Дальше разбираем, как это разложить по параметрам запроса.
Этапы внедрения: от аудита нагрузки до передачи
Порядок этапов выстроен так, чтобы до первого запуска стало ясно, где пул упрётся в лимиты и что произойдёт, когда провайдер заберёт инстансы. Начинаем не с конфигурации, а с расчёта того, что инфраструктура должна выдержать.
-
Аудит нагрузки. Собираем фактическое потребление: длительность задач, пиковую параллельность, требования к памяти и диску на единицу работы. Результат — целевой размер пула и запас на переподбор.
-
Профиль прерываний. Разбираем историю отзыва ресурсов по типам инстансов и зонам доступности: как часто приходит уведомление, сколько времени остаётся до остановки, совпадает ли это с пиками спроса. Отсюда видно, какие семейства инстансов допустимы, а какие дадут постоянные перезапуски.
-
Схема пула. Конфигурация Spot Fleet: несколько пулов по типам и зонам, стратегия распределения, доля устойчивых инстансов как страховка от дефицита. Фиксируем, какие задачи прерывать можно, а какие — нет.
-
Правила перезапуска. Настраиваем обработку уведомления: сохранение промежуточного результата, корректное завершение процесса, возврат задачи в очередь. Проверяем, что повторный запуск не дублирует результаты.
-
Проверка отработки сбоя. Имитируем отзыв инстансов под нагрузкой: укладывается ли обработка в отведённое окно, не теряются ли данные, восстанавливается ли пул до целевого размера.
-
Передача регламентов. Отдаём конфигурацию как код, порядок диагностики, метрики и пороги оповещений, действия при дефиците мощностей.
Что остаётся у команды после внедрения
После внедрения логика работы с прерываемыми инстансами остаётся в репозитории и документации, а не в голове инженера, который настраивал пул. Ниже — перечень артефактов, которые команда получает на руки и может проверить на приёмке.
- Конфигурации пула — декларативные файлы с целевой ёмкостью, распределением по типам инстансов и зонам доступности, стратегией выбора и правилами замены. Правки проходят ревью, стенд и рабочая среда собираются из одного источника.
- Политики доступа — роли для узлов, планировщика и операторов с минимально необходимыми правами, отдельные учётные данные для ручных вмешательств, секреты вынесены из конфигов и шаблонов запуска.
- Схемы инфраструктуры — очередь, пул, хранилище результатов, сетевые границы и точки, где обрабатывается уведомление о прерывании инстанса, с указанием ответственного компонента.
- Правила контроля очереди — приоритеты заданий, лимиты параллелизма, разбиение крупных заданий на короткие порции с сохранением промежуточного результата, порог, при котором пул расширяется вместо потери задач.
- Регламент при сбое — пошаговый порядок на случай массового изъятия инстансов: как перезапускается незавершённая порция, как проверяется целостность уже посчитанных результатов, кто получает уведомление.
- Мониторинг — панель и оповещения по глубине очереди, доле успешно завершённых заданий, времени ожидания в очереди и частоте прерываний.
- Документация и передача — инструкция для дежурного, порядок изменения конфигураций и разбор реальных инцидентов на созвоне с командой.
Команда может менять размер пула, приоритеты и пороги самостоятельно, не возвращаясь к нам за каждой правкой.
Кейс: пакетный конвейер, падавший каждые полчаса
Конвейер на Spot Fleet обрабатывал десятки тысяч задач в сутки и держался на пуле из одного типа машин в одной зоне доступности. Когда облако забирало ёмкость, вытеснялись сразу все узлы: очередь вставала, часть задач терялась на середине шага, остальные перезапускались вручную. Дежурный тратил на восстановление 25–40 минут, и такие остановки случались каждые полчаса в часы пика.
Что перестроили
Пул развели по нескольким типам машин и зонам — вытеснение одной группы больше не роняет конвейер целиком. Длинные задания разбили на короткие шаги с сохранением состояния: прерванный шаг возвращается в очередь и продолжается с последней контрольной точки, а не с начала. Правило выбора ёмкости учитывает и доступность, и цену, а задачи, чувствительные к обрыву, уходят на резервный пул.
| Метрика | До | После |
|---|---|---|
| Доля успешных проходов | 71% | 99,2% |
| Потерянные задачи за сутки | до 400 | единицы, и те из очереди повторов |
| Время перезапуска после вытеснения | 25–40 минут вручную | 2–3 минуты автоматически |
| Вмешательства дежурного в сутки | больше 30 | 0–1 |
| Полный проход конвейера | 6–9 часов с простоями | около 4 часов без остановок |
СеверТранс Логистик: «Раньше мы дежурили у монитора и перезапускали очередь руками. Теперь о сбое узнаём из отчёта, а не от смежного отдела — конвейер дожимает сам».
Чем спотовый пул отличается от смешанного и автомасштабирования?
Это не три замены друг друга, а три уровня одной схемы. Спотовый пул в AWS — правило выбора ёмкости внутри группы, смешанный пул — та же группа, но с несколькими типами инстансов, автомасштабирование — управление числом узлов. Их часто ставят как альтернативы, хотя на практике одно настраивают поверх другого.
Пул с одной стратегией выбора ёмкости работает, пока его тип инстанса доступен: при отзыве выпадает весь запас сразу, и очередь задач встаёт. Смешанный пул размазывает риск — несколько типов и зон доступности со взвешенной ёмкостью, поэтому отзыв части узлов не роняет кластер. Плата за это — разнородные узлы, и планировщик должен упаковывать задачи с разными требованиями к диску и памяти.
Автомасштабирование решает другую задачу: держит число воркеров под спросом по метрике длины очереди, со step scaling и cooldown. Отзыв ёмкости оно не отменяет — уведомление приходит за считаные минуты, и задача без чекпоинта перезапускается с нуля. Спотовый пул без обработчика уведомлений и плавного вывода узлов просто превращает выигрыш в повторную работу.
Граница применимости проходит по характеру нагрузки. Батч с идемпотентными шагами и чекпоинтами живёт на споте, а база данных, singleton-сервис и длинный расчёт без сохранения состояния — нет. Автомасштабирование не спасает и там, где узкое место не в числе воркеров, а во внешней зависимости: лимит запросов к источнику или скорость хранилища — новые узлы лишь добавят конфликтов за один ресурс.
Ограничения спотовых пулов: прерывания, квоты, ёмкость
Спотовая ёмкость обходится дешевле и её обычно много, но у пулов есть физика, которую не обойти настройками. Отзыв инстанса приходит с коротким уведомлением, квота на семейство ограничивает одновременный набор, а свободная ёмкость перетекает между зонами доступности в течение дня. Ниже — частые сомнения перед переносом пакетной обработки на спотовые пулы.
Что происходит с задачами, когда инстанс отзывают?
Уведомление об отзыве приходит заранее: обработчик на узле переводит его в режим завершения, пишет контрольную точку шага в общее хранилище и возвращает задачу в очередь — её подхватывает другой узел. Это работает, если шаг идемпотентен и разбит на короткие части: тогда теряется один фрагмент расчёта, а не всё задание.
Можно ли полностью исключить прерывания?
Нет — спотовая ёмкость всегда возвращается провайдеру по требованию, долю отзывов можно только снизить. Помогают выбор пулов с наибольшим остатком, распределение по нескольким семействам инстансов и зонам, запас под пики. Для заданий с жёстким сроком держат небольшой резервный пул по требованию, который включается при нехватке спота и страхует хвост очереди.
Как делить нагрузку по зонам доступности?
Чем шире пул по зонам, тем меньше шанс, что дефицит ёмкости в одной зоне остановит всю обработку. Но квота на вычислительные ресурсы считается на регион и на семейство инстансов, поэтому новая зона упирается в тот же лимит — повышение запрашивают заранее. И чем шире география, тем больше обмена данными между зонами при сборке результатов.
Обсудим вашу нагрузку и профиль прерываний
Чтобы вернуться с оценкой и планом, а не с общими словами, нужен минимум входных данных. Доступы и внутренние регламенты на этом шаге не требуются — достаточно профиля нагрузки и требований к срокам.
- Профиль нагрузки: сколько пакетных задач запускается в сутки, средняя и пиковая параллельность, объём обрабатываемых данных.
- Требования к срокам: есть ли жёсткое окно завершения обработки или остаток допустимо перенести на следующее окно.
- Профиль прерываний: какую долю задач можно перезапустить, а где перезапуск недопустим и нужна контрольная точка.
- Текущее состояние: используются ли уже спотовые ёмкости, какие семейства инстансов и зоны доступности задействованы.
- Работа с данными: откуда задача читает входные данные и куда пишет результат, есть ли зависимость от общего хранилища.
- Ограничения: квоты аккаунта, требования по изоляции, окна обслуживания, правила маркировки ресурсов.
- Критерии приёмки: по каким метрикам вы поймёте, что очередь разгружается, а стоимость обработки перестала расти.
Опишите задачу — мы разберём, как нагрузка ложится на пул спотовых ёмкостей, и предложим порядок работ. После разбора вернёмся с оценкой и планом: схема распределения ёмкости по зонам, стратегия возврата прерванных задач, этапы внедрения и точки контроля на каждом из них.
