Поделиться через

Многотенантность и Azure Cosmos DB

  • Статья

В этой статье описываются функции Azure Cosmos DB, которые можно использовать для мультитенантных систем. В нем приведены рекомендации и примеры использования Azure Cosmos DB в мультитенантном решении.

Требования к мультитенантности

При планировании мультитенантного решения у вас есть два ключевых требования:

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

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

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

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

  • Ключ партиции для каждого арендатора часто используется для полностью мультитенантных решений, таких как программное обеспечение B2C в формате SaaS.
  • Учетная запись базы данных для каждого клиента часто используется для решений SaaS для бизнеса (B2B).

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

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

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

Модель "разделение ключа на арендатора"

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

Примечание.

Единица запроса (ЕЗ) — это логическая абстракция стоимости операции базы данных или запроса. Как правило, вы подготавливаете определенное количество единиц запросов в секунду (ЕЗ/с) для рабочей нагрузки, которая называется пропускной способностью.

Льготы

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

  • Упрощенное управление. У вас меньше учетных записей Azure Cosmos DB для управления.

Компромиссы

  • Конкуренция за ресурсы: Общая пропускная способность (РУ/с) между клиентами, находящимися в одном контейнере, может приводить к конфликтам во время пикового использования. Это состязание может создавать проблемы с шумными соседями и проблемы с производительностью, если у арендаторов высокие или перекрывающиеся рабочие нагрузки. Используйте эту модель изоляции для рабочих нагрузок, которым необходимы гарантированные RUs на одном арендаторе и которые могут совместно использовать пропускную способность.

  • Ограниченная изоляция: этот подход обеспечивает логическую изоляцию, а не физическую изоляцию. Это может не соответствовать строгим требованиям к изоляции с точки зрения производительности или безопасности.

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

Функции Azure Cosmos DB для мультитенантности

  • Управление пропускной способностью. Изучите функции, которые могут помочь контролировать шумную проблему соседа при использовании ключа секции для изоляции клиентов. Используйте такие функции, как перераспределение пропускной способности, всплесковая емкость и управление пропускной способностью в Java SDK.

  • Иерархические ключи секций: используйте Azure Cosmos DB, чтобы каждая логическая секция может увеличить размер до 20 ГБ. Если у вас есть один клиент, который должен хранить более 20 ГБ данных, рассмотрите возможность распространения данных по нескольким логическим секциям. Например, вместо одного ключа секции Contoso можно распределить ключи разделов, создав несколько ключей разделов для арендатора, например Contoso1 и Contoso2.

    При запросе данных арендатора можно использовать WHERE IN предложение для сопоставления всех ключей разделов. Вы также можете использовать иерархические ключи секций для предоставления большим клиентам хранилища размером более 20 ГБ, если у вас есть высокий объем клиентов. Для этого метода не требуется использовать искусственные ключи раздела или несколько значений ключей раздела для каждого арендатора.

    Предположим, что у вас есть рабочая нагрузка, которая изолирует тенантов по ключу раздела. Один клиент, Contoso, больше других как по размеру, так и по количеству операций записи, и он продолжает расти в размере. Вы можете использовать иерархические ключи секций, чтобы избежать риска невозможности обработки дополнительных данных для этого арендатора. Укажите TenantID в качестве ключа первого уровня, а затем добавьте второй уровень, например UserId. Если ожидается, что комбинация TenantID и UserID создаст логические разделы, превышающие ограничение в 20 ГБ, можно дополнительно разбить на другом уровне, например SessionID. Запросы, которые указывают либо TenantID, либо одновременно и TenantID, и UserID, эффективно направляются только в подмножество физических разделов, содержащих соответствующие данные, что позволяет избежать выполнения расширенного запроса. Если контейнер имеет 1000 физических секций, но определенное TenantId значение находится только в пяти физических секциях, запрос направляется на меньшее количество соответствующих физических секций.

    Если у вашего первого уровня недостаточно высокая кардинальность, и вы достигнете логического ограничения раздела в 20 ГБ по ключу раздела, рассмотрите возможность использования искусственного ключа раздела вместо иерархического ключа раздела.

Модель учетной записи базы данных на арендатора

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

Льготы

  • Высокая изоляция. Этот подход позволяет избежать конфликтов или помех из-за выделенных учетных записей Azure Cosmos DB и контейнеров, подготовленных для каждого уникального клиента.

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

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

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

Компромиссы

  • Увеличение управления. Этот подход более сложный, так как вы управляете несколькими учетными записями Azure Cosmos DB.

  • Более высокие затраты: большее количество аккаунтов означает, что необходимо подготовить пропускную способность для каждого ресурса в аккаунте для каждого клиента, например, для баз данных или контейнеров. Каждый раз, когда ресурсы выделяют Request Units (единицы запросов), затраты на Azure Cosmos DB увеличиваются.

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

Функции Azure Cosmos DB для мультитенантности

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

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

При использовании выделенной учетной записи Azure Cosmos DB для каждого клиента следует учитывать максимальное количество учетных записей Azure Cosmos DB на подписку Azure.

Полный список моделей изоляции

