Параллелизм в Функциях Azure

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

Функции предоставляют два основных способа управления параллелизмом:

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

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

Масштабирование и параллелизм

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

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

Баланс масштабирования и параллелизма, который вы пытаетесь достичь в приложении, зависит от того, где могут возникнуть узкие места: в обработке (ограничения процесса с интенсивным ЦП) или в нижней службе (ограничения на основе ввода-вывода).

Исправлена одновременная обработка для каждого экземпляра

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

Вы можете переопределить значения по умолчанию для конкурентности большинства триггеров, задав определённую степень конкурентности для каждого экземпляра данного типа триггера. Для многих триггеров вы настраиваете параметры параллелизма в файлеhost.json. Например, триггер служебной шины Azure предоставляет как параметр MaxConcurrentCalls , так и MaxConcurrentSessions параметр в host.json. Эти параметры работают вместе, чтобы управлять максимальным количеством сообщений, которые каждое приложение-функция обрабатывает одновременно на каждом экземпляре.

В некоторых сценариях масштабирования на основе целевого объекта, например при использовании триггера Apache Kafka или Azure Cosmos DB, конфигурация параллелизма находится в объявлении функции, а не в файле host.json . Другие типы триггеров имеют встроенные механизмы для распределения нагрузки вызовов между экземплярами. Например, Центры событий Azure и Azure Cosmos DB используют схему на основе секционирования.

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

Параллелизм триггера HTTP

Применяется только к плану потребления Flex

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

План потребления Flex масштабирует все функции триггера HTTP в виде группы. Дополнительные сведения см. в статье о масштабировании для каждой функции.

В следующей таблице указывается параметр параллелизма по умолчанию для триггеров HTTP для данного экземпляра на основе настроенного размера памяти экземпляра:

^*В приложениях на Python все размеры экземпляров по умолчанию используют уровень параллелизма HTTP-триггера, равный единице.

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

Если необходимо точно настроить параллелизм HTTP, это можно сделать с помощью Azure CLI. Дополнительные сведения см. в разделе "Настройка ограничений параллелизма HTTP".

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

Определение оптимальной фиксированной параллельности для экземпляра

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

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

Динамический параллелизм

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

Льготы

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

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

Конфигурация динамического параллелизма

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

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

Вы можете включить динамическую параллельность в вашем приложении-функции, добавив в файл host.json следующие параметры:

    { 
        "version": "2.0", 
        "concurrency": { 
            "dynamicConcurrencyEnabled": true, 
            "snapshotPersistenceEnabled": true 
        } 
    } 

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

Диспетчер параллелизма

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

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

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

Поддержка расширений.

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

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

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

• Рекомендации по надежным функциям Azure
• Руководство разработчиков Функций Azure
• Azure Functions triggers and bindings (Триггеры и привязки в Функциях Azure)