В этой статье приводятся рекомендации по оптимизации масштабируемости и производительности при использовании Центры событий Azure и Функции Azure вместе в приложениях.
Группирование функций
Как правило, функция инкапсулирует единицу работы в потоке обработки событий. Например, функция может преобразовать событие в новую структуру данных или дополнить данные для подчиненных приложений.
В Функциях приложение-функция предоставляет контекст выполнения для функций. Поведение приложения-функции применяется ко всем функциям, на которые размещается приложение-функция. Функции в приложении-функции развертываются вместе и масштабируются вместе. Все функции в приложении-функции должны использовать один и тот же язык.
Группирование функций в приложения-функции может повлиять на производительность и масштабирование приложений-функций. Вы можете группировать в соответствии с правами доступа, развертыванием и шаблонами использования, которые вызывают код.
Рекомендации по использованию функций для группирования и других аспектов см. в рекомендациях по надежному Функции Azure и повышению производительности и надежности Функции Azure.
В следующем списке приведены рекомендации по группировке функций. В этом руководстве рассматриваются аспекты хранения и группы потребителей:
Размещение одной функции в приложении-функции: если центры событий активируют функцию, можно уменьшить количество разных функций между этой функцией и другими функциями, изолировать функцию в собственном приложении-функции. Изоляция особенно важна, если другие функции являются ресурсоемкими ЦП или памятью. Этот метод помогает, так как каждая функция имеет собственный объем памяти и шаблоны использования, которые могут напрямую повлиять на масштабирование приложения-функции, на котором он размещен.
Предоставьте каждому приложению-функции собственную учетную запись хранения: избегайте совместного использования учетных записей хранения между приложениями-функциями. Кроме того, если приложение-функция использует учетную запись хранения, не используйте ее для других операций хранения или потребностей. Особенно важно избежать совместного использования учетных записей хранения для функций, которые активируют центры событий, так как такие функции могут иметь большой объем транзакций хранения из-за контрольных точек.
Создайте выделенную группу потребителей для каждого приложения-функции: группа потребителей — это представление концентратора событий. Разные группы потребителей имеют разные представления, что означает, что состояния, позиции и смещения могут отличаться. Группы потребителей позволяют нескольким потребляющим приложениям иметь собственные представления потока событий, а также читать поток независимо по своему темпу и с собственными смещениями. Дополнительные сведения о группах потребителей см. в разделе "Функции и терминология" в Центры событий Azure.
Группа потребителей имеет одно или несколько потребительских приложений, связанных с ним, и приложение-получатель может использовать одну или несколько групп потребителей. В решении потоковой обработки каждое приложение-потребитель приравнивается к группе потребителей. Приложение-функция является основным примером приложения-получателя. На следующей схеме представлен пример двух приложений-функций, которые считываются из концентратора событий, где каждое приложение имеет собственную выделенную группу потребителей:
Не делитесь группами потребителей между приложениями-функциями и другими потребительскими приложениями. Каждое приложение-функция должно быть отдельным приложением с собственной назначенной группой потребителей, чтобы обеспечить целостность смещения для каждого потребителя и упростить зависимости в архитектуре потоковой передачи событий. Такая конфигурация, а также предоставление каждой функции, активируемой концентратором событий, собственной функции и учетной записи хранения, помогает настроить основу для оптимальной производительности и масштабирования.
Планы размещения функций
Существует несколько вариантов размещения приложений-функций, и важно ознакомиться с их возможностями. Сведения об этих вариантах размещения см. в Функции Azure параметрах размещения. Обратите внимание на масштаб параметров.
План потребления — это план потребления по умолчанию. Приложения-функции в плане потребления масштабируются независимо и наиболее эффективны, когда они избегают длительных задач.
Планы "Премиум" и "Выделенные" часто используются для размещения нескольких приложений-функций и функций, которые являются более интенсивными для ЦП и памяти. При использовании выделенного плана функции выполняются в плане обслуживания приложение Azure по обычным тарифам Служба приложений плана. Важно отметить, что все приложения-функции в этих планах совместно используют ресурсы, выделенные для плана. Если функции имеют разные профили нагрузки или уникальные требования, рекомендуется разместить их в разных планах, особенно в приложениях потоковой обработки.
Приложения контейнеров Azure обеспечивают интегрированную поддержку разработки, развертывания и управления контейнерными приложениями-функциями на Функции Azure. Это позволяет выполнять функции на основе событий в полностью управляемой среде Kubernetes с встроенной поддержкой мониторинга с открытым кодом, mTLS, Dapr и KEDA.
Масштабирование Центров событий
При развертывании пространства имен Центров событий необходимо задать несколько важных параметров, необходимых для обеспечения максимальной производительности и масштабирования. В этом разделе рассматриваются категории "Стандартный" центров событий и уникальные функции этого уровня, влияющие на масштабирование при использовании функций. Дополнительные сведения о уровнях Центров событий см. в разделе "Базовый" и "Стандартный" и "Премиум" и "Выделенные".
Пространство имен Центров событий соответствует кластеру Kafka. Сведения о том, как центры событий и Kafka связаны друг с другом, см. в статье "Что такое Центры событий Azure для Apache Kafka".
Общие сведения об единицах пропускной способности (TUS)
На уровне "Центры событий " Стандартный" пропускная способность классифицируется как объем данных, вводимых и считываемых из пространства имен на единицу времени. Единицы измерения пропускной способности являются предварительно приобретенными единицами пропускной способности.
Счета выставляются почасовой основе.
Все центры событий в пространстве имен имеют общий доступ к TUS. Чтобы правильно вычислить потребности в емкости, необходимо учитывать все приложения и службы, как издатели, так и потребители. Функции влияют на количество байтов и событий, опубликованных в концентраторе событий и считываемых из нее.
Акцент на определение количества единиц TUS находится на точке входящего трафика. Однако агрегат для потребительских приложений, включая скорость обработки этих событий, также должен быть включен в вычисление.
Дополнительные сведения об единицах пропускной способности Центров событий см. в разделе "Единицы пропускной способности".
Увеличение масштаба с помощью автоматического раздувания
Автоматическое расширение можно включить в пространстве имен Центров событий для удовлетворения ситуаций, в которых нагрузка превышает настроенное количество единиц. Использование автоматического раздувания предотвращает регулирование приложения и помогает гарантировать, что обработка, включая прием событий, продолжается без нарушений. Так как параметр TU влияет на затраты, использование автоматического раздувания помогает устранить проблемы с чрезмерной подготовкой.
Автоматическое расширение — это функция Центров событий, которые часто путаются с автомасштабированием, особенно в контексте бессерверных решений. Однако автоматическое увеличение, в отличие от автомасштабирования, не приводит к уменьшению масштаба, если добавленная емкость больше не нужна.
Если приложению требуется емкость, превышающая максимально допустимое количество единиц, рассмотрите возможность использования уровня "Премиум" центров событий или уровня "Выделенный".
Секции и параллельные функции
При создании концентратора событий необходимо указать количество секций. Число секций остается фиксированным и не может быть изменено, кроме уровней "Премиум" и "Выделенный". Если центры событий активируют приложения функций, возможно, количество одновременных экземпляров может быть равно количеству секций.
В планах размещения "Потребление" и "Премиум" экземпляры приложения-функции будут динамически масштабироваться для удовлетворения количества секций при необходимости. Выделенный план размещения выполняет функции в плане Служба приложений и требует вручную настроить экземпляры или настроить схему автомасштабирования. Дополнительные сведения см. в разделе "Выделенные планы размещения" для Функции Azure.
В конечном счете, связь между числом секций и экземплярами функций или потребителями идеально подходит для максимальной пропускной способности в решении потоковой обработки. Чтобы достичь оптимального параллелизма, у нескольких потребителей в группе потребителей. Для функций эта цель преобразуется во многие экземпляры функции в плане. Результат называется параллелизмом на уровне секции или максимальной степенью параллелизма, как показано на следующей схеме:
Возможно, нужно настроить как можно больше секций, чтобы достичь максимальной пропускной способности и учитывать возможность более высокого объема событий. Однако существует несколько важных факторов, которые следует учитывать при настройке множества разделов:
- Больше секций может привести к большей пропускной способности: так как степень параллелизма — это количество потребителей (экземпляров функций), чем больше секций, тем выше одновременная пропускная способность. Этот факт важен при совместном использовании указанного количества единиц TUS для концентратора событий с другими потребительскими приложениями.
- Для дополнительных функций может потребоваться больше памяти: по мере увеличения числа экземпляров функций, поэтому объем памяти ресурсов в плане увеличивается. В какой-то момент слишком много секций может ухудшать производительность для потребителей.
- Существует риск обратного давления от подчиненных служб: по мере создания дополнительной пропускной способности вы рискуете подавляющими подчиненными службами или получением обратного давления от них. Выдумка потребителей должна учитываться при рассмотрении последствий окружающих ресурсов. Возможные последствия включали регулирование из других служб, насыщенности сети и других форм состязания ресурсов.
- Секции могут быть разреженными: сочетание множества секций и небольшого объема событий может привести к данным, которые разрежены между секциями. Вместо этого меньшее количество секций может обеспечить более высокую производительность и использование ресурсов.
Доступность и согласованность
Если ключ секции или идентификатор не указан, центры событий перенаправляет входящее событие в следующую доступную секцию. Эта практика обеспечивает высокий уровень доступности и помогает повысить пропускную способность для потребителей.
Если требуется упорядочение набора событий, производитель событий может указать, что для всех событий набора необходимо использовать определенную секцию. Приложение-получатель, которое считывает из секции, получает события в правильном порядке. Этот компромисс обеспечивает согласованность, но компрометирует доступность. Не используйте этот подход, если порядок событий не должен быть сохранен.
Для функций порядок достигается, когда события публикуются в определенной секции, а активированная функция Центров событий получает аренду в том же разделе. В настоящее время возможность настройки секции с выходной привязкой Центров событий не поддерживается. Вместо этого лучше всего использовать один из пакетов SDK центров событий для публикации в определенном разделе.
Дополнительные сведения о том, как центры событий поддерживают доступность и согласованность, см. в разделе "Доступность и согласованность" в Центрах событий.
Триггер Центров событий
В этом разделе рассматриваются параметры и рекомендации по оптимизации функций, которые активируют центры событий. Факторы включают пакетную обработку, выборку и связанные функции, влияющие на поведение привязки триггера концентратора событий.
Пакетная обработка триггерных функций
Вы можете настроить функции, активирующие концентратор событий для обработки пакета событий или одного события за раз. Обработка пакета событий может быть более эффективной при уменьшении некоторых затрат на вызовы функций. Если не требуется обрабатывать только одно событие, функция должна быть настроена для обработки нескольких событий при вызове.
Включение пакетной обработки для привязки триггера Центров событий зависит от языков:
- JavaScript, Python и другие языки обеспечивают пакетную обработку при задании свойства кратности многим в файле function.json для функции.
- В C# кратность настраивается автоматически, если массив назначается для типа в атрибуте EventHubTrigger .
Дополнительные сведения о включении пакетной обработки см. в Центры событий Azure триггере для Функции Azure.
Настройки триггера
Несколько параметров конфигурации в файле host.json играют ключевую роль в характеристике производительности привязки триггера Центров событий для функций:
- maxEventBatchSize: этот параметр представляет максимальное количество событий, которые функция может получать при вызове. Если число полученных событий меньше этого количества, функция по-прежнему вызывается с таким количеством событий, как доступно. Не удается задать минимальный размер пакета.
- prefetchCount: число предварительных выборок является одним из наиболее важных параметров при оптимизации производительности. Базовый канал AMQP ссылается на это значение, чтобы определить, сколько сообщений требуется получить и кэшировать для клиента. Число предварительных выборок должно быть больше или равно значению maxEventBatchSize и обычно имеет значение кратного значения. При задании этого значения значение меньше параметра maxEventBatchSize может повредить производительность.
- batchCheckpointFrequency: при обработке пакетов функций это значение определяет частоту создания контрольных точек. Значение по умолчанию равно 1, что означает, что функция успешно обрабатывает один пакет. Контрольная точка создается на уровне секции для каждого читателя в группе потребителей. Сведения о том, как этот параметр влияет на воспроизведение и повторные попытки событий, см. в разделе "Центр событий", активировав функцию Azure: воспроизведение и повторные попытки (запись блога).
Выполните несколько тестов производительности, чтобы определить значения, заданные для привязки триггера. Рекомендуется изменять параметры постепенно и последовательно измерять их для точной настройки этих параметров. Значения по умолчанию являются разумной отправной точкой для большинства решений обработки событий.
Назначение контрольных точек
Контрольные точки помечают или фиксируют позиции чтения в последовательности событий секции. Это ответственность узла функций к контрольной точке по мере обработки событий и выполнение параметра частоты пакетной контрольной точки. Дополнительные сведения о контрольной точке см. в разделе "Функции и терминология" в Центры событий Azure.
Следующие понятия помогают понять связь между контрольными точками и способом обработки событий функции:
- Исключения по-прежнему учитываются в направлении успешного выполнения. Если процесс функции не завершает работу во время обработки событий, завершение функции считается успешным, даже если произошли исключения. После завершения функции узел Функций оценивает batchCheckpointFrequency. Если это время для контрольной точки, он создает один, независимо от того, были ли исключения. Тот факт, что исключения не влияют на контрольные точки, не должны влиять на правильное использование проверки исключений и обработки.
- Вопросы частоты пакетной службы: в решениях потоковой передачи событий с большим объемом может быть полезно изменить параметр batchCheckpointFrequency на значение больше 1. Увеличение этого значения может снизить скорость создания контрольных точек и, как следствие, количество операций ввода-вывода хранилища.
- Повторы могут произойти: каждый раз, когда функция вызывается с привязкой триггера Центров событий, она использует последнюю контрольную точку, чтобы определить, где возобновить обработку. Смещение для каждого потребителя сохраняется на уровне секции для каждой группы потребителей. Воспроизведение происходит, когда контрольная точка не возникает во время последнего вызова функции, и функция вызывается снова. Дополнительные сведения о повторяющихся и дедупликационных методах см. в разделе Idempotency.
Понимание контрольных точек становится критически важным при рассмотрении рекомендаций по обработке ошибок и повторных попыток, описанной далее в этой статье.
Выборка телеметрии
Функции обеспечивают встроенную поддержку Application Insights, расширение Azure Monitor, которое предоставляет возможности мониторинга производительности приложений. С помощью этой функции можно записывать сведения о действиях функции, производительности, исключениях среды выполнения и т. д. Дополнительные сведения см. в обзоре Application Insights.
Эта мощная возможность предлагает некоторые ключевые варианты конфигурации, влияющие на производительность. Ниже приведены некоторые важные параметры и рекомендации по мониторингу и производительности.
- Включение выборки телеметрии. Для сценариев высокой пропускной способности необходимо оценить объем данных телеметрии и необходимых сведений. Рекомендуется использовать функцию выборки телеметрии в Application Insights, чтобы избежать снижения производительности функции с ненужными данными телеметрии и метрик.
- Настройка параметров агрегирования. Проверьте и настройте частоту агрегирования и отправки данных в Application Insights. Этот параметр конфигурации находится в файле host.json вместе с множеством других параметров выборки и ведения журнала. Дополнительные сведения см. в разделе "Настройка агрегатора".
- Отключить AzureWebJobDashboard: для приложений, предназначенных для среды выполнения функций версии 1.x, этот параметр сохраняет строка подключения в учетную запись хранения, которую пакет SDK Azure использует для хранения журналов для панели мониторинга веб-заданий. Если Application Insights используется вместо панели мониторинга веб-заданий, этот параметр следует удалить. Дополнительные сведения см. в статье AzureWebJobsDashboard.
Если Application Insights включен без выборки, отправляется все данные телеметрии. Отправка данных обо всех событиях может негативно повлиять на производительность функции, особенно в сценариях потоковой передачи событий высокой пропускной способности.
Использование преимуществ выборки и постоянного оценки соответствующего объема телеметрии, необходимого для мониторинга, имеет решающее значение для оптимальной производительности. Телеметрия должна использоваться для общей оценки работоспособности платформы и для случайного устранения неполадок, а не для сбора основных бизнес-метрик. Дополнительные сведения см. в разделе Настройка выборки.
Выходные привязки
Используйте выходную привязку Центров событий для Функции Azure, чтобы упростить публикацию в потоке событий из функции. Преимущества использования этой привязки включают:
- Управление ресурсами. Привязка обрабатывает жизненные циклы клиентов и подключений для вас и снижает вероятность проблем, которые могут возникнуть при исчерпании портов и управлении пулом подключений.
- Меньше кода: привязка абстрагирует базовый пакет SDK и уменьшает объем кода, который необходимо опубликовать события. Это помогает писать код, который проще писать и поддерживать.
- Пакетная обработка. Для нескольких языков пакетная обработка поддерживается для эффективной публикации в потоке событий. Пакетная обработка может повысить производительность и упростить код, отправляющий события.
Настоятельно рекомендуется просмотреть список языков, поддерживаемых функциями , и руководства разработчика по этим языкам. Раздел "Привязки" для каждого языка содержит подробные примеры и документацию.
Пакетная обработка при публикации событий
Если функция публикует только одно событие, настройка привязки для возврата значения является общим подходом, который полезно, если выполнение функции всегда заканчивается оператором, отправляющим событие. Этот метод следует использовать только для синхронных функций, возвращающих только одно событие.
Пакетная обработка рекомендуется повысить производительность при отправке нескольких событий в поток. Пакетная обработка позволяет привязке публиковать события наиболее эффективным способом.
Поддержка использования выходной привязки для отправки нескольких событий в Центры событий доступна в C#, Java, Python и JavaScript.
Вывод нескольких событий с помощью модели in-process (C#)
Используйте типы ICollector и IAsyncCollector при отправке нескольких событий из функции в C#.
- ICollector <T>. Метод Add() можно использовать как в синхронных, так и в асинхронных функциях. Он выполняет операцию добавления сразу после вызова.
- IAsyncCollector <T>. Метод AddAsync() подготавливает события для публикации в потоке событий. При написании асинхронной функции следует использовать IAsyncCollector для более эффективного управления опубликованными событиями.
Примеры использования C# для публикации одного и нескольких событий см. в Центры событий Azure выходной привязке для Функции Azure.
Вывод нескольких событий с помощью модели изолированной рабочей роли (C#)
В зависимости от версии среды выполнения Функций модель изолированной рабочей роли будет поддерживать различные типы параметров, передаваемых в выходную привязку. Для нескольких событий массив используется для инкапсулирования набора. Рекомендуется просмотреть атрибуты выходной привязки и сведения об использовании для изолированной модели и заметить различия между версиями расширений.
Регулирование и обратное давление
Рекомендации по регулированию применяются не только к выходным привязкам, но не только для центров событий, но и для служб Azure, таких как Azure Cosmos DB. Важно ознакомиться с ограничениями и квотами, применяемыми к этим службам, и планировать их соответствующим образом.
Чтобы обрабатывать подчиненные ошибки с помощью модели in-process, можно упаковать AddAsync и FlushAsync в обработчик исключений для функций .NET, чтобы перехватывать исключения из IAsyncCollector. Другим вариантом является использование пакетов SDK центров событий непосредственно вместо использования выходных привязок.
При использовании изолированной модели для функций структурированная обработка исключений должна использоваться для ответственного перехвата исключений при возврате выходных значений.
Код функции
В этом разделе рассматриваются ключевые области, которые необходимо учитывать при написании кода для обработки событий в функции, которая активирует центры событий.
Асинхронное программирование
Мы рекомендуем написать функцию для использования асинхронного кода и избежать блокировок вызовов, особенно при использовании вызовов ввода-вывода.
Ниже приведены рекомендации, которые следует следовать при написании функции для асинхронной обработки:
- Все асинхронные или все синхронные: если функция настроена асинхронно, все вызовы ввода-вывода должны быть асинхронными. В большинстве случаев частично асинхронный код хуже, чем код, который полностью синхронен. Выберите асинхронный или синхронный и придерживаться выбранного варианта.
- Избегайте блокирующих вызовов: блокировка вызовов возвращается вызывающему объекту только после завершения вызова, в отличие от асинхронных вызовов, которые возвращаются немедленно. Пример в C# — вызов task.Result или Task.Wait для асинхронной операции.
Дополнительные сведения о блокировке вызовов
Использование блокирующих вызовов асинхронных операций может привести к нехватке пула потоков и привести к сбою процесса функции. Сбой происходит, так как блокирующий вызов требует создания другого потока для компенсации исходного вызова, который теперь ожидает. В результате для выполнения операции требуется в два раза больше потоков.
Избегайте этой синхронизации при асинхронном подходе, особенно важно, если задействованы центры событий, так как сбой функции не обновляет контрольную точку. При следующем вызове функции она может оказаться в этом цикле и, как представляется, зависает или медленно перемещается, так как выполнение функции в конечном итоге истекает.
Устранение неполадок с этим явлением обычно начинается с просмотра параметров триггера и выполнения экспериментов, которые могут включать увеличение количества секций. Исследования также могут привести к изменению нескольких вариантов пакетной обработки, таких как максимальный размер пакета или число предварительных выборок. Впечатление заключается в том, что это проблема пропускной способности или параметр конфигурации, которые необходимо настроить соответствующим образом. Однако основная проблема находится в самом коде и должна быть устранена.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующим участником.
Автор субъекта:
- Дэвид Баркол | Главный специалист по решению GBB
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Прежде чем продолжить, ознакомьтесь со следующими статьями:
- Мониторинг выполнения в Функциях Azure
- Функции Azure надежная обработка событий
- Проектирование Функции Azure для идентичных входных данных
- ASP.NET асинхронное руководство.
- триггер Центры событий Azure для Функции Azure