Модели аренды для мультитенантного решения

2025-07-04

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

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

Определение клиента

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

Бизнес для бизнеса (B2B): Если ваши клиенты — это другие организации, вероятно, вы сопоставляете своих арендаторов с этими организациями. Тем не менее, рассмотрите, имеют ли ваши клиенты подразделения, такие как команды или отделы, и имеют ли они присутствие в нескольких странах или регионах. Может потребоваться сопоставить одного клиента с несколькими клиентами, если существуют различные требования для этих подгрупп. Аналогичным образом, клиенту может потребоваться поддерживать два экземпляра службы, чтобы они могли сохранять свои среды разработки и рабочей среды, отделяемые друг от друга. Как правило, один клиент имеет несколько пользователей. Например, все сотрудники клиента являются пользователями в одном клиенте.
Бизнес для потребителей (B2C): Если ваши клиенты являются потребителями, часто бывает сложнее связать клиентов, арендаторов и пользователей. В некоторых сценариях каждый потребитель может быть отдельным клиентом. Тем не менее, рассмотрите, может ли ваше решение использоваться семьями, группами друзей, клубов, ассоциаций или другими группами, которые могут потребоваться для совместного доступа к данным и управления ими. Например, служба потоковой передачи музыки может поддерживать как отдельных пользователей, так и семьи, и она может обрабатывать каждую из этих типов учетных записей по-разному, когда она отделяет их от клиентов.

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

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

Определите, какую модель следует использовать

Выбор модели аренды не только является техническим решением. Это также коммерческое решение. Вам необходимо рассмотреть следующие вопросы:

Бизнес-цели: Рассмотрите возможность снижения затрат для каждого клиента или максимизации взаимодействия с клиентом более тесно с стратегическими целями.
Согласие: Рассмотрите, будут ли ваши клиенты принимать все формы мультитенантности. Как каждая модель мультитенантности влияет на требования соответствия или требования к соответствию вашим клиентам?
Шкала: Рассмотрите, может ли решение с одним арендатором масштабироваться до ваших будущих потребностей в росте.
Автоматизация: Рассмотрим размер вашей группы операций и сколько средств управления инфраструктурой можно автоматизировать.
Соглашения об уровне обслуживания (SLA): Подумайте, ожидают ли ваши клиенты от вас соответствия SLA или у вас есть целевые показатели уровня обслуживания (SLO).

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

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

Клиенты и развертывания

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

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

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

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

Развертывания иногда называются супертенантами или метками.

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

Дополнительные сведения см. в разделе Сопоставление запросов к арендаторам.

Изоляция арендаторов

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

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

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

Уровень изоляции влияет на многие аспекты архитектуры:

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

Архитектура решения может повлиять на доступные варианты изоляции. Например, рассмотрим трехуровневую архитектуру решения:

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

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

Общие модели аренды

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

Автоматизированные развертывания с одним клиентом

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

Ваше приложение отвечает за инициирование и координацию развертывания ресурсов каждого клиента. Как правило, решения, использующие эту модель, используют инфраструктуру в качестве кода или API Azure Resource Manager. Этот подход можно использовать, когда необходимо подготовить полностью отдельные инфраструктуры для каждого клиента. При планировании развертывания рекомендуется использовать шаблон меток развертывания .

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

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

Полностью мультитенантные развертывания

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

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

риски :

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

Развертывания с вертикальной секционированием

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

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

Ниже приведен пример, демонстрирующий общее развертывание для некоторых клиентов и однотенантное развертывание для другого:

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

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

Горизонтально секционированные развертывания

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

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

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

Тестирование модели изоляции

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

Чад Киттель | Главный инженер по программному обеспечению, шаблоны и практики Azure
Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

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

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

Рассмотрим жизненный цикл клиентов.