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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

Модель partition-key-per-tenant

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

Примечание.

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

Льготы

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

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

Компромиссы

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

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

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

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

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

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

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

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

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

Модель database-account-per-tenant

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

Льготы

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

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

Требуется рабочая нагрузка Ключ секции для каждого клиента (рекомендуется) Контейнер для каждого клиента (общая пропускная способность) Контейнер для каждого клиента (выделенная пропускная способность) Однотенантная база данных Учетная запись базы данных для каждого клиента (рекомендуется)
Запросы между клиентами Easy (контейнер выступает в качестве границы для запросов) Необратимая Необратимая Необратимая Необратимая
Плотность клиента Высокая (низкая стоимость для каждого клиента) Средняя Низкий Низкий Низкий
Удаление данных клиента Легко Простое (удаление контейнера при выходе клиента) Простое (удаление контейнера при выходе клиента) Простота (удаление базы данных при выходе клиента) Простота (удаление базы данных при выходе клиента)
Изоляция безопасности доступа к данным Необходимо реализовать в приложении Контейнер RBAC Контейнер RBAC База данных RBAC RBAC
Георепликация Георепликация клиента невозможна Группировать арендаторы в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований Группировать арендаторы в учетных записях базы данных на основе требований
Шумная профилактика соседей No No Да Да Да
Задержка создания нового клиента Интерпретация Быстро Быстро Средняя Медл.
Преимущества моделирования данных нет Совместное размещение сущностей Совместное размещение сущностей Несколько контейнеров для моделирования сущностей клиента Несколько контейнеров и баз данных для моделирования клиентов
Ключ шифрования Одинаково для всех клиентов Одинаково для всех клиентов Одинаково для всех клиентов Одинаково для всех клиентов Управляемый клиентом ключ для каждого клиента
Требования к пропускной способности >0 единиц запросов на клиент >100 единиц запросов на клиент >100 единиц запросов на каждый клиент (только с автомасштабированием, в противном случае >400 единиц запросов на каждый клиент) >400 единиц запросов на клиент >400 единиц запросов на клиент
Примеры использования Приложения 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 основана на количестве ЕЗ/с, которые вы подготавливаете или используете. Azure Cosmos DB предоставляет несколько вариантов подготовки пропускной способности. В мультитенантной среде выбор влияет на производительность и цену ресурсов Azure Cosmos DB.

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

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

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

Примечание.

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

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

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

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

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

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

Соавторы

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

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

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

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

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

Дополнительные сведения о мультитенантности и Azure Cosmos DB:

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