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

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

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

Концепция разделения вычислительных ресурсов между несколькими пользователями возникла задолго до появления термина «мультиарендность». В 1960–1970-х годах мейнфреймы (например, IBM System/360) использовали системы разделения времени (time-sharing), где множество пользователей через терминалы одновременно работали с одной машиной. Однако тогда изоляция была слабой, и каждый пользователь мог влиять на работу других.

Современная мультиарендность оформилась в конце 1990-х — начале 2000-х годов с развитием интернета и появлением модели «программное обеспечение как услуга» (SaaS). Пионерами в этой области стали компании Salesforce.com (основана в 1999 году) и NetSuite. Они предложили архитектуру, где одна кодовая база и одна база данных обслуживали тысячи клиентов, но данные каждого клиента были строго изолированы. Этот подход позволил радикально снизить стоимость владения для клиентов и ускорить вывод обновлений — вместо установки патчей на каждом отдельном сервере достаточно было обновить один центральный экземпляр.

Архитектурные модели мультиарендности

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

Аренда на уровне базы данных (Database per Tenant)

Каждому арендатору выделяется отдельная база данных (или отдельная схема в одной СУБД). Это обеспечивает максимальную изоляцию: сбои или некорректные запросы одного арендатора не затрагивают других. Модель удобна для приложений с высокими требованиями к безопасности и для крупных клиентов, готовых платить за выделенные ресурсы. Недостаток — более высокие затраты на инфраструктуру и сложность горизонтального масштабирования при росте числа арендаторов.

Аренда на уровне таблиц (Shared Table / Shared Schema)

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

Аренда на уровне схемы (Schema per Tenant)

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

Гибридные и кастомные модели

Крупные платформы (например, Microsoft Azure, Amazon Web Services) часто комбинируют подходы: для небольших клиентов используют общие таблицы, для крупных — выделенные базы данных. Возможна также модель, когда данные арендатора хранятся в отдельном файле или объектном хранилище (blob storage), а метаданные о правах доступа — в общей базе.

Реализация и ключевые механизмы

Для корректной работы мультиарендной системы необходимы несколько базовых компонентов:

• Идентификация арендатора. Обычно выполняется на уровне HTTP-запроса: по поддомену (client1.example.com), по пути URL (example.com/client1), по заголовку (X-Tenant-ID) или по JWT-токену.
• Фильтрация данных. На уровне ORM (Object-Relational Mapping) или в хранимых процедурах автоматически добавляется условие WHERE tenant_id = ?. В СУБД могут использоваться row-level security (RLS) — политики доступа на уровне строк, поддерживаемые, например, в PostgreSQL и Microsoft SQL Server.
• Изоляция ресурсов. Помимо данных, мультиарендность может распространяться на вычислительные мощности. В контейнерных средах (Docker, Kubernetes) каждому арендатору может выделяться отдельный контейнер или набор подов с ограничениями по CPU/RAM.
• Управление метаданными. Система должна хранить конфигурацию каждого арендатора: настройки интерфейса, лимиты, тарифный план, список пользователей.

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

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

• Экономия на инфраструктуре. Один сервер может обслуживать сотни и тысячи клиентов, что снижает капитальные и операционные затраты провайдера.
• Централизованное обновление. Новая версия программного обеспечения развёртывается один раз и сразу становится доступна всем арендаторам.
• Упрощённое администрирование. Не нужно управлять отдельными инсталляциями для каждого клиента.
• Масштабируемость. При росте числа клиентов можно добавлять ресурсы горизонтально (добавлять новые серверы) без перестройки архитектуры.

Недостатки

• Риски безопасности. Ошибка в коде или конфигурации может привести к компрометации данных всех арендаторов. Требуются тщательное тестирование, аудит и многоуровневая защита.
• Сложность настройки под клиента. Если арендаторам нужны глубокие кастомизации (изменение схемы данных, собственные модули), архитектура мультиарендности может стать препятствием.
• Эффект «шумного соседа» (noisy neighbor). Активный арендатор, потребляющий много ресурсов (CPU, дисковой ввода-вывода), может замедлить работу других. Для смягчения эффекта используются квоты, ограничение скорости (rate limiting) и планировщики ресурсов.
• Сложность резервного копирования и восстановления. В модели общих таблиц невозможно выборочно восстановить данные одного арендатора без влияния на других.

