Multitenant

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

История

Концепция разделения ресурсов между несколькими клиентами возникла задолго до появления облачных вычислений. В 1960-х годах на мейнфреймах IBM применялась технология виртуальной памяти и разделения времени (time-sharing), когда несколько пользователей одновременно работали на одной машине через терминалы. Однако термин «multitenant» закрепился в лексиконе разработчиков в начале 2000-х годов, с распространением модели «программное обеспечение как услуга» (SaaS). Компания Salesforce.com, запустившая свою CRM-систему в 1999 году, считается одним из пионеров коммерческой мультитенантной архитектуры. В 2006 году Amazon Web Services (AWS) представила Elastic Compute Cloud (EC2), где мультитенантность стала основой для предоставления виртуальных серверов. С тех пор принцип стал стандартом для большинства публичных облачных платформ.

Архитектура и уровни изоляции

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

Физический уровень

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

Виртуализация

На одном физическом сервере запускаются несколько виртуальных машин (VM), каждая из которых принадлежит одному арендатору. Арендаторы изолированы на уровне гипервизора, но разделяют физические ресурсы (CPU, RAM, диск). Этот подход популярен в IaaS (например, Amazon EC2, Microsoft Azure). Недостаток — накладные расходы на гипервизор и необходимость управления образами ОС.

Контейнеризация

Каждый арендатор работает в отдельном контейнере (Docker, LXC). Контейнеры разделяют ядро ОС, но изолированы на уровне файловой системы, сети и процессов. Это легче и быстрее, чем VM, но требует совместимости ядра и меньшей изоляции (уязвимости ядра могут затронуть всех арендаторов). Широко применяется в PaaS (например, Heroku, Google App Engine).

Прикладной уровень (база данных)

Самый распространённый в SaaS подход. Один экземпляр приложения работает для всех арендаторов, а изоляция обеспечивается на уровне базы данных. Существует три основных варианта:

• Отдельные базы данных — для каждого арендатора создаётся своя БД. Простота администрирования, хорошая изоляция, но сложность масштабирования и высокая стоимость лицензий.
• Общая БД, отдельные схемы — все арендаторы используют одну БД, но каждый имеет свою схему (набор таблиц). Удобно для небольших клиентов, но требует осторожности с индексами и блокировками.
• Общая БД, общие таблицы — все данные хранятся в одних и тех же таблицах, а принадлежность арендатору определяется через колонку tenant_id. Самый экономичный вариант, но изоляция минимальна, а запросы сложны (необходимо всегда фильтровать по tenant_id). Используется в проектах с тысячами мелких арендаторов.

Прикладной уровень (код)

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

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

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

• Single-tenant — каждый клиент получает отдельный экземпляр приложения. Противоположность мультитенантности. Обеспечивает максимальную изоляцию, но дорог и сложен в обслуживании.
• Multi-tenant с изоляцией на уровне данных — приложение одно, данные разделены. Наиболее популярная модель для SaaS.
• Multi-tenant с изоляцией на уровне инфраструктуры — приложение одно, но каждый арендатор работает в своём контейнере или виртуальной машине. Компромисс между изоляцией и стоимостью.

По способу доступа различают:

• Публичная мультитенантность — арендаторы не знают друг о друге, доступ через общий портал (например, Google Workspace, Microsoft 365).
• Частная мультитенантность — все арендаторы принадлежат одной организации (например, разные отделы компании). Часто используется в корпоративных ERP-системах.
• Гибридная мультитенантность — комбинация публичной и частной, когда часть данных хранится в облаке, часть — локально.

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

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

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

Не disadvantages

