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

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

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

Файлы кода функции хранятся в файловых ресурсах Azure в основной учетной записи хранения службы "Функции Azure". При удалении основной учетной записи хранения приложения-функции файлы кода функции удаляются и не могут быть восстановлены.

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

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

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

Scale controller monitoring events and creating instances

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

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

Основные сведения о действиях при масштабировании

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

  • Максимальные экземпляры: одно приложение-функция масштабируется только до максимального допустимого плана. Один экземпляр может обрабатывать одновременно более одного сообщения или запроса, поэтому для количества одновременных выполнений не установлено ограничение. При необходимости можно указать меньшее значение для регулирования масштаба.
  • Частота выделения нового экземпляра. Для триггеров HTTP новые экземпляры выделяются не чаще одного раза в секунду. Для триггеров, отличных от HTTP, новые экземпляры выделяются не чаще, чем каждые 30 секунд. Масштабирование выполняется быстрее при работе в плане категории "Премиум".
  • Масштабирование на основе целевого объекта. Масштабирование на основе целевых приложений обеспечивает быструю и интуитивно понятную модель масштабирования для клиентов и в настоящее время поддерживается для служебная шина очередей и разделов, служба хранилища очередей, центров событий и расширений Cosmos DB. Обязательно проверьте масштабирование на основе целевых объектов, чтобы понять их поведение масштабирования.

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

Возможно, вам нужно будет ограничить максимальное число экземпляров, которое приложение использует для масштабирования. Это наиболее распространено в случаях, когда нижестоящий компонент, например база данных, имеет ограниченную пропускную способность. По умолчанию функции плана потребления масштабируются до 200 экземпляров, а функции плана категории "Премиум" будут масштабироваться до уровня в 100 экземпляров. Вы можете указать более низкое значение для конкретного приложения, изменив значение 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 минут для приложений плана Premium. Масштабирование на основе событий и это поведение не применяются к приложениям плана "Выделенный".

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

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

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

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

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

Модель выставления счетов

Выставление счетов для разных планов подробно описано на странице цен на Функции Azure. Использование вычисляется на уровне приложения-функции. При этом учитывается только время выполнения кода функции. Счета выставляются по следующим единицам:

  • Потребление ресурсов в гигабайтах в секунду (ГБ/с). Вычисляется как сочетание объема памяти и времени выполнения для всех функций, выполняемых в приложении-функции.
  • Выполнения. Вычисляются при каждом выполнении функции в ответ на событие.

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

Следующие шаги

Дополнительные сведения см. в следующих разделах: