шаблон выравнивания нагрузкиQueue-Based

Используйте очередь, которая выступает в качестве буфера между задачей и вызываемой службой. Этот подход сглаживает временные тяжелые нагрузки, которые могут вызвать сбой службы или время ожидания задачи. Это помогает свести к минимуму влияние пиков спроса на доступность и скорость реагирования задачи и службы.

Контекст и проблема

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

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

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

Решение

Поместите очередь между задачей и службой. Задача и служба выполняются асинхронно. Задача отправляет в очередь сообщение, содержащее данные, необходимые службе. Очередь служит буфером и сохраняет сообщение, пока служба не получит его. Служба извлекает сообщения из очереди и обрабатывает их. Запросы из нескольких задач, которые могут создаваться с высокой переменной скоростью, можно передавать в службу через одну очередь сообщений. На следующей схеме показано, как очередь может сгладить нагрузку на сервис.

На схеме показано, как очередь сообщений отделяет запросы задач переменной скорости от службы, которая обрабатывает их с согласованной скоростью. Поток перемещается слева направо. Слева отдельные стрелки ведут от трёх значков задач к центральной очереди сообщений, показывая, как задачи независимо отправляют запросы в одну и ту же очередь. Одна стрелка указывает от очереди сообщений к узлу службы в крайней правой части, показывая, как служба обрабатывает сообщения с постоянной скоростью.

Очередь отделяет задачи от службы, чтобы служба может обрабатывать сообщения в собственном темпе, даже если одновременные задачи создают большой объем запросов. Кроме того, задачи не задерживаются, если служба недоступна в момент, когда они публикуют сообщения в очередь.

Такой подход обеспечивает следующие преимущества:

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

• Это помогает повысить масштабируемость, так как количество очередей и количество служб может отличаться в соответствии с спросом.

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

Замечание

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

Проблемы и рекомендации

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

• Реализуйте логику приложения, которая управляет скоростью обработки сообщений службами, чтобы избежать подавляющего целевого ресурса. Избегайте передачи пиковых нагрузок спроса в следующую стадию системы. Протестируйте систему под нагрузкой, чтобы убедиться, что она обеспечивает требуемое выравнивание. Чтобы добиться требуемого выравнивания, настройте количество очередей и количество экземпляров служб, обрабатывающих сообщения.

• Очереди сообщений представляют собой механизм односторонней связи. Если задача ожидает ответа от службы, может потребоваться реализовать механизм, который служба может использовать для отправки ответа. Дополнительные сведения см. в разделе Параметры обмена сообщениями в Azure.

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

• Если средняя ставка производителя превышает уровень потребителя, очередь продолжает расти и увеличивается задержка. Отслеживайте глубину очереди и масштабируйте число потребителей в безопасных пределах либо снижайте нагрузку на стороне производителя.

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

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

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

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

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

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

• Необходимо отделить потребление запросов от пропускной способности обработки, чтобы повысить устойчивость и управление затратами.

Этот шаблон может быть не подходит, если:

• Вызывающей стороне требуется синхронный ответ с низкой задержкой.

• Объем рабочей нагрузки прогнозируемо низкий и стабильный, поэтому добавление сложности очередей дает мало преимуществ.

Проектирование рабочей нагрузки

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

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и гарантировать, что она восстанавливается до полнофункционального состояния после сбоя.	Подход, описанный в этом шаблоне, может обеспечить устойчивость к внезапным всплескам нагрузки за счет разделения поступления задач и их обработки. Он также может изолировать неисправности в обработке очередей, чтобы они не влияли на поступление. - RE:06 Масштабирование
Оптимизация затрат фокусируется на поддержании и улучшении окупаемости ваших инвестиций в рабочие процессы.	Поскольку обработка нагрузки отделена от приема запросов или задач, этот подход позволяет снизить необходимость в выделении избыточных ресурсов для обработки пиковой нагрузки. - CO:12 Затраты на масштабирование
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Этот подход позволяет намеренно разрабатывать производительность пропускной способности, так как потребление запросов не требует корреляции с скоростью обработки. - Pe:05 Масштабирование и секционирование

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Example

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

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

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

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

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

Дальнейшие действия

При реализации этого шаблона следует принять во внимание следующие рекомендации:

• Варианты асинхронного обмена сообщениями в Azure: очереди сообщений по своей природе асинхронны. Возможно, потребуется изменить логику приложения задачи, если она взаимодействует непосредственно со службой. Аналогичным образом может потребоваться рефакторинг службы для приема запросов из очереди сообщений.

• Выбор между службами обмена сообщениями Azure: Дополнительные сведения помогут вам выбрать механизм обмена сообщениями и организации очередей в приложениях Azure.

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

• Архитектурный стиль Web-Queue-Worker: и веб-компонент, и рабочий компонент не хранят состояние. Сведения о состоянии сеанса можно сохранять в распределенном кэше. Рабочая роль выполняет длительную работу асинхронно и может быть активирована сообщениями в очереди или выполняться по расписанию для пакетной обработки.

Связанные ресурсы

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

• Шаблон регулирования. Простой способ реализации регулирования в службе — использовать выравнивание нагрузки на основе очередей и направлять все запросы в службу через очередь сообщений. Служба может обрабатывать запросы с такой скоростью, чтобы не исчерпывать нужные ей ресурсы и снижать вероятность конкуренции за ресурсы.