Блог Amazon Web Services

Представляем штатную поддержку прогнозного масштабирования в Amazon EC2 Auto Scaling

Оригинал статьи: ссылка (Scott Horsfield, Principal Solutions Architect, EC2 Scalability и Ankur Sethi, Sr. Product Manager, EC2)

С помощью Amazon EC2 Auto Scaling (автоматического масштабирования) заказчики могут использовать эластичность облака AWS, автоматически запуская и останавливая инстансы в соответствии с требованиями приложения. Сегодня мы рады рассказать вам о функциональности прогнозного масштабирования. Это новая политика EC2 Auto Scaling, которая предсказывает резкие изменения спроса и заблаговременно увеличивает мощность, обеспечивая более высокую доступность вашего приложения. Благодаря прогнозному масштабированию, вы можете избежать избыточного резервирования мощностей, что поможет снизить затраты на Amazon EC2. Прогнозное масштабирование было доступно в AWS Auto Scaling с 2018 года, но теперь вы можете использовать его напрямую в группах EC2 Auto Scaling вместе с другими политиками масштабирования. В этой статье мы рассмотрим прогнозное масштабирование и покажем сценарий, в котором такая функциональность будет полезна. Мы также рассмотрим шаги по настройке прогнозного масштабирования в группе EC2 Auto Scaling.

Общий обзор

EC2 Auto Scaling предоставляет набор динамических политик масштабирования, таких как отслеживание целевого значения (target tracking), простое масштабирование (simple scaling) и пошаговое масштабирование (step scaling). Политики масштабирования – это задаваемые заказчиками правила, по которым инстансы добавляются в группу или убираются из неё на основе определённой метрики Amazon CloudWatch, характеризующей нагрузку на приложение. EC2 Auto Scaling постоянно следит за указанной метрикой и реагирует на её изменения в соответствии с заданными политиками, запускающими дополнительные инстансы.

Так как динамические политики масштабирования реагируют на изменения метрики после того, как они произошли, дополнительное использование прогнозного масштабирования может быть полезным в следующих ситуациях:

  • Нагрузка на приложение меняется резко, но с повторяющейся закономерностью. Например, каждую неделю требуемые мощности увеличиваются при начале работы после выходных.
  • Инстансам приложения требуется много времени на инициализацию.

Теперь вы можете без труда настроить прогнозное масштабирование в дополнение к уже существующим политикам динамического масштабирования, чтобы увеличить мощности раньше, чем наступит прогнозируемое увеличение спроса. Вам не нужно резервировать больше ресурсов, чем необходимо, или тратить время, чтобы вручную настроить масштабирование по расписанию (scheduled scaling) для регулярно повторяющихся изменений спроса. Прогнозное масштабирование использует машинное обучение, чтобы предсказать требуемые мощности, основываясь на истории изменения нагрузки, а также постоянно обучается на новых данных, чтобы сделать прогнозы более точными.

Введение в параметры EC2 Auto Scaling

При запуске Auto Scaling группы вы задаёте минимальный, максимальный и желаемый размер группы, которые выражаются в количестве инстансов EC2. Минимальный и максимальный размер – это нижняя и верхняя границы группы, заданные заказчиком. Желаемый размер соответствует фактическому количеству инстансов в группе, которое EC2 Auto Scaling постоянно регулирует. Прогнозное масштабирование добавляет к этому списку ещё один параметр, который называется прогнозируемый размер (predicted capacity).

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

  • Если фактический размер ниже прогнозируемого размера, EC2 Auto Scaling масштабирует группу так, чтобы её желаемый размер соответствовал предсказанному.
  • Если фактический размер уже выше прогнозируемого размера, EC2 Auto Scaling не масштабирует группу (то есть, не уменьшает количество инстансов).
  • Если прогнозируемый размер находится вне границ минимального и максимального размера, которые вы задали, EC2 Auto Scaling не будет выходить за эти пределы.

Имейте в виду, что прогнозная политика масштабирования не предназначена для использования отдельно от других политик, так как она не уменьшает количество интансов в группе, а только увеличивает их в преддверии повышенного спроса. Таким образом, прогнозное масштабирование следует использовать вместе с какой-либо другой динамической политикой: одной из предоставляемых AWS или на основе своего решения автоматизации, созданного вами. Динамическое масштабирование позволит уменьшать размер группы, когда требуется меньше мощностей. При этом каждая политика задаёт значение размера независимо от других, а желаемый размер будет установлен в наибольшее из значений. Благодаря этому, ваше приложение может масштабироваться, даже если нагрузка в реальном времени выше предсказанной.

