Мультитенантная архитектура

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

История и предпосылки возникновения

Концепция мультитенантности возникла как ответ на необходимость снижения стоимости владения программным обеспечением для массового рынка. В эпоху мэйнфреймов (1960–1970-е годы) ресурсы одного компьютера делились между несколькими задачами, но это не было мультитенантностью в современном смысле — скорее, разделением вычислительных мощностей. С появлением персональных компьютеров и клиент-серверной архитектуры (1980–1990-е) преобладала модель однотенантного развертывания: каждая организация устанавливала собственный экземпляр приложения на выделенном сервере.

Перелом наступил с развитием интернета и облачных вычислений в начале 2000-х годов. Компании, предоставляющие программное обеспечение как услугу (SaaS), такие как Salesforce (основана в 1999 году), первыми массово внедрили мультитенантную архитектуру. Это позволило им централизованно обновлять приложения, обеспечивать единую точку входа для всех клиентов и значительно сократить издержки на поддержку. К концу 2000-х годов мультитенантность стала стандартом де-факто для большинства облачных сервисов, включая Google Workspace, Microsoft 365 и многие другие.

Принципы и ключевые характеристики

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

Главный принцип мультитенантной архитектуры — логическая изоляция данных каждого тенанта. Несмотря на то, что все тенанты используют одну базу данных (или один кластер баз данных), их записи физически или логически разделены. Основные подходы к изоляции:

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

Конфигурируемость

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

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

Масштабируемость

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

Безопасность и аудит

Обеспечение безопасности — критически важная задача. Помимо изоляции данных, применяются:

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

Классификация моделей мультитенантности

По уровню изоляции

1. Мультитенантность с полным разделением (Single-Tenant per Instance) — каждый тенант получает отдельный экземпляр приложения, но все экземпляры управляются централизованно. Фактически это гибридный подход.
2. Мультитенантность на уровне приложения (Application-Level Multi-Tenancy) — один экземпляр приложения, но данные изолированы через идентификатор тенанта. Самый распространенный вариант.
3. Мультитенантность на уровне базы данных (Database-Level Multi-Tenancy) — разные схемы или базы данных для каждого тенанта, но общий код приложения.

По типу развертывания

• Облачная мультитенантность (Public Cloud Multi-Tenancy) — приложение размещается у провайдера облачных услуг (AWS, Azure, Google Cloud) и обслуживает множество клиентов.
• Приватная мультитенантность (Private Cloud Multi-Tenancy) — приложение развернуто в частном облаке организации, но обслуживает несколько внутренних подразделений или дочерних компаний.
• Гибридная мультитенантность — комбинация, при которой часть тенантов работает в публичном облаке, а часть — в приватном.

Применение

Облачные сервисы (SaaS)

Мультитенантность является основой для подавляющего большинства SaaS-продуктов:

• CRM-системы (Salesforce, HubSpot) — тысячи компаний используют один экземпляр приложения, имея доступ только к своим данным.
• Офисные пакеты (Google Workspace, Microsoft 365) — каждый корпоративный клиент является тенантом.
• Платформы для совместной работы (Slack, Trello, Notion) — рабочие пространства и команды изолированы друг от друга.

Платформы как услуга (PaaS)

В PaaS-решениях (например, Heroku, Google App Engine) мультитенантность позволяет разработчикам запускать свои приложения на общей инфраструктуре, при этом каждый проект (тенант) имеет изолированное окружение.

Инфраструктура как услуга (IaaS)

Виртуализация серверов (VMware, Hyper-V) также использует принцип мультитенантности: одна физическая машина делится на несколько виртуальных, каждая из которых принадлежит разным клиентам.

Корпоративные системы

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

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

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

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

Недостатки и риски

• Сложность обеспечения изоляции — ошибки в коде могут привести к утечке данных между тенантами.
• Проблема «шумного соседа» — один тенант с высокой нагрузкой может замедлить работу системы для всех остальных.
• Ограниченная кастомизация — возможности настройки под уникальные требования каждого тенанта ограничены общей архитектурой.
• Зависимость от провайдера — при смене поставщика SaaS-услуг миграция данных может быть сложной и дорогой.

Сравнение с однотенантной архитектурой

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

• Термин «тенант» в контексте программного обеспечения впервые был использован компанией Salesforce в начале 2000-х годов для описания модели своих SaaS-сервисов.
• Некоторые критики утверждают, что мультитенантность увеличивает поверхность атаки для злоумышленников, так как успешная атака на один компонент может скомпрометировать данные всех тенантов.
• В России мультитенантность активно применяется в государственных информационных системах, например, в единой системе межведомственного электронного взаимодействия (СМЭВ), где каждый регион или ведомство может выступать в роли тенанта.

Критика

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

Источники

• Cloud Computing: Concepts, Technology & Architecture — Thomas Erl, Ricardo Puttini, Zaigham Mahmood (2013)
• Software Architecture: The Hard Parts — Neal Ford, Mark Richards (2021)
• Multi-Tenant Architecture: A Comprehensive Guide — документация Microsoft Azure
• Salesforce Multi-Tenant Architecture — технические документы Salesforce
• NIST Definition of Cloud Computing — Special Publication 800-145 (2011)