02. Мультитенантность¶

1. Что такое тенант¶

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

2. Иерархия сущностей¶

flowchart TD
    org[Организация - Tenant] --> users[Пользователи и роли RBAC]
    org --> agents[Агенты]
    agents --> ver[Версии конфигов агента]
    agents --> channels[Привязки каналов]
    agents --> integrations[Привязки интеграций]
    agents --> kb[База знаний RAG]
    org --> keys[API-ключи]
    org --> billing[Тариф и лимиты]

Организация (Tenant) — корень изоляции.
Агенты — у одного тенанта может быть несколько агентов (напр. «отдел продаж», «поддержка»).
Версии конфигов — каждое изменение агента версионируется (см. 03).
Каналы / Интеграции / База знаний — настраиваются на уровне агента.

3. Модели изоляции данных¶

Модель	Как устроено	Плюсы	Минусы
Shared schema + RLS	Все тенанты в одной БД/таблицах, разделение по `tenant_id` через Row-Level Security	Дёшево, простое обслуживание, экономия ресурсов	Риск утечки при ошибке в политике; «шумный сосед»; сложнее удаление/экспорт данных одного тенанта
Schema-per-tenant	Общая БД, но отдельная схема на тенанта	Логическая изоляция, проще экспорт/удаление	Много схем в одной БД усложняет миграции; предел масштабирования БД
DB-per-tenant	Отдельная база данных на каждого тенанта	Максимальная изоляция, независимая нагрузка, простое удаление/экспорт, соответствие 152-ФЗ	Дороже, сложнее эксплуатация без автоматизации

4. Выбранное решение (enterprise-first)¶

Строгая изоляция по умолчанию: db-per-tenant

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

Сквозная изоляция не ограничивается основной БД: - отдельный namespace в векторной БД (Qdrant) на тенанта; - раздельные ключи шифрования данных; - изоляция топиков/очередей шины по тенанту; - отдельные префиксы/бакеты в объектном хранилище.

5. Автоматический провижининг тенанта¶

Онбординг нового тенанта запускает автоматический пайплайн (Control Plane + Terraform + миграции), который без ручного участия:

sequenceDiagram
    participant U as Новый бизнес
    participant CP as Control Plane
    participant IaC as Terraform / Provisioner
    participant DB as PostgreSQL
    participant V as Qdrant
    participant KMS as Key Management

    U->>CP: Регистрация тенанта
    CP->>IaC: Запрос на провижининг
    IaC->>DB: Создать выделенную БД + накатить миграции
    IaC->>V: Создать namespace для базы знаний
    IaC->>KMS: Сгенерировать ключи шифрования
    CP->>CP: Завести тариф, лимиты, выдать API-ключи
    CP-->>U: Тенант готов, агент можно настраивать

Это делает подключение «в пару кликов» реальным при строгой изоляции.

6. Тарифы (черновик)¶

Тариф	Изоляция	Модели	Каналы	Лимиты
Start	schema-per-tenant	общий GPU-пул (со-размещение)	web-виджет + 1 мессенджер	лимит диалогов/мес
Business	db-per-tenant	приоритет в общем пуле	все мессенджеры + email	выше лимиты, SLA
Enterprise	db-per-tenant + опц. выделенный GPU	выделенные ресурсы/модель	все каналы + телефония	кастомные лимиты, on-prem опция, DPA

Финализация тарифов зависит от выбранной модели монетизации (открытый вопрос в 00-overview.md).

7. Изоляция вычислений (не только данных)¶

Квоты и rate-limiting на уровне тенанта в API Gateway и LLM Gateway.
Приоритеты инференса: Enterprise-тенанты могут иметь выделенные GPU-пулы; остальные — общий пул с честным планированием.
Изоляция сбоев: проблемы одного тенанта (всплеск трафика, кривая интеграция) не должны влиять на других — circuit breaker и bulkhead-паттерн.