Налаштування Spot/Preemptible Instances для batch-завдань

Без Spot-інстансів batch-обробка в хмарі коштує в 3–5 разів дорожче. Клієнти часто переплачують за on-demand ресурси, які простоюють між завданнями. Ми, як інженери, вже понад 5 років використовуємо Spot/Preemptible Instances для зниження витрат на 60–80% без втрати надійності. Нижче — конкретні методи, конфігурації та готові рішення, перевірені на десятках проєктів.

Які завдання ефективніше виконувати на Spot-інстансах?

Spot-інстанси ідеальні для stateless batch-завдань: CI/CD воркери (кожен білд ізольований), обробка зображень і відео (transcoding, resize), ML training з checkpoint-based підходами, парсинг та ETL-пайплайни, рендеринг, антивірусні скани, аналітичні запити. Вони не підходять для stateful баз даних (ризик втрати даних), веб-серверів без швидкого заміщення та сервісів із жорстким SLA без DR-стратегії.

Як Spot Fleet знижує ймовірність переривань?

Ключ до стабільності — Spot Fleet із кількома типами інстансів. Якщо m5.xlarge недоступний, Fleet підхопить m5a.xlarge або c4.xlarge. Використовуємо стратегію capacityOptimized — вона обирає пули з найбільшою вільною ємністю, знижуючи ймовірність переривання. Приклад конфігурації:

{ "SpotFleetRequestConfig": { "AllocationStrategy": "capacityOptimized", "TargetCapacity": 10, "LaunchTemplateConfigs": [ { "LaunchTemplateSpecification": {"LaunchTemplateId": "lt-xxx", "Version": "1"}, "Overrides": [ {"InstanceType": "m5.xlarge", "WeightedCapacity": 1}, {"InstanceType": "m5a.xlarge", "WeightedCapacity": 1}, {"InstanceType": "m4.xlarge", "WeightedCapacity": 1}, {"InstanceType": "c5.xlarge", "WeightedCapacity": 1} ] } ] } } 

Чому checkpointing критично важливий?

Spot-інстанси можуть бути зупинені в будь-який момент. Без checkpointing втрата прогресу робить їхню економію безглуздою. Реалізація механізму збереження стану дозволяє перезапускати завдання з останньої збереженої точки, мінімізуючи втрати. На практиці це дає до 95% корисного часу виконання навіть при частих перериваннях.

Як правильно обробити Spot Interruption Notice?

За 2 хвилини AWS надсилає metadata-подію (детальніше в документації AWS). Застосунок має опитувати endpoint і при сигналі переривання зберігати checkpoint. У коді нижче — реалізація на Python із graceful exit:

import requests import signal import sys def check_spot_interruption(): """Викликати кожні 5 секунд із воркера""" try: response = requests.get( 'http://169.254.169.254/latest/meta-data/spot/interruption-notice', timeout=1 ) if response.status_code == 200: return True # Переривання очікується except requests.exceptions.RequestException: pass return False class BatchWorker: def process_task(self, task): # Checkpoint кожні N елементів for i, item in enumerate(task.items): if i % 100 == 0 and check_spot_interruption(): self.save_checkpoint(task.id, i) sys.exit(0) # Graceful exit, завдання буде перезапущено self.process_item(item) task.mark_complete() 

Етапи обробки переривання:

1. Опитування endpoint метаданих кожні 5 секунд.
2. При отриманні сигналу — збереження checkpoint (наприклад, у S3 або Redis).
3. Graceful exit з кодом 0, щоб черга (SQS) не вважала завдання таким, що впало.

Також можна використовувати AWS EventBridge для автоматизації: подія → Lambda → збереження checkpoint, видалення інстанса з пулу, повернення завдання в чергу.

Що таке Karpenter і як він керує Spot-вузлами?

Karpenter (AWS) автоматично обирає тип інстанса (включаючи Spot) та обробляє переривання: при отриманні сповіщення він cordon та drain ноду, переплануючи под. Приклад Provisioner:

apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: batch-workers spec: requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot", "on-demand"] - key: "node.kubernetes.io/instance-type" operator: In values: ["m5.xlarge", "m5a.xlarge", "m4.xlarge", "c5.xlarge"] taints: - key: batch effect: NoSchedule consolidation: enabled: true 

Порівняння стратегій: Karpenter порівняно з ручним управлінням Spot Fleet скорочує час реагування на переривання вдвічі за рахунок автоматичного cordon та drain. Spot Fleet — простота, але вимагає ручного керування шаблонами. Karpenter — динамічне масштабування та автоматичне відновлення, але складніший у налаштуванні. Обидва дають економію 60–80%.

GCP Preemptible / Spot VMs: нюанси

GCP Preemptible: максимум 24 години життя, сповіщення за 30 секунд. Spot VMs — без ліміту 24 годин, тільки за availability. Створення через gcloud:

gcloud compute instances create batch-worker \ --machine-type=n2-standard-4 \ --provisioning-model=SPOT \ --instance-termination-action=STOP \ --zone=us-central1-a 

Тут також застосовується checkpointing, але з урахуванням коротшого сповіщення (30 секунд). Реалізація аналогічна AWS, але з опитуванням через GCP metadata server.

Що входить у налаштування під ключ?

• Аудит поточних workloads і вибір відповідних
• Проєктування Spot Fleet / Provisioner із кількома типами інстансів
• Реалізація checkpointing та обробки переривань (код на Python/Go/Java)
• Інтеграція з EventBridge, Lambda, чергами (SQS, RabbitMQ)
• Налаштування моніторингу (CloudWatch, Prometheus) та сповіщень
• Документація та навчання команди
• Тестування із симуляцією переривань
• Post-launch підтримка 1 місяць

Терміни орієнтовно

Вартість розраховується індивідуально під ваш обсяг і складність. Замовити оцінку — просто напишіть нам. Ми гарантуємо прозоре ціноутворення та фіксацію обсягу робіт.

Реальна економія на цифрах

Типова економія становить 60–80% порівняно з on-demand. Надбавка за переривання та перезапуски — 5–15% часу. На одному з проєктів із ML training на p3.2xlarge економія досягла 70%. Наші клієнти підтверджують: грамотна реалізація checkpoint окупається за 1–2 місяці. Зв'яжіться з нами для розрахунку економії під ваше навантаження. Замовте аудит ваших batch-завдань — наші інженери з 5+ років досвіду та сертифікаціями AWS/GCP допоможуть знизити рахунок за хмару без втрати продуктивності.