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

Реализация Scheduled Scaling (масштабирование по расписанию)

Наша команда DevOps-инженеров не раз сталкивалась с ситуацией, когда reactive scaling не спасает — нагрузка растёт быстрее, чем успевают подняться инстансы. Для предсказуемых пиков мы используем Scheduled Scaling: capacity увеличивается за 10–15 минут до ожидаемого события, а не после. Это стандартный подход для проектов с регулярной нагрузкой — SaaS для бизнеса, маркетинговые акции, ночные ETL-задачи. Мы внедряем такое масштабирование под ключ, с Terraform-кодом, мониторингом и документацией. По данным AWS, правильно настроенное расписание снижает затраты на инстансы до 40%.

Почему reactive scaling не подходит для предсказуемых пиков?

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

Как мы настраиваем Scheduled Scaling: реальный кейс

Опыт показывает, что лучший подход — использовать Terraform для описания всех scheduled actions как кода. Вот пример для EC2 Auto Scaling Groups — настройка под офисные часы и ночной batch:

# Рабочее утро — расширяемся заранее
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" # 8:45 MSK (UTC+2) = 06: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 MSK
  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+3): рабочий старт в 9:00 MSK = 6:00 UTC.

Что входит в работу: deliverables

В рамках услуги мы предоставляем:

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

Сравнение: Scheduled Scaling vs Reactive Scaling

Scheduled Scaling примерно в 5 раз эффективнее для регулярных паттернов, если считать по времени простоя (capacity недогружена) vs переплаты за лишние инстансы.

Что делать, если пик приходится на разовое событие?

Для маркетинговых акций, распродаж, запусков фичей используем Scheduled Actions с конкретной датой (не recurrence). Пример для Black Friday:

resource "aws_autoscaling_schedule" "black_friday" {
  scheduled_action_name = "black-friday-scale-out"
  autoscaling_group_name = aws_autoscaling_group.app.name
  start_time = "2024-11-29T08:00:00Z"
  end_time = "2024-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 6 ? * 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 Scaling обновляем вместе с бизнес-реальностью.

Сроки

Настройка scheduled actions для одного ASG или ECS сервиса — от 1 дня. Комплексная настройка для нескольких сервисов с разными расписаниями, разовыми событиями и мониторингом — 1–2 дня. Стоимость рассчитывается индивидуально — оценим проект за один день.

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