Автоматическое масштабирование в облаке

Завершено

Администратор облака может вручную увеличивать вертикальный или горизонтальный масштаб при росте спроса и уменьшать масштаб для снижения затрат при падении спроса. Например, внимательный администратор может определить, что спрос растет, и использовать инструменты, предоставляемые поставщиками облачных служб, чтобы активировать дополнительные виртуальные машины (увеличение горизонтального масштаба, или расширение) или заменить существующие виртуальные машины на более крупные, с большим количеством ресурсов ЦП и большим объемом памяти (увеличение вертикального масштаба). Ключевое слово здесь — внимательный. Если пик спроса никто не заметит, система может работать очень медленно или даже перестанет отвечать на запросы конечных пользователей. И наоборот, если вы увеличите масштаб при росте нагрузок и не уменьшите его обратно при их снижении, вы будете платить за ненужные ресурсы.

Поэтому популярные облачные платформы предлагают механизмы автоматического масштабирования для масштабирования ресурсов в ответ на колебания спроса без вмешательства оператора. Существует два основных подхода к автоматическому масштабированию:

  • На основе времени — масштабирование ресурсов по заранее определенному расписанию. Например, если веб-сайт вашей организации испытывает максимальные нагрузки в рабочее время, настройте автоматическое масштабирование, чтобы увеличивать масштаб ресурсов в 08:00 каждое утро и уменьшать масштаб в 17:00 каждый вечер. Масштабирование на основе времени иногда называют масштабированием по расписанию.

  • На основе метрик — если нагрузка менее предсказуема, изменяйте масштаб ресурсов на основе предопределенных метрик, таких как использование ЦП, нехватка памяти или среднее время ожидания запроса. Например, если средняя загрузка ЦП достигает 70 %, автоматически подключаются дополнительные виртуальные машины, а когда она снижается до 30 %, лишние виртуальные машины отключаются.

Автоматическое масштабирование на основе времени, метрик или обоих показателей основывается на правилах масштабирования или политиках масштабирования, которые настраивает администратор облака. Современные облачные платформы поддерживают правила масштабирования от самых простых (например, увеличить количество экземпляров с двух до четырех каждый день в 08:00 и сократить обратно до двух в 17:00) до сложных (например, увеличить число виртуальных машин на единицу, если максимальная загрузка ЦП превышает 70 % или среднее время ожидания запроса достигает 5 секунд). Обычно администратору облака требуется поэкспериментировать, чтобы подобрать нужную комбинацию правил.

Все основные поставщики облачных служб, включая Amazon, Microsoft и Google, поддерживают автоматическое масштабирование. Автоматическое масштабирование AWS можно применить к экземплярам EC2, таблицам DynamoDB и некоторым другим облачным службам AWS. Azure предоставляет варианты автоматического масштабирования для ключевых служб, включая службу приложений и виртуальные машины. Google предлагает автоматическое масштабирование для Google Compute Engine и Google App Engine.

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

Автоматическое масштабирование на основе времени

Автоматическое масштабирование на основе времени используется, когда нагрузка меняется предсказуемым образом. Например, ИТ-системы многих организаций испытывают наивысшую нагрузку в рабочее время и почти не испытывают нагрузку ночью. Веб-сайт пиццы Domino может испытывать нагрузки на все часы дня, так как он работает более чем 16000 магазинов в почти 100 странах или регионах. Но в определенное время года нагрузка предсказуемо увеличивается.

В любом из этих сценариев можно использовать автоматическое масштабирование на основе времени. На рисунке 7 показано, как в Azure действует автоматическое масштабирование по расписанию. В этом примере администратор облака настраивает Службу приложений Azure, в которой размещен веб-сайт организации, для запуска двух экземпляров по умолчанию и увеличения их количества до четырех с 06:00 до 18:00 шесть дней в неделю, кроме воскресенья. Выбрав параметр "Указать даты начала и окончания", администратор может так же просто настроить службу приложений для расширения до 10 экземпляров в воскресенье, когда проходит Суперкубок. Кроме того, он может определить несколько условий масштабирования для расширения в другие дни.

Figure 7: Scheduled autoscaling in Azure.

Рис. 7. Запланированное автоматическое масштабирование в Azure.

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

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

Отслеживается несколько аспектов ресурсов для активации их масштабирования. Наиболее распространенной метрикой является использование ресурсов. Например, служба мониторинга может отслеживать использование ЦП каждым узлом ресурсов и масштабировать ресурсы, если использование слишком высокое или низкое. Если, например, использование каждого ресурса превышает 90 %, то, вероятно, лучше добавить дополнительные ресурсы, так как система сильно загружена. Поставщики услуг обычно выбирают точки триггеров путем анализа точки останова узлов ресурсов, когда в них начнут происходить сбои, и сопоставления их поведения с различными уровнями нагрузки. Но из соображений экономии важно максимально использовать каждый ресурс, поэтому рекомендуется оставить операционной системе пространство для некоторых издержек. Аналогично, если использование ниже, скажем, 30 %, возможно, требуются не все узлы ресурсов и можно отключить некоторые.

На практике поставщики услуг обычно отслеживают сочетание нескольких метрик узла ресурса, чтобы оценить, когда следует масштабировать ресурсы. Некоторые из них включают использование ЦП, использование памяти, пропускную способность и задержку. AWS использует CloudWatch для отслеживания ресурсов EC2 и предоставления метрик масштабирования (рис. 8). CloudWatch отслеживает метрики для всех экземпляров EC2 в группе масштабирования и создает оповещение, когда указанная метрика выходит за пределы, например, когда загрузка ЦП превышает 70 %. Затем AWS увеличивает или уменьшает число экземпляров EC2 на основе политик масштабирования, настроенных администратором.

Figure 8: Autoscaling EC2 instances in AWS.

Рис. 8. Автоматическое масштабирование экземпляров EC2 в AWS.

AWS также поддерживает прогнозное масштабирование, который использует машинное обучение, чтобы предвидеть шаблоны трафика и управлять количеством экземпляров соответственно. Цель состоит в том, чтобы интеллектуально масштабировать облачные ресурсы, не требуя от администратора облака настройки правил автоматического масштабирования. Основные поставщики облачных служб постоянно находят новые способы улучшения платформ с помощью машинного обучения. Корпорация Майкрософт, например, теперь использует машинное обучение для повышения устойчивости виртуальных машин Azure путем упреждающего прогнозирования и устранения сбоев виртуальных машин1.

Ссылки

  1. Майкрософт (2018). Повышение устойчивости виртуальных машин Azure с помощью прогнозного машинного обучения и динамической миграции. https://azure.microsoft.com/blog/improving-azure-virtual-machine-resiliency-with-predictive-ml-and-live-migration/.

Проверьте свои знания

1.

Вы являетесь администратором облака и следите за тем, чтобы общедоступный веб-сайт вашей организации всегда хорошо работал и быстро отвечал на запросы. Сайт размещается в Службе приложений Azure. Период самого интенсивного трафика — с 08:00 до 17:00 каждый день, но нагрузка может меняться в разные дни. Кроме того, иногда возникают пики нагрузки, когда трафик увеличивается в 10 раз. Эти пики сложно предсказать, но они существенно замедляют работу сайта, если как можно скорее не подключить дополнительные ресурсы. Какой подход обеспечивает лучший баланс между быстротой реагирования и затратами?