Мультитенантность (мультиарендность) – особенность архитектуры ПО, которая позволяет приложению обслуживать несколько независимых арендаторов. Пользователи не мешают друг другу, их данные хранятся независимо и безопасно, а разработчики могут быстро запускать версии продукта с разными техническими возможностями.

В первую очередь мультитенантность нужна SaaS-продуктам, но не только. Этот подход применяется везде, где компания параллельно поддерживает несколько версий одного продукта.

Например:

• Одно подразделение в компании продаёт услуги частным клиентам, другое работает с юридическими лицами. В обоих случаях сотрудники используют одну и ту же систему продаж, но набор функций им нужен разный.

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

• Компания создаёт разные версии одного продукта, которые рассчитаны на разные группы пользователей. Ядро решения остаётся одним, а возможности меняются в зависимости от того, что нужно клиентам.

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

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

Мультиарендность обеспечивает бизнес-пользователям независимость процессов

Данные из каждого бизнес-модуля поступают в выделенную среду. Процессы внутри продукта организованы таким образом, чтобы разные арендаторы не мешали друг другу:

• Микросервисная архитектура позволяет выделять ресурсы для разных процессов и распределять их между пользователями.

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

• Ключи-идентификаторы используются для распределения потоков данных между разными пользователями и внутри своей собственной ИТ-экосистемы.

Всё это позволяет мультиарендному продукту разграничивать данные и процессы как на уровне отдельных заказчиков, так и на уровне конечных пользователей.

Возможные варианты архитектуры мультитенантных приложений

1. Единый пул ресурсов, единое хранилище данных, одна инсталляция, разделение на уровне софта.

Такое приложение само понимает, куда пустить каких пользователей и какие функции им требуются. Этот сценарий обеспечивает оптимальное использование ресурсов, простое администрирование и развитие ПО.

Это мультиарендность на уровне ядра. Именно по такому пути стоит следовать, если вы создаёте мультитенантное приложение с нуля.

2. Единое хранилище данных, одна инсталляция ПО, пул ресурсов у каждого тенанта свой.

В этом случае разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу.

В этом случае ресурсы используются менее экономично, зато у каждого арендатора есть гарантированные мощности – ведь он использует собственный пул. Архитектурно такой подход проще, чем первый вариант, и если у вашей компании есть собственный ЦОД, он действительно может оказаться оптимальным.

3. У каждого арендатора есть собственная инсталляция ПО, собственный пул ресурсов, собственное хранилище.

Наименее экономичный вариант, требует больше всего ресурсов поддержки. По сути своей, каждый арендатор получает собственную копию приложения. Так что и разработчикам нужно развивать каждую версию отдельно, и поддержка у них строится независимо. Если компании нужно контролировать всю ситуацию целиком, нужно строить некое интеграционное решение.

Такой сценарий подходит для приложений, которые разрабатывались без расчёта на мультиарендное использование. Это не мультитенантность в полном смысле этого слова – скорее, способ добиться части её возможностей, когда переделывать продукт оказывается слишком дорого или нецелесообразно по другим причинам.

Что нужно, чтобы сделать продукт мультитенантным

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

Разработка мультитенантных продуктов строится по принципу Feature-driven Development (Trunk-based Development). Разработчики создают новые функции, которые можно включать и выключать для разных групп пользователей.

Именно с перехода на Trunk-based Development мы рекомендуем начинать путь к мультитенантности. Это позволит разработчикам взглянуть на продукт как на набор функций, из которых можно составлять параллельные версии.