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

Автомасштабированием называется процесс динамического выделения ресурсов в соответствии с требованиями к производительности. По мере роста объема работы приложение может потребовать дополнительных ресурсов для поддержания требуемых уровней производительности и удовлетворения соглашений об уровне обслуживания (SLA). По мере снижения спроса и дополнительных ресурсов больше не требуется, их можно отменить, чтобы свести к минимуму затраты.

Автоматическое масштабирование использует преимущества эластичности облачной среды и сокращает издержки на управление, так как оператору не нужно отслеживать производительность системы и принимать решения о добавлении или удалении ресурсов.

Масштабировать приложение можно двумя способами:

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

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

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

Компоненты автомасштабирования

Стратегия автомасштабирования обычно включает следующие элементы:

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

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

Настройка автомасштабирования для решения Azure

Azure предоставляет встроенную автомасштабирование для большинства вариантов вычислений.

• Автомасштабирование виртуальных машин Azure с помощью масштабируемых наборов виртуальных машин, которые управляют набором виртуальных машин в качестве группы. Узнайте , как использовать автоматическое масштабирование и масштабируемые наборы виртуальных машин.

• Service Fabric также поддерживает автоматическое масштабирование с помощью масштабируемых наборов виртуальных машин. Каждый тип узла в кластере Service Fabric настраивается как отдельный масштабируемый набор виртуальных машин. Таким образом, каждый тип узла можно масштабировать внутрь или наружу независимо. См. Масштабирование кластера Service Fabric внутрь или наружу с помощью правил автомасштабирования.

• Служба приложений Azure имеет встроенное автомасштабирование. Параметры автомасштабирования применяются ко всем приложениям в службе приложений. Дополнительные сведения см. в статьях "Масштабирование количества экземпляров вручную или автоматически" и "Масштабирование приложения в службе приложений Azure".

Эти параметры вычислений все используют автомасштабирование Azure Monitor для предоставления набора общих функций автомасштабирования.

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

Наконец, иногда может быть полезно пользовательское решение автомасштабирования. Например, можно использовать метрики системы диагностики Azure и приложений, а также пользовательский код для мониторинга и экспорта метрик приложения. Затем можно определить пользовательские правила на основе этих метрик и использовать REST API Resource Manager для активации автомасштабирования. Однако пользовательское решение не является простым для реализации и должно рассматриваться только в том случае, если ни один из предыдущих подходов не может соответствовать вашим требованиям.

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

Автомасштабирование в Azure Monitor

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

Примеры.

• Увеличьте масштабирование до 10 экземпляров в будние дни и уменьшите масштабирование до 4 экземпляров в субботу и воскресенье.
• Горизонтальное масштабирование увеличивается на один экземпляр, если среднее использование ЦП превышает 70%, и уменьшается на один экземпляр, если использование ЦП опускается ниже 50%.
• Масштабировать на один экземпляр, если количество сообщений в очереди превышает определенный порог.

Увеличьте ресурсы при увеличении нагрузки, чтобы обеспечить доступность. Аналогичным образом, в периоды низкой нагрузки уменьшайте масштаб, чтобы оптимизировать затраты. Всегда используйте сочетание правил расширения (scale-out) и сокращения (scale-in). В противном случае, автомасштабирование выполняется только в одном направлении, пока не достигнет установленного в профиле порогового значения (максимального или минимального числа экземпляров).

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

Список встроенных метрик см. в статье "Автомасштабирование общих метрик Azure Monitor". Вы также можете реализовать пользовательские метрики с помощью Application Insights.

Автомасштабирование можно настроить с помощью PowerShell, Azure CLI, шаблона Azure Resource Manager или портала Azure. Для получения более подробного элемента управления используйте REST API Azure Resource Manager. Библиотека управления службами мониторинга Azure и библиотека Microsoft Insights (в предварительной версии) — это пакеты SDK, которые позволяют собирать метрики из разных ресурсов и выполнять автомасштабирование с помощью REST API. Для ресурсов, в которых недоступна поддержка Azure Resource Manager или если вы используете облачные службы Azure, REST API управления службами можно использовать для автомасштабирования. Во всех остальных случаях используйте Azure Resource Manager.

При использовании автомасштабирования Azure следует учитывать следующие моменты:

• Рассмотрим, можно ли прогнозировать нагрузку на приложение достаточно точно, чтобы использовать запланированное автомасштабирование, добавление и удаление экземпляров для удовлетворения ожидаемых пиков спроса. Если это невозможно, используйте реактивное автомасштабирование на основе метрик среды выполнения, чтобы обрабатывать непредсказуемые изменения спроса. Как правило, эти подходы можно объединить. Например, создайте стратегию, которая добавляет ресурсы на основе расписания времени, когда вы знаете, что приложение является самым загруженным. Это помогает обеспечить доступность емкости при необходимости без каких-либо задержек при запуске новых экземпляров. Для каждого запланированного правила определите метрики, разрешающие реактивное автомасштабирование в течение этого периода, чтобы гарантировать, что приложение может обрабатывать устойчивые, но непредсказуемые пики спроса.

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

• Настройте правила автомасштабирования, а затем отслеживайте производительность приложения с течением времени. Используйте результаты этого мониторинга, чтобы настроить способ масштабирования системы при необходимости. Однако помните, что автомасштабирование не является мгновенным процессом. Требуется время для реагирования на метрику, например среднее превышение использования ЦП (или снижение ниже) заданного порогового значения.

• Правила автомасштабирования, использующие механизм обнаружения на основе измеренного атрибута триггера (например, загрузки ЦП или длины очереди), используют агрегированное значение с течением времени, а не мгновенные значения для активации действия автомасштабирования. По умолчанию, сводное значение вычисляется как среднее. Это предотвращает слишком быстрое реагирование системы и быстрое колебание. Он также позволяет время для новых экземпляров, которые автоматически начинаются в режим выполнения, предотвращая выполнение дополнительных действий автомасштабирования во время запуска новых экземпляров. Для облачных служб Azure и виртуальных машин Azure период по умолчанию для агрегирования составляет 45 минут, поэтому метрика может занять до этого периода времени, чтобы активировать автомасштабирование в ответ на пики спроса. Период агрегирования можно изменить с помощью пакета SDK, но периоды менее 25 минут могут привести к непредсказуемым результатам. Для веб-приложений период усреднения гораздо короче, что позволяет новым экземплярам стать доступными примерно через пять минут после изменения усредненного показателя запуска.

• Избегайте сдвига, когда действия масштабирования и горизонтального масштабирования постоянно идут назад и вперед. Предположим, что существует два экземпляра, а верхний предел составляет 80% ЦП, нижний предел составляет 60%. При загрузке в 85%добавляется другой экземпляр. Через некоторое время нагрузка уменьшается до 60%. Перед масштабированием служба автомасштабирования вычисляет, как распределится общая нагрузка из трех экземпляров в случае, если один экземпляр будет удален, что приведет к её повышению до 90%. Это означает, что необходимо будет немедленно увеличить масштаб. Таким образом, он пропускает масштабирование, и вы никогда не увидите ожидаемые результаты масштабирования.

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

• Ручное масштабирование сбрасывается до максимального и минимального количества экземпляров, используемых для автоматического масштабирования. Если вы вручную изменяете число экземпляров, установив его выше максимального или ниже минимального, подсистема автомасштабирования автоматически масштабируется до минимального (если ниже) или максимального (если выше). Например, можно задать диапазон от 3 до 6. Если у вас есть один запущенный экземпляр, механизм автомасштабирования увеличивает количество экземпляров до трех на следующем запуске. Аналогично, если вы вручную установите масштаб на восемь экземпляров, при следующем запуске автомасштабирование уменьшит его до шести. Масштабирование вручную является временным, если вы также не перенастроите правила автоматического масштабирования.

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

Дополнительные сведения о масштабировании Azure Monitor см. в рекомендациях по автомасштабированию.

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

