Мы часто сталкиваемся с задачей мульти-компанийного деплоя: агентство обслуживает несколько клиентов из единой инсталляции, при этом каждый клиент должен видеть только свои данные. Или холдинг с несколькими юридическими лицами — общая инфраструктура, изолированные AI-организации. Типичная ситуация: при старте с одним клиентом всё просто, но когда их становится 10, 50 или 100 — расходы на поддержку отдельных инстанций растут линейно. В этой статье — архитектурное решение, которое мы применяем уже более 5 лет в 10+ проектах. Оно позволяет централизованно управлять сотнями организаций, сохраняя latency p99 на уровне 200 мс даже при пиковых нагрузках.
Какие уровни изоляции мы используем?
Изоляция строится на нескольких уровнях. На нижнем уровне — database-level isolation: отдельные PostgreSQL схемы на организацию с Row-Level Security. Это гарантирует, что запросы из агента компании A никогда не вернут данные компании B. Добавочная задержка на RLS — 1–2 мс, что незаметно для пользователя.
Выше — namespace isolation: каждый агент работает в контексте своей организации. LLM-вызовы маркируются organization_id, логи полностью разделены. Resource isolation через отдельные очереди задач (Redis namespacing) и rate limits, настраиваемые отдельно для каждой компании. При высоких требованиях — опциональная сетевая изоляция через Docker networks.
Сравним уровни в таблице:
| Уровень изоляции | Механизм | Задержка | Сложность конфигурации |
|---|---|---|---|
| Database-level | PostgreSQL схемы + RLS | <2 мс | Низкая |
| Agent namespace | organisation_id в каждом запросе | <0.5 мс | Средняя |
| Resource (очереди, лимиты) | Redis namespaces, rate limiting | ~0 мс | Средняя |
| Network-level (опционально) | Docker сети на организацию | ~0 мс | Высокая |
Дополнительно, каждая компания может иметь свои RAG-базы знаний с изолированными embeddings (например, 1536-мерные через text-embedding-ada-002). Это позволяет строить персонализированные AI-ассистенты без пересечения контекста.
Почему multi-tenant Paperclip в 3–5 раз дешевле?
Экономия на инфраструктуре: одна инсталляция обслуживает десятки организаций. Централизованное управление через super-admin панель: создание компаний, настройка тарифов, мониторинг использования и биллинг. Organisation admin видит только свою компанию. Kubernetes позволяет динамически масштабировать ресурсы при росте числа организаций — horizontal scaling worker-ов. По нашим оценкам, multi-tenant архитектура снижает совокупную стоимость владения в 3–5 раз по сравнению с отдельными экземплярами для каждой компании.
Сравним сценарии развёртывания:
| Параметр | Отдельные инстанции | Multi-tenant Paperclip |
|---|---|---|
| Количество серверов | N | 1–2 |
| Время на добавление компании | 1–2 недели | 1 час |
| Сложность мониторинга | Высокая (N дашбордов) | Низкая (единый дашборд) |
| Возможность white-label | Требует отдельных настроек | Из коробки |
Типичные ошибки при настройке изоляции
- Пропуск RLS: забывают включить на всех таблицах, что приводит к утечкам. Проверяйте через тестовые запросы с разными
organization_id. - Смешивание очередей: используют один Redis namespace — задачи одной компании могут блокировать другую. Всегда изолируйте очереди через префиксы.
- Не настроенные rate limits: при всплеске активности одна организация потребляет все ресурсы GPU. Устанавливайте лимиты на токены в минуту и параллельные запросы.
Как мы тестируем изоляцию?
Мы проводим автоматизированные тесты на изоляцию: запускаем агентов от имени разных компаний и проверяем, что их данные не пересекаются. Используем случайные запросы и измеряем утечки — target: нулевое пересечение. Load-тесты с пиковой нагрузкой от 10 до 100 организаций подтверждают, что latency p99 не превышает 200 мс. Для особо чувствительных сценариев добавляем аудит логов на предмет prompt injection — изолированные namespace не позволяют одной компании влиять на контекст другой.
Процесс работы
- Аналитика — изучаем сценарий использования, количество компаний, требования к изоляции и compliance.
- Проектирование — разрабатываем multi-tenant схему базы данных, определяем конфигурацию namespace и resource isolation.
- Реализация — настраиваем PostgreSQL схемы, RLS, админ-панель, интеграцию с биллингом.
- Тестирование — изоляционные тесты: проверяем, что агент одной компании не видит данные другой. Load-тесты под пиковой нагрузкой.
- Деплой — развертывание на вашей инфраструктуре или в нашем облаке, обучение администраторов.
Что входит в работу
- Документация — описание архитектуры, инструкция по добавлению новых компаний.
- Admin API и панель — полный функционал управления организациями, тарифами и мониторингом.
- Изоляционные тесты — отчёт с результатами подтверждения изоляции.
- Билдинг-интеграция — подключение к вашей системе биллинга (Stripe, PayPal, счёт).
- Обучение — демонстрация админ-панели вашим сотрудникам.
Сроки: от 3 до 5 недель в зависимости от сложности. Точную стоимость рассчитываем под ваш сценарий. Свяжитесь с нами для получения консультации.
Мы гарантируем, что данные каждой компании будут полностью изолированы. Этот подход проверен на 10+ проектах с суммарным числом организаций более 50. Закажите оценку вашего проекта — мы расскажем, как внедрить мульти-компанийность с минимальными рисками.