Масштабирование на основе событий в Функциях Azure
В планах "Потребление", "Использование Flex" и "Премиум" Функции Azure масштабирует ресурсы, добавляя дополнительные экземпляры на основе числа событий, которые активируют функцию.
Внимание
План потребления Flex в настоящее время находится в предварительной версии.
Способ масштабирования приложения-функции зависит от плана размещения:
План потребления. Каждый экземпляр узла Функций в плане потребления ограничен, как правило, 1,5 ГБ памяти и одним ЦП. Экземпляр узла поддерживает все приложение-функцию. Таким образом, все функции в ресурсе общего ресурса приложения-функции в экземпляре масштабируются одновременно. Когда приложения-функции используют тот же план потребления, они по-прежнему масштабируются независимо.
План потребления Flex: план использует детерминированную стратегию масштабирования для каждой функции, где каждая функция масштабируется независимо, за исключением HTTP, BLOB-объектов и Устойчивые функции активируемых функций, которые масштабируются в собственных группах. Дополнительные сведения см. в статье о масштабировании для каждой функции. Затем эти экземпляры масштабируются на основе параллелизма запросов.
План "Премиум": конкретный размер плана Premium определяет доступную память и ЦП для всех приложений этого плана в этом экземпляре. План масштабирует свои экземпляры на основе потребностей масштабирования приложений в плане и приложений в рамках плана по мере необходимости.
Файлы кода функции хранятся в файловых ресурсах Azure в основной учетной записи хранения службы "Функции Azure". При удалении основной учетной записи хранения приложения-функции файлы кода функции удаляются и не могут быть восстановлены.
Масштабирование среды выполнения
Решение "Функции Azure" использует компонент, называемый контроллером масштабирования, чтобы отслеживать скорость событий и определять, необходимо ли горизонтально увеличить или уменьшить масштаб. Контроллер масштабирования использует эвристику для каждого типа триггеров. Например, при использовании триггера хранилища очередей Azure используется масштабирование на основе целевого объекта.
Единицей масштабирования для Функций Azure является приложение-функция. При развертывании приложения-функции выделяются дополнительные ресурсы для выполнения нескольких экземпляров узла Функций Azure. И наоборот, когда потребность в вычислительных ресурсах уменьшается, контроллер масштабирования удаляет экземпляры узла функции. Число экземпляров в конечном итоге "масштабируется" при отсутствии функций в приложении-функции.
Холодный запуск
Если приложение-функция перестает работать в течение нескольких минут, платформа может решить масштабировать количество экземпляров, на которых приложение выполняется до нуля. В следующем запросе добавлена задержка масштабирования от нуля до единицы. Эта задержка называется холодным запуском. Количество зависимостей, необходимых приложению-функции, может повлиять на время холодного запуска. Холодный запуск является более серьезной проблемой для синхронных операций, таких как триггеры HTTP, которые должны возвращать ответ. Если холодные запуски влияют на ваши функции, рассмотрите возможность использования плана, отличного от потребления. Другие планы предлагают эти стратегии для устранения или устранения холодных запусков:
План "Премиум": поддерживает как предварительно подготовленные экземпляры, так и всегда готовые экземпляры с минимальным количеством экземпляров.
План потребления Flex: поддерживает необязательное количество всегда готовых экземпляров, которые можно определить на основе масштабирования каждого экземпляра.
Выделенный план: сам план не масштабируется динамически, но вы можете непрерывно запускать приложение с включенным параметром Always on .
Основные сведения о действиях при масштабировании
Масштабирование может отличаться в зависимости от нескольких факторов, а приложения масштабируются по-разному в зависимости от выбранных триггеров и языка. Следует учитывать следующие особенности поведения масштабирования:
- Максимальные экземпляры: одно приложение-функция масштабируется только до максимального допустимого плана. Однако один экземпляр может обрабатывать несколько сообщений или запросов одновременно. При необходимости можно указать меньшее значение для регулирования масштаба.
- Частота выделения нового экземпляра. Для триггеров HTTP новые экземпляры выделяются не чаще одного раза в секунду. Для триггеров, отличных от HTTP, новые экземпляры выделяются не чаще, чем каждые 30 секунд. Масштабирование выполняется быстрее при работе в плане категории "Премиум".
- Масштабирование на основе целевого объекта. Масштабирование на основе целевого объекта обеспечивает быструю и интуитивно понятную модель масштабирования для клиентов и в настоящее время поддерживается для служебная шина очередей и разделов, очередей хранилища, Центров событий, Apache Kafka и расширений Azure Cosmos DB. Обязательно проверьте масштабирование на основе целевых объектов, чтобы понять их поведение масштабирования.
- Масштабирование для каждой функции: с некоторыми заметными исключениями функции, работающие в масштабе плана потребления Flex на независимых экземплярах. Исключения включают триггеры HTTP и триггеры хранилища BLOB-объектов (Сетка событий). Каждый из этих типов триггеров масштабируется в виде группы в одних и тех же экземплярах. Аналогичным образом все триггеры Устойчивые функции также совместно используют экземпляры и масштабируются. Дополнительные сведения см. в разделе масштабирования для каждой функции.
- Максимально отслеживаемые триггеры: в настоящее время контроллер масштабирования может отслеживать только до 100 триггеров для принятия решений о масштабировании. Если у приложения более 100 триггеров на основе событий, решение о масштабировании принимается только на основе первых 100 триггеров, которые выполняются. Дополнительные сведения см. в рекомендациях и шаблонах для масштабируемых приложений.
Ограничение горизонтального масштабирования
Возможно, вы решите ограничить максимальное количество экземпляров, которые приложение может использовать для горизонтального масштабирования. Это наиболее распространено в случаях, когда подчиненный компонент, например база данных, имеет ограниченную пропускную способность. Максимальные ограничения масштабирования при выполнении различных планов размещения см. в разделе "Ограничения масштабирования".
План потребления Flex
По умолчанию приложения, работающие в плане потребления Flex, имеют ограничение общих 100 экземпляров. В настоящее время наименьшее максимальное число экземпляров равно40, а максимальное поддерживаемое максимальное значение числа экземпляров .1000 При использовании az functionapp create команды для создания приложения-функции в плане потребления Flex используйте --maximum-instance-count параметр, чтобы задать это максимальное количество экземпляров для приложения.
Обратите внимание, что в то время как можно изменить максимальное количество экземпляров приложений Flex Consumption до 1000, ваши приложения достигнут предел квоты, прежде чем достичь этого числа. Дополнительные сведения см . в квотах памяти региональной подписки.
В этом примере создается приложение с максимальным числом экземпляров 200:
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <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
Планы потребления и уровня "Премиум"
В плане потребления или эластичного класса 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>
Поведение масштабирования
Масштабирование на основе событий автоматически уменьшает емкость при снижении спроса на функции. Это делается путем очистки экземпляров своих текущих выполнений функций, а затем удаляет эти экземпляры. Это поведение регистрируется в режиме стока. Льготный период для выполняемых в настоящее время функций может продлиться до 10 минут для приложений плана потребления и до 60 минут для приложений плана Flex Consumption и Premium. Масштабирование на основе событий и это поведение не применяются к приложениям плана "Выделенный".
К поведению масштабирования применяются следующие рекомендации:
- Для приложений, работающих в Windows в плане потребления, только приложения, созданные после мая 2021 года, по умолчанию поддерживают режим очистки.
- Чтобы включить корректное завершение работы функций с помощью триггера Служебной шины, используйте расширение Служебной шины версии 4.2.0 или более поздней.
Масштабирование для каждой функции
Применяется только к плану потребления Flex (предварительная версия).
План потребления Flex является уникальным в том, что он реализует поведение масштабирования для каждой функции. При масштабировании для каждой функции, за исключением триггеров HTTP, триггеров BLOB-объектов (Сетка событий) и Устойчивые функции, все остальные типы триггеров функций в масштабе приложения на независимых экземплярах. Триггеры HTTP в приложении все масштабируются в виде группы в одних и тех же экземплярах, как и все триггеры больших двоичных объектов (сетка событий) и все триггеры Устойчивые функции, которые имеют собственные общие экземпляры.
Рассмотрим приложение-функцию, размещенное в плане потребления Flex, которое имеет следующие функции:
| function1 | function2 | function3 | function4 | function5 | function6 | function7 |
|---|---|---|---|---|---|---|
| Триггер HTTP | Триггер HTTP | Триггер оркестрации (устойчивый) | Триггер действия (устойчивый) | Триггер служебной шины | Триггер служебной шины | Триггер Центров событий |
В этом примере:
- Две триггерные функции HTTP (
function1иfunction2) выполняются вместе на своих экземплярах и масштабируются вместе в соответствии с параметрами параллелизма HTTP. - Две устойчивые функции (
function3иfunction4) работают вместе на своих экземплярах и масштабируются вместе на основе настроенных регулирования параллелизма. - Активируемая функция
function5служебной шины выполняется самостоятельно и масштабируется независимо в соответствии с правилами масштабирования на основе целевого объекта для служебная шина очередей и разделов. - Активируемая функция
function6служебной шины выполняется самостоятельно и масштабируется независимо в соответствии с правилами масштабирования на основе целевого объекта для служебная шина очередей и разделов. - Триггер Центров событий (
function7) выполняется в собственных экземплярах и масштабируется независимо в соответствии с правилами масштабирования на основе целевых центров событий.
Рекомендации и шаблоны для масштабируемых приложений
В приложении-функции существует множество аспектов, влияющих на качество его масштабирования, в том числе конфигурация узла, занимаемая память среды выполнения и эффективность использования ресурсов. Дополнительные сведения см. в разделе Рекомендации по масштабируемости. Вам также следует учитывать поведение подключений при масштабировании приложения-функции. См. дополнительные сведения об управлении подключениями в службе "Функции Azure".
Если у приложения более 100 функций, использующих триггеры на основе событий, рассмотрите возможность разбиения приложения в одно или несколько приложений, где каждое приложение имеет менее 100 функций на основе событий.
Дополнительные сведения о масштабировании в Python и Node.js см. в разделах о масштабировании и параллелизме в руководстве разработчика Python для Функций Azure и руководстве разработчика Node.js для Функций Azure.
Следующие шаги
Дополнительные сведения см. в следующих разделах: