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?
Усе, що тримає стан довше за відкликання вузла: бази даних, брокери повідомлень, координатори та потоковий запис даних — їх розміщують на постійних вузлах, а на переривні віддають лише перерахункові та разові порції роботи.