Потребность в рабочей нагрузке Ключ партиционирования для каждого клиента (рекомендуется) Контейнер для каждого клиента (общая пропускная способность) Контейнер для каждого клиента (выделенная пропускная способность) База данных для каждого арендатора Учетная запись базы данных для каждого клиента (рекомендуется)
Запросы между арендаторами Easy (контейнер выступает в качестве границы для запросов) Трудный Трудно Жёсткий Трудный
Плотность арендаторов Высокий уровень (самая низкая стоимость на арендатора) Средняя Низкий Низкий Низкий
Удаление данных клиента Легко Простое (удаление контейнера при выходе клиента) Простое (удаление контейнера при выходе клиента) Простота (удаление базы данных при выходе клиента) Простота (удаление базы данных при выходе клиента)
Изоляция безопасности доступа к данным Необходимо реализовать в приложении Контейнер RBAC Контейнер RBAC База данных RBAC RBAC
Георепликация Георепликация клиента невозможна Группировать клиентов в учетных записях базы данных на основе требований Группировать тенантов в учетных записях баз данных на основе требований Группировать клиентов в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований
Профилактика шума от соседей Нет Нет Да Да Да
Задержка создания нового клиента Немедленный Быстро Быстро Средняя Медленный
Преимущества моделирования данных нет Колокация сущностей Совместное размещение сущностей Несколько контейнеров для моделирования сущностей клиента Несколько контейнеров и баз данных для моделирования клиентов
Ключ шифрования Одинаково для всех клиентов Одинаково для всех клиентов Одинаково для всех клиентов Одинаково для всех клиентов Управляемый клиентом ключ для каждого клиента
Требования к пропускной способности >0 единиц ресурсов на арендатора >100 RU на арендатора >100 единиц запросов на каждый клиент (только с автомасштабированием, в противном случае >400 единиц запросов на каждый клиент) >400 RU на арендатора >400 RUs на арендатора
Примеры использования Приложения B2C Стандартное предложение для приложений B2B Предложение "Премиум" для приложений B2B Предложение "Премиум" для приложений B2B Предложение "Премиум" для приложений B2B

Модель контейнера для арендатора

Вы можете подготовить выделенные контейнеры для каждого клиента. Выделенные контейнеры хорошо работают, если можно объединить данные, которые хранятся для клиента, в один контейнер. Эта модель обеспечивает большую изоляцию производительности, чем модель partition-key-per-tenant. Она также обеспечивает повышенную изоляцию доступа к данным через Azure RBAC.

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

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

Если модель данных арендатора требует больше чем одну сущность, и если все сущности могут использовать один ключ секции, их можно разместить в одном контейнере. Но если модель данных арендатора более сложна и требует сущностей, которые не могут использовать один и тот же ключ раздела, рассмотрите модели базы данных на арендатора или учетную запись базы данных для каждого арендатора. Дополнительные сведения см. в разделе "Модель" и данные секционирования в Azure Cosmos DB.

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

Модель базы данных на клиент

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

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

Функции Azure Cosmos DB, поддерживающие мультитенантность

Секционирование

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

Рассмотрите иерархические ключи разбиения для улучшения производительности вашей мультитенантной системы. Используйте иерархические ключи секции для создания ключа секции, включающего несколько значений. Например, вы можете использовать иерархический ключ разбиения, включающий идентификатор клиента, например GUID с высокой степенью уникальности, чтобы обеспечить почти неограниченный масштаб. Или можно указать иерархический ключ секции, содержащий свойство, которое часто используется в запросах. Этот подход помогает избежать межсекционных запросов. Используйте иерархические ключи раздела, чтобы масштабироваться за пределы логического лимита в 20 ГБ для каждого значения ключа раздела и ограничить дорогостоящие запросы с распределением нагрузки.

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

Управление RUs

Модель ценообразования Azure Cosmos DB основана на количестве RU/с, которые вы подготавливаете или используете. Azure Cosmos DB предоставляет несколько опций для выделения пропускной способности. В мультитенантной среде выбор влияет на производительность и цену ресурсов Azure Cosmos DB.

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

Альтернативная модель аренды для Azure Cosmos DB включает развертывание отдельных контейнеров для каждого клиента в общей базе данных. Используйте Azure Cosmos DB для подготовки единиц запросов (RUs) для базы данных, чтобы все контейнеры разделяли единицы запросов (RUs). Если рабочие нагрузки клиента обычно не перекрываются, этот подход может помочь сократить операционные затраты. Но этот подход подвержен проблеме шумного соседа, так как контейнер одного клиента может использовать непропорциональное количество общих подготовленных единиц запросов (RUs). Чтобы устранить эту проблему, сначала определите шумных клиентов. Затем можно дополнительно задать подготовленную пропускную способность для определенного контейнера. Другие контейнеры в базе данных продолжают делиться пропускной способностью, но шумный клиент потребляет собственную выделенную пропускную способность.

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

Примечание.

При планировании конфигурации Azure Cosmos DB рассмотрите квоты и ограничения службы.

Чтобы помнить об отслеживании и управлении затратами, связанными с каждым арендатором, учтите, что каждая операция, использующая API Azure Cosmos DB, включает потребляемые RUs. Эти сведения можно использовать для объединения и сравнения фактических RUs, используемых каждым клиентом. Затем можно определить клиентов, имеющих различные характеристики производительности.

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

Ключи, управляемые клиентом

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

Дополнительные сведения см. в статье "Настройка ключей, управляемых клиентом" для учетной записи Azure Cosmos DB с помощью Azure Key Vault.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

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

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

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

Узнайте больше о мультитенантности и Azure Cosmos DB.

Ознакомьтесь с некоторыми из других сценариев архитектуры Azure Cosmos DB: