Поделиться через

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование функции автомасштабирования Azure Monitor

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

Рассмотрим следующие примеры:

  • Масштабируйте до 10 экземпляров в будние дни и уменьшайте масштаб до четырех экземпляров в субботу и воскресенье.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Операции увеличения масштабирования всегда имеют приоритет над операциями внутреннего масштабирования.

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

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

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

Рекомендации по проектированию приложений

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

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

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

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

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

Другие критерии масштабирования

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

    • Например, в очереди может быть 50 000 сообщений. Но критическое время самого старого сообщения составляет 500 мс, и эта конечная точка имеет дело с интеграцией с веб-службой партнера для отправки сообщений электронной почты. Бизнес-заинтересованные лица могут не рассматривать этот сценарий как достаточно срочный, чтобы оправдать затраты на масштабирование.

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

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

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

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

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

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

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

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

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

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

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