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

Что такое мультитенантность

Мультитенантность (multitenancy) — архитектура, при которой один экземпляр приложения или инфраструктуры обслуживает много независимых клиентов, а данные каждого изолированы от остальных. Клиенты делят код, серверы и часто одну базу, но не видят друг друга.

Противоположность — single-tenant: для каждого клиента разворачивается отдельная копия системы.

Тенант — это кто

Тенант (tenant, от англ. «арендатор») — изолированная сущность-владелец данных внутри общей системы: организация, проект или рабочее пространство. Не пользователь: у одного тенанта обычно много пользователей, и один человек может входить в несколько тенантов разными аккаунтами.

Аналогия прямо в названии: многоквартирный дом. Фундамент, лифт и трубы общие, а квартиры заперты. Управляющая компания обслуживает здание целиком, а не строит каждому жильцу отдельный коттедж — за счёт этого содержание квартиры стоит дешевле дома.

Где встречается слово:

• SaaS: tenant_id — организация-клиент (Slack workspace, портал Битрикс24).
• IAM: в Microsoft Entra ID / Azure AD тенант — каталог организации со своими пользователями и политиками.
• Kubernetes: тенанта чаще всего изображают namespace с квотами и сетевыми политиками.
• Облачные провайдеры: тенант — аккаунт клиента; его сеть отделена от чужих через VPC.

Уровни изоляции

Главный проектный выбор — насколько глубоко разделены клиенты. Чем сильнее изоляция, тем дороже и тем сложнее обновлять всех разом.

В модели с общей схемой изоляция держится на дисциплине кода: один забытый WHERE tenant_id = ? — и клиент получает чужие данные. Поэтому фильтр выносят на уровень, который нельзя обойти, — глобальный scope ORM или Row-Level Security в PostgreSQL:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Так база отсекает чужие строки даже при ошибке в запросе. Дополнительно tenant_id ставят первой колонкой составного индекса — иначе выборка одного клиента читает данные всех.

Проблема шумного соседа

Общий ресурс означает общие лимиты: один клиент запустил тяжёлый отчёт — тормозят все. Это noisy neighbor, главная плата за плотность.

Меры: квоты и rate limiting на тенанта, отдельные очереди и пулы под тяжёлые задачи, вынос крупных клиентов на выделенные экземпляры, учёт потребления по tenant_id — без него неизвестно, кто именно съел ресурсы.

Мультитенантность на уровне железа

Тот же принцип работает ниже приложения — так устроено любое публичное облако:

• Виртуализация — гипервизор делит физический сервер на изолированные ВМ разных клиентов.
• Сеть — трафик тенантов разделён через VPC и VLAN.
• GPU — MIG режет A100 или H100 на несколько аппаратно изолированных инстансов с собственной памятью и вычислительными блоками. Это честная изоляция, а не тайм-шеринг: соседняя задача не отберёт вашу VRAM.

Когда изоляция должна быть абсолютной, от мультитенантности отказываются: GPU passthrough или bare metal отдают карту и сервер одному клиенту целиком. Дороже — зато соседей нет вообще.

Связанные термины

• SaaS — модель, которая без мультитенантности не окупается
• VPC — сетевая изоляция тенантов в облаке
• MIG (Multi-Instance GPU) — мультитенантность на уровне GPU
• IAM / IdP — где тенант означает каталог организации
• RBAC и ACL — разграничение прав внутри тенанта
• Типы облаков — публичное облако как мультитенантная среда