Multitenancy, или многопользовательская архитектура, — это подход, когда одна и та же платформа обслуживает сразу несколько независимых групп пользователей. Эти группы обычно называют «тенантами» (по сути, арендаторы системы). Код у всех общий, железо и инфраструктура общие, но данные, настройки, права и рабочие окружения — свои у каждого, с жёсткой изоляцией.
Как это выглядит в живой системе #
Представьте SaaS-платформу для управления проектами. Её одновременно используют:
- крупная стройкомпания,
- e-commerce стартап,
- исследовательский центр в университете.
Все сидят на одном и том же приложении, но:
- видят только свои задачи, файлы и отчёты;
- заводят собственные схемы авторизации и роли пользователей;
- могут по-разному настраивать интерфейс и часть функционала под свои процессы.
Где такое чаще всего встречается #
- SaaS-сервисы: CRM, ERP, helpdesk, маркетинговые платформы — одна кодовая база, при этом десятки или тысячи клиентов.
- Облачные провайдеры: IaaS и PaaS, где на одной инфраструктуре живут среды разных компаний.
- Корпоративные платформы: единая система, разделённая на «тенантов» по филиалам, брендам или бизнес-юнитам.
Чем это выгодно бизнесу #
- Меньше затрат — не нужно поднимать отдельные инсталляции под каждого клиента или подразделение.
- Обновления проще — патч выкатывается один раз и сразу доезжает до всех.
- Быстрое подключение новых клиентов — создать ещё одного тенанта обычно сильно дешевле, чем разворачивать отдельную систему.
- Гибкая кастомизация — каждый клиент играет со своими настройками, не мешая остальным.
Безопасность и изоляция — больное место #
Самый критичный момент в multitenancy — чтобы данные одного тенанта не пересекались с другим ни при каких условиях. Для этого обычно комбинируют несколько механизмов:
- жёсткие политики доступа в приложении и на уровне ролей;
- разделение данных в БД (схемы, отдельные таблицы, строгие фильтры по tenant_id везде, где только можно ошибиться);
- шифрование и при хранении, и в транспорте;
- регулярные аудиты безопасности и попытки «пробить» изоляцию в тестах.
Простой пример #
Облачная CRM обслуживает около 500 компаний. Каждая заходит в один и тот же адрес, но видит только свой список клиентов, сделок и отчётов. Разработчики выкатывают новый модуль аналитики — и на следующий день он есть у всех, без миграции 500 отдельных установок.
1. Одна система для всех #
Если копнуть чуть глубже, multitenancy держится на одном общем экземпляре приложения и инфраструктуры: сервера, БД, файловые хранилища, общие механизмы обновлений. Это даёт несколько приятных эффектов:
- любое новое улучшение сразу появляется у всех;
- железо используется эффективнее — нет десятков недогруженных инсталляций;
- обновления не надо раскатывать по одному клиенту, всё делается централизованно.
2. Изоляция данных и настроек #
При этом каждый клиент живёт в своём «пузыре» — видит и трогает только своё.
- Логическая изоляция — отдельные схемы в одной БД, или общий набор таблиц, но с аккуратной работой через tenant_id везде, где есть доступ к данным.
- Физическая изоляция — у некоторых тенантов могут быть свои БД или даже сервера, но приложение всё равно одно и то же.
Идея простая: даже если кто-то попытается «выстрелить себе в ногу», он не должен задеть чужие данные.
3. CRM в реальной жизни #
Возьмём ту же CRM с 500 компаниями внутри:
- Компания А живёт в системе как будто она у неё «своя» — свой список сделок, контактов, доступов.
- Компания B работает в том же интерфейсе, просто в другом логическом «кармане» данных.
- Разработчики выкатывают обновление — и через пару минут оно доступно всем, никаких отдельных установок.
4. Почему архитектура с multitenancy так популярна #
- Экономия: общая инфраструктура дешевле, чем сотня изолированных.
- Масштабирование: подключить нового клиента — не повод начинать новый IT-проект.
- Обновления: меньше рутины с релизами и меньше версий, за которыми надо следить.
- Безопасность и контроль: при нормальной реализации понятно, где чьи данные, и как на это натягивать правила, аудит, логирование.
