Многоарендная архитектура

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

История

Концепция многоарендности возникла задолго до появления облачных вычислений. В 1960-х годах, в эпоху мейнфреймов, операционные системы, такие как IBM OS/360, уже поддерживали разделение ресурсов между несколькими пользователями (time-sharing). Однако термин «многоарендная архитектура» получил распространение в середине 2000-х годов с развитием SaaS-модели, популяризированной компаниями Salesforce, Workday и Google. До этого доминировала одноарендная (single-tenant) модель, где для каждого клиента разворачивался отдельный экземпляр приложения, что требовало значительных затрат на обслуживание и обновление.

Переломным моментом стало внедрение виртуализации и контейнеризации (Docker, Kubernetes), которые упростили изоляцию арендаторов на уровне операционной системы. К 2010-м годам многоарендная архитектура стала стандартом де-факто для публичных облачных платформ (Amazon Web Services, Microsoft Azure, Google Cloud Platform) и большинства крупных SaaS-продуктов.

Основные принципы

Разделение данных (Data Isolation)

Ключевой аспект многоарендной архитектуры — способ хранения данных арендаторов. Существует три основных подхода:

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

Изоляция ресурсов (Resource Isolation)

Арендаторы могут влиять друг на друга через общие ресурсы (процессор, память, сеть). Для предотвращения «шумных соседей» (noisy neighbor) применяются:

• Ограничение квот (rate limiting) — лимиты на количество запросов в секунду.
• Виртуализация и контейнеризация — выделение гарантированных ресурсов каждому арендатору.
• Приоритезация трафика — использование алгоритмов очередей (например, Weighted Fair Queuing).

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

Многоарендная архитектура позволяет горизонтально масштабировать приложение, добавляя новые экземпляры (поды) для обработки нагрузки. Однако сложность заключается в том, что каждый экземпляр должен обслуживать всех арендаторов, а не одного. Для этого используются балансировщики нагрузки и распределенные кэши (Redis, Memcached).

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

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

• Тонкая многоарендность (Thin Multi-tenancy) — арендаторы разделяют код, но имеют отдельные базы данных или схемы. Характерна для решений на основе WordPress Multisite или Drupal.
• Толстая многоарендность (Thick Multi-tenancy) — арендаторы разделяют все уровни, включая данные, но изоляция обеспечивается на уровне приложения (например, через фильтрацию по tenant_id). Используется в Google Docs, Salesforce.

По типу арендатора

• Корпоративная (Enterprise) — арендаторы — крупные организации с собственными администраторами и настройками.
• Потребительская (Consumer) — арендаторы — отдельные пользователи (например, в почтовых сервисах).
• Гибридная — сочетание обоих типов.

Устройство и компоненты

Уровень приложения

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

• Домен или поддомен (например, tenant1.example.com).
• HTTP-заголовок (например, X-Tenant-ID).
• Параметр URL (например, ?tenant=tenant1).

После идентификации арендатора приложение загружает его конфигурацию (настройки, темы, права доступа) и выполняет запрос в контексте его данных.

Уровень данных

Для обеспечения изоляции данных используются:

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

Уровень инфраструктуры

• Оркестрация контейнеров (Kubernetes) — для автоматического масштабирования.
• Сервисная сетка (Service Mesh, например, Istio) — для управления трафиком между арендаторами.
• Мониторинг и логирование — сбор метрик производительности каждого арендатора (например, через Prometheus и Grafana).

Применение

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

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

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

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

Облачные провайдеры (AWS, Azure, Google Cloud) предоставляют многоарендные среды для разработки. Например, Google App Engine автоматически распределяет запросы от разных проектов по общим серверам.

Социальные сети и медиа

Крупные платформы (Facebook — организация признана экстремистской и запрещена в РФ, Instagram — организация признана экстремистской и запрещена в РФ, TikTok) используют многоарендность для обслуживания миллиардов пользователей, где каждый пользователь является арендатором.

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

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

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

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

Критика

Основная критика многоарендной архитектуры связана с рисками для конфиденциальности данных. В 2019 году в облачном сервисе Capital One произошла утечка данных 100 миллионов клиентов из-за ошибки в конфигурации многоарендного хранилища AWS S3. Кроме того, в 2020 году исследователи из компании Wiz обнаружили уязвимость в Azure Cosmos DB, позволявшую читать данные других арендаторов через неправильно настроенные индексы.

Также критикуется сложность внедрения многоарендности в legacy-системах. Многие компании, пытаясь перейти на SaaS-модель, сталкиваются с необходимостью полной переработки архитектуры, что требует значительных инвестиций.

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

• Термин «арендатор» (tenant) заимствован из недвижимости: в облачной архитектуре арендатор «снимает» часть вычислительных ресурсов.
• Salesforce была первой компанией, которая в 1999 году представила многоарендную CRM-систему, что вызвало скепсис у аналитиков, считавших такой подход небезопасным.
• В 2023 году Google Cloud объявила о поддержке «многоарендного режима» для своей базы данных Spanner, что позволило клиентам создавать изолированные базы данных в рамках одного экземпляра.

Источники

• «Multi-Tenant Architecture: A Survey» — IEEE Transactions on Cloud Computing, 2021.
• «Cloud Computing: Concepts, Technology & Architecture» — Thomas Erl, 2013.
• Документация AWS: «Multi-Tenant SaaS Storage Strategies».
• «The Problem of Noisy Neighbors in Multi-Tenant Environments» — ACM Computing Surveys, 2020.
• Статья «Capital One Data Breach: What Went Wrong?» — Wired, 2019.