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

  • Статья

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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