Реалізація Predictive Scaling (масштабування за прогнозом)

Реалізація Predictive Scaling (масштабування за прогнозом)

Ми часто стикаємося з ситуацією, коли reactive scaling не встигає за зростанням навантаження: інстанси додаються вже після того, як користувачі відчули гальмування. Scheduled scaling вимагає ручного підтримання розкладів і ламається при будь-якій зміні паттернів. Predictive Scaling — третій підхід, який вирішує ці проблеми: AWS аналізує історичні дані про навантаження за останні 14 днів і будує ML-прогноз на найближчі 48 годин, автоматично додаючи інстанси до того, як навантаження зросте. Наші сертифіковані інженери з 10+ років досвіду налаштовують це рішення під ключ.

Це не заміна reactive scaling, а доповнення до нього. Predictive відпрацьовує регулярні паттерни, reactive — несподівані сплески. Ми гарантуємо, що ваша інфраструктура буде готова до будь-яких сценаріїв.

Як працює ML-прогнозування AWS

Predictive Scaling використовує ансамблеві моделі часових рядів, навчені на паттернах конкретного ASG. Для прогнозу потрібно мінімум 24 години історії, але точність зростає з накопиченням даних — оптимально від 2 тижнів. Модель уловлює:

• Добові паттерни (ранкове зростання, нічне затишшя)
• Тижневі цикли (будні vs вихідні)
• Комбінації (понеділок вранці завжди вищий, ніж п'ятниця)

Модель не уловлює разові події (запуск реклами, новина в пресі), а також технічні аномалії (DDoS, crawler-сплеск). Для цього — reactive scaling поверх.

Чому Predictive Scaling не відміняє reactive scaling?

Це часте питання від замовників. Predictive Scaling ідеальний для передбачуваних циклів, але безсилий проти раптових сплесків. Тому в production-конфігурації ми завжди комбінуємо обидва підходи: Predictive підготовлює ємність під регулярні піки, а Target Tracking доопрацьовує при відхиленнях. Така зв'язка забезпечує SLA 99.9% навіть при хаотичному трафіку.

Налаштування через Terraform

resource "aws_autoscaling_policy" "predictive" {
  name = "predictive-scaling"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "PredictiveScaling"

  predictive_scaling_configuration {
    metric_specification {
      target_value = 50 # цільовий CPU%
      predefined_scaling_metric_specification {
        predefined_metric_type = "ASGAverageCPUUtilization"
      }
      predefined_load_metric_specification {
        predefined_metric_type = "ASGTotalCPUUtilization"
      }
    }

    mode = "ForecastAndScale"
    scheduling_buffer_time = 300 # 5 хвилин до прогнозованого піку
    max_capacity_breach_behavior = "IncreaseMaxCapacity"
    max_capacity_buffer = 10 # запас 10% зверху прогнозу
  }
}

scheduling_buffer_time: 300 — Predictive Scaling запускає інстанси за 5 хвилин до прогнозованого піку. Це покриває час запуску та ініціалізації. Для застосунків з довгим warmup (Spring Boot) — потрібно 600–900 секунд.

mode: ForecastOnly — почніть з цього режиму. ASG буде будувати прогноз і показувати його в CloudWatch, але не приймати жодних action. Це дозволяє оцінити точність прогнозу перед включенням реального масштабування.

Як вибрати метрику для прогнозу?

Predictive Scaling працює з двома типами метрик:

Для load metric і scaling metric краще використовувати різні метрики: load metric описує загальне навантаження на fleet (ASGTotalCPUUtilization = сума CPU всіх інстансів), scaling metric — цільове значення на інстанс.

Практичні обмеження

Predictive Scaling працює тільки для EC2 Auto Scaling Groups. ECS Service, DynamoDB, Lambda Provisioned Concurrency — тільки через Scheduled Actions або Target Tracking.

Predictive Scaling не вміє масштабуватися вниз у режимі ForecastAndScale — тільки вгору. Scale-in залишається за Target Tracking. Якщо паттерн навантаження нестабільний (стартап зі швидко змінюваними паттернами, A/B тест змінює трафік) — 14-денна історія буде зашумлена, і прогноз вийде неточним. У таких випадках Scheduled Actions + reactive scaling буде надійніше.

Перевірка точності прогнозу

У CloudWatch дивимося PredictiveScalingLoadForecast і PredictiveScalingCapacityForecast. Порівнюємо прогнозоване навантаження з фактичним. Якщо прогноз систематично помиляється на 30%+ — або паттерн нестабільний, або обрана неправильна метрика. В AWS Console (EC2 → Auto Scaling Groups → вкладка Predictive Scaling) є візуалізація прогнозу vs факт — зручно для початкової калібрування.

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

При замовленні послуги ми надаємо:

• Аналіз історичних даних і вибір оптимальної метрики
• Налаштування Predictive Scaling через Terraform (ForecastOnly → ForecastAndScale)
• Інтеграцію з існуючими reactive і scheduled політиками
• Моніторинг точності прогнозу в CloudWatch протягом 2 тижнів
• Документацію runbook і рекомендації щодо scale-in
• Гарантію якості: якщо прогноз систематично помиляється більш ніж на 20%, ми безкоштовно переглядаємо конфігурацію

Комбінація з Reactive Scaling

Фінальна конфігурація для production:

Всі три механізми активні одночасно і не конфліктують — ASG вибирає максимальний desired з усіх діючих політик.

Терміни та оцінка

Включення Predictive Scaling у режимі ForecastOnly — кілька годин. Спостереження за прогнозом протягом 1–2 тижнів, перехід у ForecastAndScale і точне налаштування параметрів — 3–5 робочих днів сумарно (з перервами на накопичення даних). Вартість розраховується індивідуально: напишіть нам, і ми оцінимо ваш проект.

Отримайте консультацію — наші інженери допоможуть підібрати оптимальну конфігурацію Predictive Scaling під ваше навантаження.