Мультиарендная (multi-tenant) архитектура

Мультиарендная архитектура — это доминирующий паттерн инфраструктуры SaaS, при котором единственный экземпляр приложения — и, как правило, единственная база данных — обслуживает множество отдельных клиентов («арендаторов», tenants, например разные компании), при этом данные каждого арендатора логически изолированы от данных всех остальных, даже несмотря на то, что физически они используют одни и те же вычислительные ресурсы и хранилище. Это противоположность однотенантной (single-tenant) архитектуры, где каждый клиент получает полностью отдельный, выделенный экземпляр и базу данных. Мультиарендность — это то, что делает SaaS экономически жизнеспособным в масштабе: вместо развёртывания и обслуживания отдельного сервера и базы данных на каждого клиента (single-tenant), поставщик разворачивает одну кодовую базу и один набор инфраструктуры, обслуживающий тысячи или миллионы клиентов одновременно, что резко снижает операционные издержки на клиента и позволяет каждому клиенту мгновенно получать выгоду от одних и тех же исправлений багов и релизов функций. Существует три распространённые стратегии реализации, в порядке возрастания изоляции (и стоимости): (1) общая схема с колонкой `tenant_id` в каждой таблице, фильтруемая на уровне приложения через row-level security или middleware при каждом запросе — самый дешёвый и распространённый вариант для SaaS на ранней стадии; (2) общая база данных, отдельная схема на каждого арендатора — умеренная изоляция, более простое резервное копирование/восстановление по арендатору; (3) полностью отдельная база данных на каждого арендатора — максимальная изоляция и проще всего удовлетворяет строгие требования комплаенса/резидентности данных, но возвращает значительную часть операционных издержек single-tenant подхода. Самый катастрофический класс багов в мультиарендных системах — это сбой изоляции арендаторов: запрос без фильтра `WHERE tenant_id = ?`, который утекает данные Арендатора A к Арендатору B, — поэтому зрелые мультиарендные кодовые базы SaaS обеспечивают изоляцию на уровне базы данных или ORM (например, политики Row-Level Security в Postgres), а не полагаются на то, что каждый запрос приложения не забудет про фильтр. Конкретный пример: SaaS для управления проектами использует общую базу данных Postgres, где каждая таблица (`projects`, `tasks`, `comments`) включает внешний ключ `tenant_id`. Политика RLS в Postgres определена как `CREATE POLICY tenant_isolation ON tasks USING (tenant_id = current_setting('app.tenant_id')::uuid);` — то есть даже если баг на уровне приложения забывает отфильтровать по арендатору в запросе, сама база данных отказывается возвращать строки, принадлежащие другому арендатору, обеспечивая эшелонированную защиту от самой разрушительной категории багов безопасности в SaaS. Некоторые SaaS-продукты предлагают гибридный «силосный» (silo) тариф для своих крупнейших или наиболее чувствительных к комплаенсу клиентов — полностью выделенную базу данных (или даже выделенные вычислительные ресурсы), развёрнутую внутри в остальном мультиарендной платформы, давая этому конкретному клиенту более сильные гарантии изоляции и более простое соответствие требованиям резидентности данных без необходимости для поставщика отказываться от мультиарендности как своей архитектуры по умолчанию, экономически эффективной для всех остальных.