Прогнозное масштабирование работает в одном из двух режимов: «только предсказание» (Forecast Only) или «предсказание и масштабирование» (Forecast And Scale). В первом режиме вы можете удостовериться, что прогнозное масштабирование правильно предсказывает ваш обычный спрос. Это отличный способ начать работу с прогнозным масштабированием без влияния на текущее поведение группы. Вы также можете создать несколько политик в режиме «только предсказание», что позволит вам сравнить разные настройки, например, прогнозирование на основе различных метрик. После проверки прогнозов вам достаточно переключить режим в «предсказание и масштабирование» для наиболее подходящей политики. Теперь, когда у вас есть общее представление о новой функциональности, давайте рассмотрим шаги по её настройке.

Начинаем работу с прогнозным масштабированием

В этом разделе мы пройдём шаги по добавлению политики прогнозного масштабирования в Auto Scaling группу, но перед тем, как мы начнём, давайте посмотрим на то, как динамическое масштабирование реагирует на резкие увеличения нагрузки. Для наглядности мы создали симуляцию нагрузки, для запуска которой необходимо развернуть шаблон AWS CloudFormation в вашем аккаунте. В этом примере будут созданы две Auto Scaling группы. Первая группа используется для запуска тестового приложения и работает вместе с Application Load Balancer (ALB). Вторая группа предназначена для генерации повторяющихся запросов через ALB к приложению из первой группы. В данном случае мы использовали политику отслеживания целевого значения для сохранения нагрузки CPU на уровне 25% путём масштабирования первой группы, в которой запущено приложение.

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

Сильный скачок времени ответа при резком изменении нагрузки

На графике вы можете увидеть периодическое повышение количества запросов (красная линия), но скорость такого повышения отличается. Например, в промежутке с 16:00 до 18:00 UTC, прежде чем стабилизироваться, увеличение нагрузки происходит гораздо более плавно, чем в промежутке с 08:00 до 10:00 UTC. Время ответа ALB (зелёная линия) остаётся низким в первом случае при плавном увеличении нагрузки. Однако во втором случае, когда нагрузка увеличивается резко, хотя автоматическое масштабирование и добавляет необходимое количество инстансов (синяя линия), мы видим резкий скачок во времени ответа. Давайте увеличим масштаб, чтобы лучше рассмотреть график этой метрики.

Количество запросов и время ответа ALB

На предыдущем скриншоте мы можем увидеть, что время ответа достигает 35 секунд в первые 5 минут часа, а затем снова падает до значения меньше одной секунды. Так как динамическое масштабирование реагирует на изменение метрики, оно не успело за резким изменением спроса, которое мы видим в данном случае. Это может быть приемлемо для приложений, не чувствительных к таким задержкам, но для других приложений прогнозное масштабирование поможет лучше справляться с такими сценариями, устанавливая базовую мощность в начале каждого часа.

Теперь мы рассмотрим шаги по настройке политики прогнозного масштабирования. Имейте в виду, что ей требуется как минимум 24 часа исторических данных о нагрузке для генерации предсказаний. Если вы используете пример выше, оставьте его запущенным на 24 часа для генерации данных.

Настройка политики прогнозного масштабирования в режиме «только предсказание»

В первую очередь, давайте настроим Auto Scaling группу с политикой прогнозного масштабирования в режиме «только предсказание», чтобы проверить результаты прогнозирования и поменять параметры для более точного отражения желаемого поведения.

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

cat <<EoF > predictive-scaling-policy-cpu.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 25,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ASGCPUUtilization"
            }
        }
    ],
    "Mode": "ForecastAndScale"
}
EoF

После создания файла запустите следующую команду для добавления политики в вашу группу.

aws autoscaling put-scaling-policy \
    --auto-scaling-group-name "Example Application Auto Scaling Group" \
    --policy-name "CPUUtilizationpolicy" \
    --policy-type "PredictiveScaling" \
    --predictive-scaling-configuration file://predictive-scaling-policy-cpu.json

Просмотр прогнозов

После создания политики и сбора данных о загрузке на протяжении 24 часов вы можете использовать API прогнозного масштабирования, чтобы посмотреть прогнозируемую нагрузку и прогнозируемый размер группы. Эти прогнозы вы также можете найти в консоли управления: для этого перейдите в раздел Amazon EC2, выберите в меню Auto Scaling Groups, а затем откройте группу, для которой вы настроили прогнозное масштабирование. Вы можете увидеть политику в разделе Automatic Scaling в детальной информации о группе. В информации о политике показаны графики LoadForecast и CapacityForecast, которые показывают предсказанные значения соответствующих метрик на следующие 48 часов, а также предыдущие предсказания и фактическое среднее количество инстансов. На скриншоте ниже показаны предсказания для политики, только что созданной в Auto Scaling группе. Оранжевая линия показывает фактическое значение, синяя линяя показывает предыдущие предсказания, а зелёная – предсказания на следующие 2 дня.

Исторические и новые прогнозы

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

В этом примере политика прогнозного масштабирования рассчитывает размер группы так, чтобы инстансы в ней имели загрузку CPU, равную 25% каждый час. В прогнозном масштабировании также доступны три другие предопределённые конфигурации метрик, чтобы вы могли быстро настроить предсказания по другим метрикам, кроме CPU. Вы можете создать несколько политик прогнозного масштабирования в режиме «только предсказание» на основе разных метрик и целевых значений, чтобы определить наиболее подходящую для вашей рабочей нагрузки. Это поможет вам сравнить поведение различных политик с существующими приложениями без изменения текущей конфигурации. В нашем случае предсказание выглядит вполне точным, поэтому мы будем придерживаться этой конфигурации.

Настройка политик в режиме «предсказание и масштабирование»

Когда вы будете готовы разрешить прогнозному масштабированию автоматически изменять размер вашей группы каждый час, вы можете обновить одну из политик и включить для неё режим «предсказание и масштабирование» прямо в консоли управления. Также вы можете создать новый файл конфигурации и установить значение Mode в ForecastAndScale. Это можно сделать следующей командой:

cat <<EoF > predictive-scaling-policy-cpu.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 25,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ASGCPUUtilization"
            }
        }
    ],
    "Mode": "ForecastAndScale"
}
EoF

Теперь запустите команду ниже, чтобы обновить политику на основе созданного файла конфигурации.

aws autoscaling put-scaling-policy \
    --auto-scaling-group-name "Example Application Auto Scaling Group" \
    --policy-name "CPUUtilizationpolicy" \
    --policy-type "PredictiveScaling" \
    --predictive-scaling-configuration file://predictive-scaling-policy-cpu.json

После обновления политики масштабирования прогнозируемый размер группы будет изменяться каждый час в соответствии с предсказаниями. Этот размер действует в качестве базового уровня и будет устанавливаться в начале каждого часа. Вы можете настроить дополнительное время для запуска в соответствии со временем, которое требуется инстансу для настройки и прогрева.

Влияние включённого прогнозного масштабирования

Теперь, когда мы включили режим ForecastAndScale, и прогнозное масштабирование изменяет размер группы, давайте посмотрим на метрику времени ответа ALB.

Скачки во времени ответа отсутствуют при использовании прогнозного масштабирования

Как вы можете увидеть на скриншоте выше, до резкого повышения спроса (08:00 – 10:00 UTC) в группу были добавлены 40 инстансов на основе прогнозного масштабирования. Политика динамического масштабирования добавила оставшиеся 9 инстансов, которые требуются для обработки повышенного спроса. Благодаря совместной работе обеих политик, мы больше не видим скачков во времени ответа (зелёная линия). Давайте приблизим график на необходимый промежуток времени, чтобы рассмотреть его лучше.

Применение прогнозного масштабирования в режиме «предсказание и масштабирование»

Время ответа постоянно меньше, чем 0,02 секунды, по сравнению с 35 секундами, которые мы наблюдали ранее, когда использовали только динамическое масштабирование. Благодаря запуску инстансов до резкого увеличения нагрузки, мы смогли улучшить пользовательский опыт при работе с приложением. Вам больше не нужно прибегать к избыточному резервированию или ручным изменениям для масштабирования ваших групп в преддверии таких изменений спроса. Пока существует предсказуемая модель поведения, автоматическое масштабирование, дополненное прогнозным масштабированием, поддерживает высокую доступность ваших приложений.

Если вы использовали стек из примера выше, не забудьте удалить его после окончания тестирования.

Заключение

Прогнозное масштабирование в комбинации с динамическим масштабированием помогает вам быть уверенными, что у рабочих нагрузок в группах EC2 Auto Scaling есть достаточно мощностей для обработки как предсказанной нагрузки, так и нагрузки, изменяющейся в режиме реального времени. Вы можете запустить прогнозное масштабирование в режиме «только предсказание», чтобы получить представление о прогнозируемом размере группы без непосредственных действий по масштабированию. Вы можете уточнить и настроить политики прогнозного масштабирования, выбрав одну из четырёх предопределённых метрик и настроив её целевое значение в соответствии с вашими требованиями. После этого вы можете переключить политику в режим «предсказание и масштабирование» для автоматического изменения размера вашей группы на основе предсказанной нагрузки. При использовании прогнозного и динамического масштабирования вместе, размер вашей группы будет соответствовать требованиям, что позволит повысить скорость отклика приложения и уменьшить затраты на EC2. Чтобы узнать больше о новой функциональности, обратитесь к документации EC2 Auto Scaling.