Запланированное и прогнозируемое масштабирование

Динамические политики масштабирования (отслеживание цели и пошаговое масштабирование) являются реактивными: они реагируют уже после превышения порога показателя. Для известных и предсказуемых схем трафика, таких как пики в рабочие часы, пакетные задания в конце месяца или распродажи в Чёрную пятницу, реактивное масштабирование слишком медленное, поскольку запуск и прогрев экземпляров занимают минуты. Плановое масштабирование и прогнозное масштабирование решают эту проблему, заранее изменяя ёмкость до поступления нагрузки.

Плановое действие масштабирования изменяет минимальную, максимальную или желаемую ёмкость ASG в определённые дату и время либо по повторяющемуся расписанию cron. Это идеально подходит, когда Вы точно знаете, когда возрастёт нагрузка, — например, для предварительного прогрева перед запланированным маркетинговым мероприятием или для уменьшения ёмкости ночью, когда трафик минимален, чтобы снизить расходы. В указанное время плановые действия переопределяют текущую желаемую ёмкость.

Запланированные действия используют формат Unix cron: minute hour day-of-month month day-of-week. Все времена указаны в UTC. Распространённые шаблоны включают 0 8 * * 1-5 (по будним дням утром в 08:00 UTC) для увеличения масштаба и 0 20 * * * (каждую ночь в 20:00 UTC) для уменьшения масштаба. В одной ASG можно создать несколько запланированных действий, например одно для увеличения масштаба и одно для его уменьшения каждый день.

Запланированные действия могут быть однократными (выполняются один раз в определённое время начала) или повторяющимися (выполняются по расписанию cron). Однократное действие отлично подходит для известного события в будущем, например запуска продукта. Повторяющееся действие обрабатывает регулярные закономерности, например ежедневные или еженедельные циклы трафика. Для повторяющегося действия также можно задать время начала и время окончания, чтобы автоматически включать и отключать расписание в пределах заданного диапазона дат.

Запланированные действия и политики динамического масштабирования могут работать совместно. В запланированное время действие задаёт новую базовую ёмкость. После этого динамические политики (отслеживание целевого показателя или ступенчатое масштабирование) продолжают изменять ёмкость в обновлённых минимальных и максимальных пределах. Например, утреннее запланированное действие задаёт min=4 и desired=8; в течение дня отслеживание целевого показателя увеличивает масштаб до 15 при росте нагрузки; затем вечернее действие снова устанавливает min=2 и desired=2.

Прогнозирующее масштабирование использует машинное обучение для анализа исторических закономерностей нагрузки по метрикам CloudWatch и прогнозирования будущих потребностей в ёмкости. Оно заранее планирует действия по увеличению масштаба до появления прогнозируемой нагрузки — обычно за 5–60 минут. Прогнозирующее масштабирование лучше всего подходит для рабочих нагрузок с повторяющимися ежедневными или еженедельными циклами трафика. По мере сбора новых данных оно непрерывно обновляет прогноз.

Чтобы включить прогнозирующее масштабирование, добавьте к своей ASG политику PredictiveScaling. Укажите пару метрик: метрику нагрузки (что определяет масштабирование, например CPU или количество запросов ALB) и метрику масштабирования (что отслеживается на каждом экземпляре). Затем AWS прогнозирует метрику нагрузки и вычисляет количество экземпляров, необходимое для поддержания метрики масштабирования на заданном целевом значении.

У Predictive Scaling есть два режима: ForecastOnly создаёт прогнозы, не изменяя фактическую ёмкость, — это удобно для проверки прогнозов перед переходом к автоматическому масштабированию. ForecastAndScale создаёт прогнозы и автоматически применяет изменения ёмкости. Начните с ForecastOnly на несколько недель, чтобы проверить точность, а затем переключитесь на ForecastAndScale. Перед созданием первого прогноза AWS требует данные метрик как минимум за 24 часа.

Прогнозирующее масштабирование заранее выполняет действия по увеличению масштаба, но можно настроить SchedulingBufferTime, чтобы запускать предварительную подготовку экземпляров ещё раньше. Значение SchedulingBufferTime, равное 5 минутам, означает, что ёмкость будет добавлена за 5 минут до прогнозируемого момента необходимости. Также можно задать MaxCapacityBuffer, чтобы разрешить ASG увеличивать масштаб сверх прогнозируемой потребности на определённый процент и создать запас на случай неточности прогноза.

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

Используйте масштабирование по расписанию, когда пики трафика полностью предсказуемы и известны точные моменты их возникновения (например, при событиях или в рабочие часы). Используйте прогнозирующее масштабирование, когда закономерности повторяются, но точное время может меняться: машинное обучение автоматически изучает закономерность. Используйте отслеживание целевого показателя как постоянно работающий динамический механизм защиты от неожиданной нагрузки. При полностью случайной нагрузке достаточно использовать только отслеживание целевого показателя или ступенчатое масштабирование. На экзамене SAA-C03 часто требуется выбрать наиболее эффективный с операционной точки зрения подход, и для повторяющихся циклических рабочих нагрузок выигрывает прогнозирующее масштабирование.

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что масштабирование по расписанию использует выражения cron для изменения ёмкости ASG в известные моменты и идеально подходит для предсказуемых событий или повторяющихся периодов рабочего времени; прогнозирующее масштабирование применяет машинное обучение к историческим данным CloudWatch, чтобы заранее увеличить масштаб до появления нагрузки; а сочетание прогнозирующего масштабирования и отслеживания целевого показателя обеспечивает проактивное и реактивное покрытие для наиболее устойчивой стратегии масштабирования. Далее мы рассмотрим обновление экземпляров и перехватчики жизненного цикла для контролируемого развёртывания.