Применение в различных сферах

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

Мультиарендность является стандартом де-факто для большинства SaaS-продуктов: CRM (Salesforce, HubSpot), офисные пакеты (Google Workspace, Microsoft 365), системы управления проектами (Jira, Asana), платформы электронной коммерции (Shopify). В России примером мультиарендного SaaS может служить сервис «Яндекс.360» (объединяет почту, диск, календарь и другие инструменты для бизнеса).

Облачные платформы (PaaS, IaaS)

Провайдеры облачной инфраструктуры (Amazon Web Services, Microsoft Azure, Яндекс.Облако, VK Cloud) также используют мультиарендность: виртуальные машины разных клиентов работают на одном физическом сервере, но изолированы гипервизором. Однако здесь термин чаще заменяется на «мультитенантность» (multi-tenancy) или «совместное размещение» (co-location).

Мобильные и веб-приложения

Социальные сети, мессенджеры, онлайн-игры — все они по сути мультиарендны: миллионы пользователей разделяют одну кодовую базу и базу данных, но видят только свои данные. Однако в этом контексте термин «арендатор» обычно не используется — говорят об «изоляции пользовательских данных».

Промышленность и IoT

В системах управления производством (MES) и интернете вещей мультиарендность позволяет одному экземпляру ПО обслуживать несколько заводов или несколько клиентов, каждый со своими устройствами и датчиками.

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

Основные критические замечания касаются безопасности и сложности. В 2017 году исследователи из компании Rapid7 обнаружили уязвимость в популярной CRM-системе, позволявшую одному арендатору читать данные другого из-за ошибки в реализации row-level security. Подобные инциденты подрывают доверие к мультиарендным моделям, особенно в отраслях с жёсткими требованиями к конфиденциальности (медицина, финансы, государственные системы).

Кроме того, законодательство некоторых стран (например, GDPR в Европе, Федеральный закон № 152-ФЗ «О персональных данных» в России) требует локализации данных и строгого контроля доступа. Мультиарендная архитектура может усложнить выполнение этих требований, особенно если данные клиентов из разных юрисдикций хранятся в одной базе данных.

Альтернативы

Для организаций, которым мультиарендность не подходит из-за рисков или регуляторных ограничений, существуют альтернативные подходы:

• Single-tenant (одноарендная архитектура) — каждому клиенту выделяется отдельный экземпляр приложения (отдельный сервер, контейнер или виртуальная машина). Это дороже, но даёт полную изоляцию и возможность глубокой кастомизации.
• Гибридные модели — часть клиентов работает в мультиарендном режиме, часть — на выделенных инстансах, в зависимости от тарифного плана.
• Локальные (on-premises) инсталляции — программное обеспечение устанавливается на серверах клиента. Этот подход популярен в госсекторе и крупных корпорациях.

Перспективы развития

С развитием технологий контейнеризации и оркестрации (Kubernetes) мультиарендность становится более гибкой. Появляются решения, позволяющие динамически перемещать арендаторов между узлами кластера без простоя. В области баз данных набирают популярность «облачные СУБД» (Snowflake, Amazon Redshift, Яндекс.Облако Managed Database), которые изначально проектируются как мультиарендные, с автоматическим управлением изоляцией и масштабированием.

Также развивается подход «мультиарендность на уровне функций» (function-level multi-tenancy), когда изоляция обеспечивается не на уровне базы данных, а на уровне бессерверных функций (serverless). Это позволяет ещё более эффективно утилизировать ресурсы, но предъявляет высокие требования к быстродействию и безопасности.

Источники

• Книга «Cloud Application Architecture: Building Applications and Infrastructure in the Cloud» (William T. Tsai, 2014).
• Документация Microsoft Azure: «Multi-tenant SaaS patterns» (docs.microsoft.com).
• Статья «Multi-tenancy: The Good, The Bad, and The Ugly» (Rapid7, 2017).
• Материалы конференции HighLoad++ (секция «Архитектура SaaS», 2020–2023).
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».