• При автомасштабировании Service Fabric типы узлов в кластере состоят из масштабируемых наборов виртуальных машин в серверной части, поэтому необходимо настроить правила автомасштабирования для каждого типа узла. Учитывайте количество узлов, которые необходимо иметь перед настройкой автомасштабирования. Минимальное количество узлов, которые необходимо использовать для типа основного узла, зависит от выбранного уровня надежности. Для получения дополнительной информации см. раздел "Масштабирование кластера Service Fabric с использованием правил автомасштабирования".

• Портал можно использовать для связывания ресурсов, таких как экземпляры и очереди базы данных SQL, с экземпляром облачной службы. Это позволяет более легко получить доступ к отдельным параметрам конфигурации вручную и автоматического масштабирования для каждого связанного ресурса. Дополнительные сведения см. в статье "Практическое руководство. Связывание ресурса с облачной службой".

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

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

• В среде службы приложений любые рабочие пулы или интерфейсные метрики можно использовать для определения правил автомасштабирования. Дополнительные сведения см. в разделе "Автомасштабирование" и "Среда службы приложений".

Application design considerations

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

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

• Если решение реализует долго выполняющуюся задачу, создайте эту задачу для поддержки масштабирования и масштабирования. Без должного ухода такая задача может предотвратить очистку экземпляра процесса при масштабировании системы или потерять данные, если процесс принудительно завершается. В идеале необходимо провести рефакторинг длительной задачи и разбить процесс, который она выполняет, на более мелкие, отдельные блоки. Шаблон "Каналы и фильтры" содержит пример того, как это можно сделать.

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

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

Дополнительные критерии масштабирования

• Рассмотрим длину очереди, по которой взаимодействуют пользовательские интерфейсы и фоновые вычислительные экземпляры. Используйте его в качестве критерия для стратегии автомасштабирования. Это один из возможных индикаторов дисбаланса или разницы между текущей нагрузкой и емкостью обработки фоновой задачи. Существует немного более сложный, но лучший атрибут, на основании которого можно принимать решения о масштабировании. Используйте время между отправкой сообщения и моментом завершения его обработки, известное как критическое время. Если это критическое значение времени ниже понятного бизнес-порога, то не требуется масштабировать, даже если длина очереди длинна.

  • Например, в очереди может быть 50 000 сообщений, но критическое время самого старого сообщения составляет 500 мс, и эта конечная точка имеет дело с интеграцией со сторонней веб-службой для отправки сообщений электронной почты. Скорее всего, заинтересованные лица бизнеса считают, что это период времени, который не оправдывает дополнительные расходы на масштабирование.
  • С другой стороны, в очереди может быть 500 сообщений, с тем же 500 мс критического времени, но конечная точка является частью критического пути в некоторых онлайн-играх в режиме реального времени, где заинтересованные лица бизнеса определили 100 мс или меньше времени отклика. В этом случае масштабирование имеет смысл.
  • Чтобы эффективно использовать критически важное время при принятии решений об автоматическом масштабировании, полезно, чтобы библиотека автоматически добавляла соответствующую информацию в заголовки сообщений во время их отправки и обработки. Одна из таких библиотек, предоставляющая эту функцию, — NServiceBus.

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

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

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

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

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

Связанные ресурсы

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

• Шаблон регулирования. В этом шаблоне описывается, как приложение может продолжать функционировать и соответствовать соглашениям об уровне обслуживания, когда увеличение спроса приводит к крайней нагрузке на ресурсы. Ограничение скорости можно использовать вместе с автомасштабированием, чтобы предотвратить перегрузку системы при её расширении.

• Шаблон конкурирующих потребителей. В этом шаблоне описывается реализация пула экземпляров служб, которые могут обрабатывать сообщения из любого экземпляра приложения. Автомасштабирование можно использовать для запуска и остановки экземпляров сервисов для соответствия ожидаемой рабочей нагрузке. Этот подход позволяет системе одновременно обрабатывать несколько сообщений для оптимизации пропускной способности, повышения масштабируемости и доступности и балансировки рабочей нагрузки.

• Мониторинг и диагностика. Инструментирование и телеметрия жизненно важны для сбора информации, которая может управлять процессом автомасштабирования.