Налаштування Spot/Preemptible Instances для пакетних завдань

Spot-інстанси обриваються на середині пакетного розрахунку

Переривні інстанси — основа пакетної обробки: платформа віддає їх під розрахунок зі значною знижкою і має право забрати назад у будь-який момент.

Саме звідси береться втрата прогресу: монолітний перерахунок тримає проміжні результати в пам'яті процесу, а відкликання ресурсу вбиває цей процес повністю. Завдання, яке рахувалося шість годин, після перезапуску стартує з першого рядка.

Повідомлення про відкликання надходить за десятки секунд — цього достатньо, щоб коректно закрити поточний крок, але не щоб зберегти весь стан.

Гірше те, що ресурс забирають не по одному вузлу: якщо група зібрана в одному пулі, відкликання надходить пакетом, і одночасно випадає половина парку. Черга зупиняється, а частина завдань залишається в невизначеному стані — частина перевірок пройдена, частина ні.

У повсякденній експлуатації це виглядає так: нічний перерахунок не вкладається у вікно, бо кожен обрив відкочує роботу на кілька годин назад; повторні запуски дублюють записи, якщо операції не ідемпотентні; простій розрахунків зростає, а звіти надходять із затримкою.

Інженери починають тримати критичні завдання на постійних ресурсах, і виграш від переривних з'їдається.

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

Ефект від керованих переривань у пакетних розрахунках

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

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

Ефект вважаємо трьома величинами. Час простою на перезапуск скорочується до хвилин — вихідні дані не перечитуються з нуля, піднімається лише підзавдання, що впало.

Частка доведених до кінця завдань сягає 99% і вище навіть за частих відкликань, бо прогрес фіксується постійно, а не в кінці прогону. Утилізація потужностей зростає кратно: переривні ресурси дешевші за простоюючі, і черга більше не чекає звільнення виділеного вузла.

Знімається й цілий клас відмов — «ресурс відкликали, пакет упав, рахуємо заново». Контрольні точки пишуться асинхронно й не гальмують обчислення, повторний запуск ідемпотентний, а оркестратор на кшталт Kubernetes сам перепланує підзавдання на доступній ємності.

Час виконання пакета стає передбачуваним: бюджет на перезапуски відомий заздалегідь, і терміни не зсуваються через те, що частину вузлів відкликали в середині прогону.

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

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

Поєднують так: база йде на зарезервованих потужностях, критичні стадії — на виділених, хвіст і пікові прогони — на переривних. Планувальник зберігає контрольні точки й повторний запуск, тому відкликання інстансу втрачає останній крок, а не весь прогін.

Частка переривних у розрахунку сягає двох третин — за умови, що завдання ідемпотентні й уміють продовжуватися з останньої контрольної точки.

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

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

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

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

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

Що залишається у замовника — не «налаштовані переривні машини», а повторюваний контур: його можна передати черговій зміні, розгорнути заново й перевірити. Нижче комплект, який ми віддаємо разом із працюючою системою; кожен пункт закриває свій клас збоїв.

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

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

Кейс: розрахунки на переривних ресурсах без втрат

Що було

Розрахунки йшли пакетом на кілька сотень завдань у нічному вікні, результат потрібен був до ранку.

Вузли тримали виділеними: між запусками вони простоювали, зате будь-який збій розбирали вручну — інженер з'ясовував, які кроки встигли записати результат, і перезапускав гілку з початку.

Точкові запуски на Spot-інстансах закінчувалися однаково: відкликання ресурсу припадало на середину пакета, і до 15% завдань втрачали результат.

Що змінили

Пакет розбили на ідемпотентні кроки з контрольними точками в об'єктному сховищі, а чергу збірки перевели на Kubernetes з окремим пулом переривних вузлів.

Відкликання ресурсу перехоплює керівний компонент: завдання повертається в чергу з останньої контрольної точки, а крок, який відкликають занадто часто, автоматично йде на звичайний вузол. Ручний розбір залишився лише для двох кроків, де зберегти проміжний результат неможливо.

Що стало

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

Чим переривний інстанс відрізняється від зарезервованого

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

Гарантії доступності та пріоритет відкликання — дві ключові відмінності. При дефіциті ємності провайдер спершу звільняє переривні машини й лише потім дивиться на зарезервовані.

Відкликання надходить коротким попередженням — у Amazon Web Services близько двох хвилин, — за які застосунок має зберегти результат і коректно завершитися.

Розрахунок, який іде годинами без проміжних збережень, на переривному інстансі втрачає прогрес при кожному відкликанні.

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

На практиці беруть змішану схему: вузли управління й усе, що тримає стан, — на зарезервованих машинах, а масовий розрахунок — на переривних із автоперезапуском.

Часті технічні сумніви перед стартом

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

Чи доведеться переписувати код завдань?

Зазвичай ні. Потрібні обробка сигналу про відкликання, точки збереження прогресу й повторний запуск, який не дублює результат. Це локальні правки в запуску та збереженні, бізнес-логіка залишається незмінною.

Чи сумісно це з поточним стеком і сховищем?

Запуск іде в тих самих образах, що й на постійних машинах, обмежень за мовою немає. Окремо перевіряємо доступ до сховища й секретів, мережеві правила та наявність місць для збереження проміжних даних.

Хто відповідає за контроль виконання?

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

Що якщо відкликань занадто багато і прогін не вкладається у вікно?

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

Обговоримо ваше завдання і повернемося з оцінкою та планом

Для старту розмови достатньо опису навантаження: чим запускаються пакетні завдання, скільки їх за добу, який у кожного граничний строк і що відбувається при відкликанні віртуальної машини.

Логи минулих запусків, конфігурація кластера й список сервісів, з якими завдання обмінюються даними, скорочують обговорення до однієї зустрічі — за ними видно, де навантаження рветься при перериванні.

Далі робота йде за кроками:

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

Обговоримо завдання — надішліть опис навантаження й те, що вже є. Повернемося з оцінкою та планом: які кроки беремо на себе, що потрібно від вашого боку й коли буде видно перший результат.