Масштабирование на основе событий в Функциях Azure

Масштабирование, основанное на событиях, не применяется к плану Dedicated (App Service). План Dedicated не масштабируется динамически в зависимости от событий. Для вариантов масштабирования в Выделенном плане см. раздел «Масштабировать приложение в Служба приложений Azure».

Масштабирование, управляемое событием, не применяется при запуске функций на Контейнеры приложений Azure. При размещении на Container Apps масштабирование управляется средой Container Apps. Дополнительные сведения см. в статье Установка правил масштабирования в Контейнерах приложений Azure.

Масштабирование среды выполнения

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

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

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

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

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

Платформа управляет скоростью добавления экземпляров (кривая масштаба) отдельно от максимального количества экземпляров. Для получения дополнительной информации о том, как работает кривая масштабирования, поведении троттлинга и лучших практиках для высокоскоростного масштабирования, см. раздел Scale-out rate.

Холодный запуск

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

Как видно в этой таблице, и планы Flex Consumption, и Premium предоставляют способы устранить холодные старты в ваших приложениях.

Понимание поведения при масштабировании

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

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

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

• Масштабирование на основе целевого объекта: Масштабирование на основе целевого объекта обеспечивает быструю и интуитивно понятную модель масштабирования для клиентов. В настоящее время этот метод масштабирования поддерживается для очередей и разделов служебной шины, очередей хранилища, Центров событий, Apache Kafka и расширений Azure Cosmos DB. Обязательно проверьте масштабирование на основе целевых объектов, чтобы понять их поведение масштабирования.

• Масштабирование для каждой функции: За некоторыми отметимыми исключениями, функции, работающие в рамках плана Flex Consumption, масштабируются на независимых экземплярах. Исключения включают триггеры HTTP и триггеры хранилища BLOB-объектов (Сетка событий). Каждый из этих типов триггеров масштабируется в виде группы в одних и тех же экземплярах. Аналогичным образом триггеры всех устойчивых функций также разделяют экземпляры и масштабируются вместе. Дополнительные сведения см. в разделе масштабирования для каждой функции.

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

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

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

По умолчанию приложения, работающие в плане потребления Flex, имеют ограничение общих 100 экземпляров. В настоящее время наименьшее максимальное число экземпляров равно 1, а наибольшее поддерживаемое значение числа экземпляров — 1000. При использовании команды az functionapp create для создания приложения функции в плане Flex Consumption используйте параметр --maximum-instance-count, чтобы задать эту максимальную численность экземпляров вашего приложения.

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

Хотя можно изменить максимальное количество экземпляров приложений Flex Consumption до 1000, квота на приложения будет достигнута ранее этого числа. Просмотрите квоты на использование памяти для региональной подписки для получения более подробной информации.

В этом примере создается приложение с ограничением на максимальное количество экземпляров 200.

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

В этом примере команда az functionapp scale config set используется для изменения максимального количества экземпляров для существующего приложения на 150:

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

В плане Consumption или Elastic Premium можно указать меньшее максимальное ограничение для приложения, изменив значение functionAppScaleLimit параметра конфигурации сайта. Для параметра functionAppScaleLimit можно задать неограниченное значение (0 или null) или значение от 1 до максимального значения для приложения.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

Скорость масштабирования

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

Скорость масштабирования

В планах Потребление и Премиум контроллер масштабов управляет скоростью добавления новых экземпляров. Для триггеров HTTP новые экземпляры выделяются не чаще одного раза в секунду. Для триггеров, не связанных с HTTP, новые экземпляры выделяются не более одного раза в 30 секунд. Масштабирование выполняется быстрее при работе в плане категории "Премиум".

Поведение при сжатии ресурсов

Масштабирование на основе событий автоматически уменьшает емкость при снижении спроса на функции. Это сокращение достигается путем освобождения экземпляров от их текущих выполнений функций, а затем удаления этих экземпляров. Это поведение регистрируется в режиме стока. Льготный период для выполняемых в настоящее время функций может продлиться до 10 минут для приложений плана потребления и до 60 минут для приложений плана Flex Consumption и Premium. Масштабирование на основе событий и такое поведение не применимы к приложениям плана "Выделенный".

К поведению масштабирования применяются следующие рекомендации:

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

Масштабирование для каждой функции

План потребления Flex является уникальным в том, что он реализует поведение масштабирования для каждой функции. При масштабировании по функциям, за исключением триггеров HTTP, триггеров BLOB (Сетка событий) и Durable функции, все остальные типы триггеров в вашем приложении масштабирутся на независимых экземплярах. Триггеры HTTP в вашем приложении масштабируются все вместе как группа на одних и тех же экземплярах, как и все триггеры Blob (Event Grid), а также все триггеры Устойчивые функции, которые имеют собственные совместные экземпляры.

Рассмотрим приложение-функцию, размещенное планом потребления Flex, которое имеет следующие функции:

В этом примере:

• Две триггерные функции HTTP (function1 и function2) выполняются вместе на своих экземплярах и масштабируются вместе в соответствии с параметрами параллелизма HTTP.
• Две долговечные функции (function3 и function4) работают вместе на своих экземплярах и масштабируются вместе на основе настроенных дросселей параллелизма.
• Активируемая функция function5 служебная шина выполняется самостоятельно и масштабируется независимо в соответствии с целевыми правилами масштабирования для очередей и тем службы.
• Активируемая функция function6 служебная шина выполняется самостоятельно и масштабируется независимо в соответствии с целевыми правилами масштабирования для очередей и тем службы.
• Триггер Центров событий (function7) выполняется в собственных экземплярах и независимо масштабируется в соответствии с правилами масштабирования для Центров событий на целевой основе.

Рекомендации и шаблоны для масштабируемых приложений

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

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

Дополнительные сведения о масштабировании в Python и Node.js см. в разделе "Масштабирование и производительность" руководства разработчика по Python для функций Azure и разделе "Масштабирование и параллелизм" руководства разработчика по Функциям Azure для Node.js.