Многотенантность и Хранилище очередей Azure

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

Стратегии разбиения на разделы

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

Для сообщений размером 1 КиБ одна очередь имеет целевую пропускную способность до 2000 сообщений в секунду, а учетная запись хранения имеет максимальную скорость запросов в 20 000 сообщений в секунду. Размеры сообщений и шаблоны доступа влияют на пропускную способность, которой достигает ваша рабочая нагрузка. Сообщения очереди могут иметь размер до 64 КиБ. Для больших сообщений или расширенных функций брокера рекомендуется использовать Служебная шина Azure.

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

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

Модели изоляции

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

Соображение Общие очереди Очереди для каждого клиента Учетные записи хранения для каждого клиента
Изоляция данных Низкий. Приложение применяет изоляцию. Низкий-средний Высокий
Изоляция производительности Low Низкий. Большинство квот и ограничений применяются ко всей учетной записи хранения. Высокий
Сложность развертывания Low Medium Высокий
Операционная сложность Low Medium Высокий
Пример сценария Большое мультитенантное решение имеет общий уровень приложений. Выдаются URL-адреса подписей общего доступа (SAS) с областью клиента. Каждый арендатор имеет собственный штамп развертывания.

Note

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

Общие очереди

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

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

Очереди для каждого клиента

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

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

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

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

Учетные записи хранения для каждого клиента

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

Возможности Хранилища очередей с поддержкой мультитенантности

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

Подписи для совместного доступа

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

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

Используйте Valet Key pattern для выдачи ограниченных и сфокусированных маркеров SAS на уровне приложения. Проверьте подлинность клиента с помощью системы проверки подлинности вашего приложения, определите, к очереди какого арендатора клиент может получить доступ, и выдайте токен только для необходимых операций.

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

Делегирование пользователей с помощью SAS

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

Используйте короткие сроки существования токенов и запланируйте отмену доступа, если токен скомпрометирован. Чтобы сопоставить журналы приложения с журналами хранилища очередей, задайте идентификатор запроса клиента (x-ms-client-request-id) для запросов к хранилищу и зарегистрируйте его вместе с идентификатором арендатора.

Управление доступом на основе удостоверений

Хранилище очередей обеспечивает управление доступом на основе идентификации с помощью Microsoft Entra ID. Используйте управляемые удостоверения и управление доступом Azure на основе ролей, чтобы авторизовать приложение для доступа к очередям без хранения ключей учетной записи. Ограничьте доступ к очереди каждого клиента, когда для клиентов требуется прямой доступ. Авторизация на уровне очереди не изолирует сообщения отдельных арендаторов в общей очереди.

Encryption

Хранилище очередей шифрует данные при хранении с помощью ключей, управляемых Microsoft по умолчанию. Чтобы использовать ключи, управляемые клиентом, настройте учетную запись хранения для использования ключа шифрования для очередей с областью действия на уровне учетной записи при создании учетной записи. Вы не можете изменить эту область ключа шифрования после создания учетной записи.

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

Monitoring

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

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

Отслеживайте частоту запросов и ответы HTTP 500 и 503 для обнаружения очередей или учетных записей, которые приближаются к пределам масштабируемости. Сопоставляйте эту телеметрию с идентификаторами арендаторов, чтобы можно было определить арендаторов, использование которых влияет на общий ресурс.

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

Авторы

Ведение этой статьи осуществляет Microsoft. Следующие авторы написали эту статью.

Основной автор:

  • Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

Другие участники:

Чтобы увидеть непубличные профили в LinkedIn, войдите в LinkedIn.

  • Последнее обновление: