Открыть сервис
Главная → Блог → Мультитенантность

Мультитенантность

Мультитенантность — это архитектурный принцип построения программного обеспечения, при котором один экземпляр приложения (или его компонента) обслуживает множество независимых групп пользователей, называемых «клиентами» или «арендаторами» (от англ. tenant — арендатор). Каждый арендатор работает в изолированном виртуальном окружении, воспринимая приложение как выделенную именно для него систему, при этом фактически используя общие вычислительные ресурсы (серверы, базы данных, код). Мультитенантность является одной из ключевых концепций облачных вычислений (SaaS, PaaS, IaaS), позволяя провайдерам услуг эффективно масштабировать сервисы и снижать затраты за счёт разделения инфраструктуры между множеством заказчиков.

История

Концепция мультитенантности возникла в 1990-х годах, когда стало очевидным, что традиционная модель развёртывания «одно приложение — один сервер — один клиент» (единичная аренда) плохо масштабируется и экономически неэффективна. Первые коммерческие реализации были связаны с системами управления взаимоотношениями с клиентами (CRM), где компании Salesforce и Oracle начали предлагать облачные версии своих продуктов, способные обслуживать сотни клиентов на общей платформе.

С развитием облачных технологий и распространением модели «программное обеспечение как услуга» (SaaS) в 2000-х годах мультитенантность стала стандартом де-факто. Массовое внедрение произошло благодаря:

К 2010-м годам мультитенантность стала неотъемлемой частью не только облачных, но и корпоративных приложений, баз данных (например, Oracle Multitenant) и операционных систем (контейнеризация).

Архитектурные уровни

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

Физическая мультитенантность (на уровне серверов)

Несколько арендаторов используют один и тот же физический сервер, но каждый — в своей виртуальной машине (VM) или контейнере. Изоляция достигается за счёт гипервизора или контейнерного движка (например, Docker, Kubernetes). Этот уровень наиболее прост в реализации, но менее экономичен, так как каждый экземпляр ОС или приложения потребляет ресурсы.

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

Самый распространённый вариант в SaaS. Существуют три основных подхода:

  1. Отдельная база данных для каждого арендатора — простая изоляция, высокая безопасность, но дорого при большом числе клиентов.
  2. Общая база данных с отдельными таблицами — все арендаторы используют одну БД, но данные каждого хранятся в выделенной таблице (с префиксом арендатора). Компромисс между изоляцией и затратами.
  3. Общая база данных с общими таблицами — все записи смешаны в одних и тех же таблицах, но различаются по столбцу tenant_id. Максимальная экономия ресурсов, но сниженная изоляция и повышенные требования к безопасности запросов.

Мультитенантность на уровне приложения

В этом случае один экземпляр кода приложения обрабатывает запросы от всех арендаторов. Для идентификации арендатора обычно используется запросный параметр, заголовок HTTP (например, X-Tenant-ID) или доменное имя (например, customer1.example.com). Логика приложения должна корректно разграничивать данные и права каждого арендатора — так называемая «идентификация арендатора» (tenant awareness).

Мультитенантность на уровне ядра ОС

Исторически ранние реализации (например, операционные системы с разделением времени — mainframe IBM), но в современном виде используется в контейнеризации и виртуализации (например, Kubernetes с пространствами имён).

Классификация

В зависимости от степени изоляции и гибкости выделяют три модели мультитенантности:

Модель 1: Выделенные экземпляры (single-tenant per instance)

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

Модель 2: Общий экземпляр с общей базой данных (shared everything)

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

Модель 3: Общий экземпляр с раздельной базой данных (shared application, separate DB)

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

Примеры реализации

Преимущества и недостатки

Преимущества

Недостатки

Критика и риски

Наибольшая критика мультитенантности связана с проблемами безопасности и конфиденциальности. При использовании общей базы данных или сервера возрастает риск компрометации данных одного арендатора при атаке на другого (например, SSRF-атаки или SQL-инъекции с подменой tenant_id). Для снижения этих рисков применяется шифрование данных на уровне строк, строгая валидация идентификаторов арендаторов, изоляция с помощью отдельных контейнеров или виртуальных машин.

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

Интересные факты

Источники

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы