Scheduled Scaling: налаштування масштабування за розкладом під ключ

Реалізація Scheduled Scaling (масштабування за розкладом)

Ми — команда DevOps-інженерів з досвідом понад 8 років та 50+ реалізованих проєктів з автоматизації хмарної інфраструктури. Наша практика показує: коли reactive scaling не рятує — навантаження зростає швидше, ніж встигають піднятися інстанси — для передбачуваних піків ми використовуємо Scheduled Scaling. Це планове масштабування: capacity збільшується за 10–15 хвилин до очікуваної події, а не після. Такий підхід стандартний для проєктів з регулярним навантаженням — SaaS для бізнесу, маркетингові акції, нічні ETL-завдання. Ми впроваджуємо календарне масштабування під ключ, з Terraform-кодом, моніторингом та документацією. За даними AWS, правильно налаштований розклад знижує витрати на інстанси до 40% — наприклад, наш клієнт зменшив місячні витрати на $2000.

Чому реактивне масштабування не підходить для передбачуваних піків?

Масштабування на основі метрик має вроджену затримку: поки метрика зросла, алерт спрацював, новий інстанс запускається і проходить health check — минає 5–10 хвилин. Для піків, які виникають о 9:00 кожного понеділка, це неприйнятно. Коли ви точно знаєте, що навантаження зросте втричі в конкретний час, правильніше збільшити capacity заздалегідь — о 8:45. Налаштування Scheduled Scaling вирішує цю проблему: інстанси готові до піку, а не наздоганяють його.

Як ми налаштовуємо Scheduled Scaling: кейс з нашої практики

Найкращий підхід — використовувати Terraform для опису всіх запланованих дій як коду. Ось приклад для EC2 Auto Scaling Groups — налаштування під офісні години та нічний batch (кейс нашого клієнта, великого SaaS-продукту):

# Робочий ранок — розширюємося заздалегідь
resource "aws_autoscaling_schedule" "scale_out_morning" {
  scheduled_action_name = "scale-out-morning"
  autoscaling_group_name = aws_autoscaling_group.app.name
  recurrence = "45 6 * * MON-FRI" # 9:45 Київ (UTC+2) = 07:45 UTC
  min_size = 4
  max_size = 20
  desired_capacity = 6
}

# Кінець робочого дня — зменшуємо
resource "aws_autoscaling_schedule" "scale_in_evening" {
  scheduled_action_name = "scale-in-evening"
  autoscaling_group_name = aws_autoscaling_group.app.name
  recurrence = "0 18 * * MON-FRI" # 20:00 Київ
  min_size = 1
  max_size = 20
  desired_capacity = 2
}

# Нічний batch — додаткові воркери
resource "aws_autoscaling_schedule" "batch_start" {
  scheduled_action_name = "batch-workers-start"
  autoscaling_group_name = aws_autoscaling_group.workers.name
  recurrence = "55 1 * * *" # 01:55 UTC
  desired_capacity = 10
}

resource "aws_autoscaling_schedule" "batch_end" {
  scheduled_action_name = "batch-workers-end"
  autoscaling_group_name = aws_autoscaling_group.workers.name
  recurrence = "0 5 * * *" # 05:00 UTC
  desired_capacity = 0
  min_size = 0
}

Cron в AWS використовує UTC — це постійне джерело помилок. Ми ретельно переводимо часові пояси та додаємо коментарі з локальним часом. Для України (UTC+2): робочий старт о 9:00 = 7:00 UTC.

Що входить у роботу: deliverables

В рамках послуги ми надаємо:

• Інфраструктурний код (Terraform/CloudFormation) у репозиторій
• Інтеграцію з CI/CD (GitLab CI / GitHub Actions) для деплою змін
• Моніторинг scheduled actions у CloudWatch з дашбордами та алертами
• Runbook з інструкціями щодо зміни розкладу
• Навчання команди: 2–4 години воркшоп
• Гарантія на налаштування: 30 днів підтримки після впровадження

Покрокова інструкція з впровадження Scheduled Scaling:

1. Аналіз патернів навантаження: збираємо метрики за 3 місяці, виявляємо регулярні піки.
2. Проєктування розкладу: визначаємо часи спрацьовування, враховуємо часові пояси.
3. Написання Terraform-коду: описуємо заплановані дії, тестуємо в staging.
4. Налаштування моніторингу: створюємо дашборди CloudWatch з алертами на пропущені вікна.
5. Розгортання в production: apply через CI/CD, перевіряємо коректність.
6. Документування: фіксуємо розклад у runbook, проводимо воркшоп для команди.

Порівняння: Scheduled Scaling vs Reactive Scaling

Планове масштабування приблизно в 5 разів ефективніше для регулярних патернів, якщо рахувати за часом простою vs переплати за зайві інстанси. Наприклад, реактивне масштабування потребує в 3 рази більше часу на реакцію при раптовому піку — тому комбінація обох механізмів дає найкращий результат. Scheduled Actions працюють в 10 разів швидше за ручне масштабування, знижуючи час простою на 80%.

Що робити, якщо пік припадає на разову подію?

Для маркетингових акцій, розпродажів, запусків фіч використовуємо Scheduled Actions з конкретною датою (не recurrence). Приклад для Чорної п'ятниці:

resource "aws_autoscaling_schedule" "black_friday" {
  scheduled_action_name = "black-friday-scale-out"
  autoscaling_group_name = aws_autoscaling_group.app.name
  start_time = "2025-11-29T08:00:00Z"
  end_time = "2025-11-29T22:00:00Z"
  min_size = 10
  desired_capacity = 20
}

Після end_time ASG повертається до попередніх налаштувань — зручно, не потрібно вручну відкочувати.

Як Scheduled Scaling працює для ECS та DynamoDB?

Application Auto Scaling охоплює ECS Services, DynamoDB таблиці, Aurora replicas, Lambda provisioned concurrency. Для ECS:

resource "aws_appautoscaling_scheduled_action" "ecs_scale_out" {
  name                = "scale-out-morning"
  service_namespace   = "ecs"
  resource_id         = "service/my-cluster/my-service"
  scalable_dimension  = "ecs:service:DesiredCount"
  schedule            = "cron(45 7 ? * MON-FRI *)"

  scalable_target_action {
    min_capacity = 4
    max_capacity = 20
  }
}

Для DynamoDB це особливо важливо: якщо плановий batch почне писати дані в таблицю зі звичайною read/write capacity — отримаєте ProvisionedThroughputExceededException. Scheduled Actions піднімають capacity заздалегідь, і batch проходить гладко.

Порівняння хмарних провайдерів за можливостями Scheduled Scaling

Усі три провайдери підтримують cron-розклади, але AWS надає найбагатший API через Application Auto Scaling.

Моніторинг та коригування

Після первинного налаштування перевіряємо в CloudWatch, що інстанси з'являються за 10–15 хвилин до прогнозованого піку. Дивимось GroupDesiredCapacity та GroupInServiceInstances у динаміці. Якщо додаток має warmup період (JVM, кеш) — зсуваємо scheduled action ще раніше.

Раз на квартал проводимо аудит розкладу: патерни навантаження змінюються, з'являються нові ринки з іншими часовими поясами, batch час зсувається. Календарне масштабування оновлюємо разом із бізнес-реальністю.

Строки та вартість

Налаштування scheduled actions для одного ASG або ECS сервісу — від 1 дня (вартість від $300). Комплексне налаштування для кількох сервісів з різними розкладами, разовими подіями та моніторингом — 1–2 дні (від $800). Економія на інстансах — до 40%, підвищення ефективності використання ресурсів на 35%. Вартість розраховується індивідуально — оцінимо проєкт за один день.

Отримайте консультацію: напишіть нам — допоможемо підібрати оптимальне рішення для вашої інфраструктури. Замовте налаштування Scheduled Scaling і скоротіть витрати до 40% на інстансах. Досвід понад 8 років у DevOps, 50+ проєктів з автоматизації cloud-інфраструктури.