Multi-tenancy¶

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

¶История

Концепция multi-tenancy возникла задолго до появления облачных технологий. Её предшественниками можно считать мэйнфреймовые системы 1960–1970-х годов, где один компьютер одновременно обслуживал множество терминалов разных пользователей. Однако тогда изоляция была слабой, а управление — централизованным.

Современное понимание multi-tenancy сформировалось в конце 1990-х — начале 2000-х годов вместе с развитием интернет-сервисов и архитектуры «программное обеспечение как услуга» (SaaS). Первыми крупными примерами стали Salesforce.com (запущен в 1999 году) и Google Apps (ныне Google Workspace, запущен в 2006 году). Salesforce предложила модель, в которой тысячи клиентов используют один и тот же код и базу данных, но видят только свои данные.

В 2010-е годы multi-tenancy стала стандартом для большинства облачных платформ: Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform. В 2020-е годы акцент сместился на обеспечение безопасности и соответствия регуляторным требованиям (например, GDPR, 152-ФЗ «О персональных данных» в РФ), что привело к развитию гибридных и выделенных моделей.

¶Классификация моделей multi-tenancy

Multi-tenancy может быть реализована на разных уровнях архитектуры — от базы данных до приложения. Выделяют три основные модели:

¶1. Общая база данных, общая схема (shared database, shared schema)

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

¶2. Общая база данных, отдельные схемы (shared database, separate schemas)

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

¶3. Отдельные базы данных (separate databases)

Каждому арендатору выделяется отдельная база данных (или экземпляр СУБД). Это даёт максимальную изоляцию, упрощает резервное копирование и восстановление, но требует значительных затрат на инфраструктуру. Часто используется для крупных клиентов с особыми требованиями к безопасности.

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

¶Архитектурные особенности

¶Изоляция данных

Главная задача multi-tenancy — гарантировать, что арендатор не сможет получить доступ к данным другого арендатора. Изоляция достигается на уровне кода (проверка tenant_id в каждом запросе), на уровне базы данных (схемы или отдельные БД) и на уровне сети (виртуальные частные облака, VPC).

¶Настройка (customization)

Каждый арендатор может иметь индивидуальные настройки: интерфейс, бизнес-логику, рабочие процессы, отчёты. Эти настройки хранятся в метаданных, которые загружаются при входе арендатора в систему. Например, в Salesforce арендаторы могут создавать свои объекты и поля, не затрагивая код других.

¶Масштабирование

Multi-tenancy упрощает горизонтальное масштабирование: при росте числа арендаторов можно добавлять новые серверы или базы данных. Однако требуется балансировка нагрузки, чтобы один «шумный» арендатор не замедлял работу остальных (проблема «соседа по облаку»).

¶Безопасность

Помимо изоляции данных, multi-tenancy требует защиты от атак на уровне приложения (SQL-инъекции, XSS) и управления доступом (RBAC, OAuth). В России дополнительно необходимо соблюдать требования Федерального закона № 152-ФЗ, который предписывает хранение персональных данных граждан РФ на серверах, расположенных на территории РФ.

¶Применение

Multi-tenancy широко используется в различных сферах:

• Облачные сервисы SaaS: CRM (Salesforce, HubSpot), офисные пакеты (Google Workspace, Microsoft 365), бухгалтерские системы (1С:Предприятие через облако).
• Платформы как услуга (PaaS): Heroku, Google App Engine — разработчики создают приложения, которые работают в мультиарендной среде.
• Инфраструктура как услуга (IaaS): AWS, Azure, Яндекс.Облако — виртуальные машины разных клиентов работают на одном физическом сервере.
• Веб-хостинг: один сервер обслуживает сотни сайтов (cPanel, ISPmanager).
• Образовательные платформы: Moodle, Blackboard — каждый учебный курс или школа является арендатором.
• Государственные информационные системы: например, портал «Госуслуги» использует мультиарендную архитектуру для обслуживания разных ведомств и регионов.

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

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

• Экономия ресурсов: поставщик услуг использует общую инфраструктуру, снижая затраты на оборудование, электроэнергию и администрирование.
• Простота обновлений: обновление одного экземпляра приложения автоматически доступно всем арендаторам.
• Быстрое развёртывание: новый арендатор может быть создан за минуты без установки дополнительного ПО.
• Централизованное управление: единая точка мониторинга, резервного копирования и обеспечения безопасности.

¶Недостатки

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

¶Реализация в российских продуктах

В России multi-tenancy активно используется в облачных решениях. Например, платформа 1С:Предприятие через Интернет (1С:Fresh) позволяет организациям работать с типовыми конфигурациями 1С в облаке, где каждый клиент является арендатором. Сервис Яндекс.Облако предоставляет мультиарендную инфраструктуру, соответствующую требованиям 152-ФЗ. Также мультиарендность применяется в системах электронного документооборота (например, «Диадок»), где один экземпляр сервера обслуживает тысячи юридических лиц.

¶Критика и ограничения

Основная критика multi-tenancy связана с безопасностью. В 2019 году исследователи обнаружили уязвимости в реализации multi-tenancy в AWS и Azure, позволявшие потенциально получить доступ к данным соседних арендаторов. Кроме того, регуляторные требования в некоторых странах (например, в России и Китае) могут запрещать хранение данных разных клиентов на одном сервере без криптографической изоляции.

В ответ на это поставщики разрабатывают гибридные модели: например, «выделенный арендатор» (dedicated tenant) — физически отдельный сервер для одного клиента, но с использованием общей платформы управления. Также активно внедряются технологии шифрования на уровне базы данных и аппаратной изоляции (Intel SGX, AMD SEV).

¶Источники

• Cloud Computing: Concepts, Technology & Architecture / Thomas Erl, Zaigham Mahmood, Ricardo Puttini. — Prentice Hall, 2013.
• Multi-Tenant SaaS Patterns / Microsoft Patterns & Practices, 2012.
• Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ (ред. от 14.07.2022).
• Документация Salesforce: «Multi-Tenant Architecture» (salesforce.com).
• Документация Яндекс.Облака: «Архитектура и изоляция» (yandex.cloud).