Политики масштабирования: отслеживание цели и пошаговое масштабирование

Статическая желаемая ёмкость подходит при постоянной нагрузке, но в реальном мире трафик меняется. Политики масштабирования позволяют группе Auto Scaling автоматически изменять желаемую ёмкость в ответ на показатели. AWS предлагает три основных типа динамических политик: отслеживание цели, пошаговое масштабирование и простое масштабирование. Для экзамена SAA-C03 важнее всего понимать отслеживание цели и пошаговое масштабирование.

Масштабирование с отслеживанием цели работает подобно термостату: Вы указываете показатель и целевое значение, а AWS автоматически вычисляет, сколько экземпляров добавить или удалить, чтобы поддерживать показатель на этом уровне. Например, если целевое значение средней загрузки CPU — 50%, а загрузка вырастет до 80%, ASG добавит достаточно экземпляров, чтобы вернуть загрузку CPU к 50%. AWS самостоятельно управляет увеличением и уменьшением ёмкости.

Отслеживание цели изначально поддерживает несколько предопределённых показателей: ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut и специфичный для ALB показатель ALBRequestCountPerTarget. Для показателей эффективности приложения (глубина очереди, активные подключения, пользовательские бизнес-показатели) можно указать пользовательский показатель CloudWatch. Пользовательские показатели обеспечивают гораздо более точный контроль над тем, что определяет решения о масштабировании.

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

Пошаговое масштабирование реагирует на оповещения CloudWatch, добавляя или удаляя определённое количество экземпляров в зависимости от того, насколько показатель превышает порог. Вы задаёте несколько пошаговых изменений — каждый шаг охватывает диапазон показателя и задаёт изменение ёмкости. Например: при загрузке CPU 60–70% добавить 1 экземпляр; при 70–90% добавить 3 экземпляра; при превышении 90% добавить 5 экземпляров. Это обеспечивает постепенную пропорциональную реакцию на разные уровни нагрузки.

Для пошагового масштабирования требуется заранее созданное оповещение CloudWatch. Оповещение отслеживает показатель и переходит в состояние ALARM при пересечении порога. Затем политика масштабирования использует пошаговые изменения, определяемые значением показателя относительно порога оповещения. Можно настроить тип изменения: ChangeInCapacity (добавить N), ExactCapacity (установить N) или PercentChangeInCapacity (изменить на N%).

Каждое пошаговое изменение содержит MetricIntervalLowerBound и, при необходимости, MetricIntervalUpperBound. Границы отсчитываются относительно порога оповещения. Если порог оповещения составляет 60% загрузки CPU: LowerBound=0, UpperBound=10 срабатывает при загрузке CPU 60–70%; LowerBound=10, UpperBound=null срабатывает при загрузке CPU выше 70%. Такой многоуровневый подход гарантирует, что при резком скачке трафика ёмкость будет сразу значительно увеличена, а не после нескольких циклов оповещений.

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

Иногда требуется предотвратить завершение работы определённых экземпляров при уменьшении ёмкости — например, экземпляра, выполняющего длительное пакетное задание. Можно включить защиту экземпляра от уменьшения ёмкости для отдельных экземпляров через консоль или CLI. Когда ASG выбирает кандидатов на завершение, она пропускает защищённые экземпляры. Не забудьте отключить защиту после завершения задания: иначе ASG может вообще не суметь уменьшить ёмкость, если защищены все экземпляры.

К одной ASG можно подключить несколько политик масштабирования. Если одновременно существуют политика отслеживания цели и политика пошагового масштабирования, ASG использует ту, которая рекомендует большее увеличение ёмкости (то есть наиболее осторожную). При уменьшении ёмкости выигрывает политика, которая рекомендует удалить наименьшее количество экземпляров. Это не позволяет системе колебаться между избыточным и недостаточным выделением ресурсов. Распространённый подход — использовать отслеживание цели для обычного режима и пошаговое масштабирование для защиты от аварийных всплесков нагрузки.

Для большинства веб-приложений начните с отслеживания цели по загрузке CPU или количеству запросов на цель — это требует минимальной настройки, а вычисления выполняет AWS. Используйте пошаговое масштабирование, когда нужны постепенные пропорциональные реакции на нагрузку разной интенсивности. Всегда устанавливайте минимальную ёмкость, достаточную для обработки обычного трафика без увеличения ёмкости, поскольку масштабирование занимает время. Отслеживайте показатели CloudWatch GroupDesiredCapacity и GroupInServiceInstances, чтобы убедиться, что политики работают ожидаемым образом.

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

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