Мультитенантная архитектура в SaaS: три подхода и критерии выбора

В SaaS-продуктах одно приложение обслуживает множество клиентов. Каждого клиента называют «тенантом» (tenant), и свои данные должен видеть только он сам. То, как будут разделены данные тенантов, — архитектурное решение, которое годами влияет на стоимость продукта, его безопасность и эксплуатационную нагрузку.

Три основных подхода

1. Общая база данных, общая схема

Данные всех тенантов лежат в одних и тех же таблицах; каждая строка содержит поле, которое указывает, какому тенанту она принадлежит. Каждый запрос фильтруется по этому полю. Это самый простой в развёртывании и эксплуатации подход с самым эффективным использованием ресурсов.

Его риск в том, что единственный запрос, в котором забыли о фильтрации, может показать данные другого тенанта. Этот риск снижают, не оставляя фильтрацию на усмотрение кода приложения, а делая её обязательной на уровне базы данных; например, для этого используется защита на уровне строк в PostgreSQL.

2. Общая база данных, отдельная схема для каждого тенанта

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

3. Отдельная база данных для каждого тенанта

У каждого тенанта своя база данных. Изоляция максимальна; интенсивное использование одним тенантом не влияет на остальных, и можно выполнить такие требования, как хранение данных в определённом регионе. Цена этого — более высокая стоимость инфраструктуры и эксплуатационная нагрузка, связанная с управлением большим числом баз данных.

Сравнение

Критерий	Общая схема	Отдельная схема	Отдельная база данных
Изоляция данных	Логическая	Более сильная	Самая сильная
Стоимость на одного тенанта	Самая низкая	Средняя	Самая высокая
Изменение схемы	За один раз	Для каждой схемы	Для каждой базы данных
Резервная копия и восстановление для отдельного тенанта	Сложно	Просто	Проще всего
Большое число небольших тенантов	Очень подходит	Ограниченно	Не подходит
Небольшое число крупных корпоративных тенантов	Может быть достаточно	Подходит	Очень подходит

Что определяет выбор?

• Профиль клиентов: Вы будете обслуживать тысячи небольших компаний или небольшое число крупных организаций?
• Требования договоров и законодательства: Ставят ли клиенты условием физически раздельное хранение своих данных?
• Уровень кастомизации: Тенанты будут менять только настройки или захотят собственные поля и рабочие процессы?
• Возможности команды: Есть ли у вас эксплуатационные ресурсы, чтобы отслеживать и обновлять большое число баз данных?

Гибридная модель

Подходы можно использовать и вместе. Распространённый вариант — держать клиентов на стандартных тарифах в общей схеме, а корпоративным клиентам предлагать отдельную базу данных. Чтобы это было возможно, информация о тенанте должна с самого начала передаваться через все слои приложения.

О чём нужно подумать помимо базы данных

• Идентификация и права доступа: Должно быть точно известно, какому тенанту принадлежит каждый сеанс; если пользователи могут состоять в нескольких тенантах, переключение между ними должно быть выстроено безопасно.
• Разделение ресурсов: Интенсивное использование одним тенантом не должно замедлять остальных. Для этого применяются лимиты запросов и квоты на фоновые задачи для каждого тенанта.
• Файлы и кеш: Изоляция должна обеспечиваться не только в базе данных, но и в файловом хранилище, кеше и поисковом индексе.
• Мониторинг: Журналы ошибок и производительности должны содержать информацию о тенанте; иначе вопрос «какой клиент пострадал?» останется без ответа.

Для большинства SaaS-продуктов общая схема — правильное начало; важно выстроить её так, чтобы в будущем она не мешала переходу на отдельную базу данных.

Чтобы вместе спланировать архитектуру вашего продукта, ознакомьтесь с нашей услугой разработки SaaS-продуктов.