Поиск по сайту:

Что такое мультитенантность и как она влияет на приложения SaaS?


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

Мультитенантность чаще всего встречается в контексте облачных сервисов SaaS. Организации, которые подписываются на службу, становятся «арендаторами». Арендатор инкапсулирует конфигурацию на уровне организации и обычно поддерживает несколько учетных записей конечных пользователей. Когда пользователь входит в систему, он видит индивидуальное представление службы для своей организации.

Зачем использовать мультиарендность?

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

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

Общая инфраструктура также означает более высокую эффективность работы. Возможно, у вас есть арендатор, который нечасто пользуется этой службой. С платформой с одним арендатором вы все равно будете выделять выделенную установку, даже если большую часть времени она простаивает.

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

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

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

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

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

Недостатки мультиарендности

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

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

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

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

SELECT * FROM orders;

В многопользовательской среде вам необходимо настроить это:

SELECT * FROM orders WHERE tenant_id = 1;

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

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

Гибридная аренда?

Некоторые приложения переходят на «гибридную аренду». Эта концепция сочетает в себе лучшее из обеих моделей. Гибридная аренда хорошо сочетается с системами, построенными с использованием микросервисов. Некоторые службы будут однопользовательскими, в то время как другие будут использовать форму мультитенантности.

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

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

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

Доступ арендатора

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

В системе с одним арендатором у вас может быть выделенная установка «суперпользователя» для вашей службы. При мультитенантном подходе вы можете просто иметь таблицу tenants в своей базе данных.

Когда пользователь подключается к вашей службе, вам нужно знать, к какому арендатору он принадлежит. Обычный способ идентификации арендаторов — обнаружение поддоменов:

tenant1.example.com

tenant2.example.com

Некоторые сайты используют URL-адреса (example.com/tenant1) или могут позволить арендаторам использовать собственное доменное имя. Другие предоставят единую точку входа (example.com), но затем установят файлы cookie, идентифицирующие арендатора, или заголовки HTTP после входа пользователя в систему.

Вам также необходимо обрабатывать пользователей, принадлежащих нескольким арендаторам. Многие службы теперь позволяют вам входить в систему с общими учетными данными. Записи пользователей хранятся глобально — за пределами арендованной системы — и связываются с тенантами посредством отношений с базой данных. Это не всегда подходит для вашей системы: если вы предоставляете выделенные поддомены или поддерживаете домены, предоставленные арендаторами, может быть нежелательно позволять пользователю «менять организацию».

Краткое содержание

«Аренда» относится к тому, как приложение обрабатывает данные из нескольких разных пользовательских баз. Каждый арендатор получает собственную операционную среду; способ предоставления зависит от модели аренды.

Службы с одним арендатором просты, но неэффективны. Услуги с несколькими арендаторами сводят к минимуму требования к обслуживанию, но требуют более продуманного проектирования. Гибридная аренда — это новая модель, в которой используются микросервисы для объединения двух подходов.

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