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