Чому 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-сервіс і довгий розрахунок без збереження стану — ні.
Автомасштабування не рятує й там, де вузьке місце не в кількості воркерів, а в зовнішній залежності: ліміт запитів до джерела або швидкість сховища — нові вузли лише додадуть конфліктів за один ресурс.
Обмеження спотових пулів: переривання, квоти, ємність
Спотова ємність обходиться дешевше, і її зазвичай багато, але в пулів є фізика, яку не обійти налаштуваннями. Відкликання інстанса надходить із коротким повідомленням, квота на родину обмежує одночасний набір, а вільна ємність перетікає між зонами доступності протягом дня. Нижче — часті сумніви перед перенесенням пакетної обробки на спотові пули.
Що відбувається із завданнями, коли інстанс відкликають?
Повідомлення про відкликання надходить заздалегідь: обробник на вузлі переводить його в режим завершення, пише контрольну точку кроку в спільне сховище й повертає завдання в чергу — його підхоплює інший вузол.
Це працює, якщо крок ідемпотентний і розбитий на короткі частини: тоді губиться один фрагмент розрахунку, а не все завдання.
Чи можна повністю виключити переривання?
Ні — спотова ємність завжди повертається провайдеру на вимогу, частку відкликань можна лише знизити. Допомагають вибір пулів із найбільшим залишком, розподіл за кількома родинами інстансів і зонами, запас під піки.
Для завдань із жорстким терміном тримають невеликий резервний пул на вимогу, який вмикається за нестачі спота й страхує хвіст черги.
Як ділити навантаження за зонами доступності?
Чим ширший пул за зонами, тим менший шанс, що дефіцит ємності в одній зоні зупинить всю обробку. Але квота на обчислювальні ресурси рахується на регіон і на родину інстансів, тому нова зона впирається в той самий ліміт — підвищення запитують заздалегідь. І чим ширша географія, тим більше обміну даними між зонами під час збирання результатів.
Обговоримо ваше навантаження та профіль переривань
Щоб повернутися з оцінкою та планом, а не із загальними словами, потрібен мінімум вхідних даних. Доступи та внутрішні регламенти на цьому кроці не потрібні — достатньо профілю навантаження й вимог до строків.
- Профіль навантаження: скільки пакетних завдань запускається за добу, середня та пікова паралельність, обсяг оброблюваних даних.
- Вимоги до строків: чи є жорстке вікно завершення обробки або залишок допустимо перенести на наступне вікно.
- Профіль переривань: яку частку завдань можна перезапустити, а де перезапуск неприпустимий і потрібна контрольна точка.
- Поточний стан: чи вже використовуються спотові ємності, які родини інстансів і зони доступності задіяні.
- Робота з даними: звідки завдання читає вхідні дані й куди пише результат, чи є залежність від спільного сховища.
- Обмеження: квоти акаунта, вимоги щодо ізоляції, вікна обслуговування, правила маркування ресурсів.
- Критерії приймання: за якими метриками ви зрозумієте, що черга розвантажується, а вартість обробки перестала зростати.
Опишіть завдання — ми розберемо, як навантаження лягає на пул спотових ємностей, і запропонуємо порядок робіт.
Після розбору повернемося з оцінкою та планом: схема розподілу ємності за зонами, стратегія повернення перерваних завдань, етапи впровадження та точки контролю на кожному з них.