• Риск «шумного соседа» — один арендатор может потреблять непропорционально много ресурсов (CPU, память, диск), замедляя работу соседних. Требуется механизм квотирования и ограничения (rate limiting).
• Сложность изоляции — ошибка в коде или уязвимость в базе данных может привести к утечке данных между арендаторами. Необходимо строгое тестирование на уровне SQL-инъекций и контроля доступа.
• Ограниченная кастомизация — арендаторы не могут менять архитектуру приложения (например, добавлять собственные таблицы или модули) без риска повлиять на других. Обычно кастомизация ограничивается настройками интерфейса и бизнес-правил.
• Сложность миграции — перенос данных одного арендатора на отдельный сервер (например, при переходе на single-tenant) технически сложен и требует остановки сервиса.
• Юридические риски — в некоторых отраслях (медицина, финансы, государственные данные) требуется физическое разделение данных, что противоречит мультитенантной модели.

Применение

Мультитенантность широко используется в следующих областях:

• Облачные SaaS-сервисы — CRM (Salesforce, HubSpot), офисные пакеты (Google Workspace, Microsoft 365), бухгалтерия (1С:Fresh), системы управления проектами (Jira, Asana).
• Платформы как услуга (PaaS) — среда выполнения приложений (Heroku, Google App Engine, AWS Elastic Beanstalk), где каждый арендатор — это отдельное приложение разработчика.
• Инфраструктура как услуга (IaaS) — виртуальные машины (Amazon EC2, Microsoft Azure VMs), где арендаторы — это владельцы отдельных VM.
• Веб-хостинг — shared hosting (общий хостинг), где на одном сервере размещаются сайты сотен клиентов.
• ERP-системы — корпоративные решения для управления ресурсами предприятия, где разные подразделения или дочерние компании выступают арендаторами.
• Медицинские информационные системы — электронные медицинские карты, где арендаторами являются разные клиники или врачебные кабинеты (при условии соблюдения HIPAA, 152-ФЗ).

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

• Salesforce.com, один из первых SaaS-сервисов, изначально использовала модель «один арендатор — одна база данных», но к 2005 году перешла на общую БД с колонкой org_id (аналог tenant_id), что позволило сократить количество баз данных с десятков тысяч до нескольких сотен.
• В 2011 году в Amazon EC2 произошёл сбой, затронувший многих арендаторов из-за ошибки в конфигурации сети. Этот инцидент продемонстрировал уязвимость мультитенантной архитектуры перед «шумным соседом» и привёл к внедрению более жёстких квот.
• В России мультитенантность активно используется в государственных информационных системах, например, в Единой государственной информационной системе в сфере здравоохранения (ЕГИСЗ), где арендаторами выступают региональные медицинские учреждения.
• Существует понятие «мультитенантность на уровне приложения» (application-level multitenancy), когда один и тот же код работает для разных арендаторов, но каждый видит только свои данные. Это требует тщательной проверки всех SQL-запросов и API-вызовов на наличие фильтрации по идентификатору арендатора.

Критика

Основные критические замечания в адрес мультитенантности связаны с безопасностью и производительностью. В 2017 году исследователи из Университета штата Северная Каролина продемонстрировали атаку, позволяющую одному арендатору на общем сервере EC2 извлечь данные соседнего арендатора через уязвимости в гипервизоре (атака «rowhammer»). В ответ AWS внедрила аппаратные средства защиты (Intel SGX). Кроме того, критики отмечают, что мультитенантность создаёт «единую точку отказа»: сбой в общем экземпляре приложения или базе данных парализует работу всех арендаторов одновременно. Некоторые компании, особенно в сфере финансов и оборонной промышленности, принципиально отказываются от мультитенантных решений, предпочитая выделенные серверы.

Источники

• Книга «Cloud Computing: Concepts, Technology & Architecture» (Thomas Erl, 2013)
• Документация Salesforce: «Multitenant Architecture Overview»
• Документация Microsoft Azure: «What is multitenancy?»
• Статья «A Survey of Multitenant Architecture for SaaS Systems» (Journal of Cloud Computing, 2016)
• Материалы конференции AWS re:Invent 2018: «Multitenancy Best Practices»