Поддержка многопользовательского режима

10

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

Я один из архитекторов для довольно значительных усилий по автоматизации, и исторически это была наша компания, использующая это. Мы хотим, чтобы другие тоже могли его использовать. Каждый раз, когда мы говорим о «создании мультитенанта», разговор вращается вокруг того, чтобы держать пользователей с одним арендатором в стороне от данных, которыми владеет другой арендатор, и чтобы убедиться, что пользователи с одним арендатором не могут (намеренно или непреднамеренно) создавать воздействия в другом среда арендатора. Что меня интересует, так это то, являются ли безопасность / изоляция данных действительно единственными серьезными проблемами здесь, или есть ли другие серьезные проблемы, о которых мы просто не думаем.

architecture multitenancy Грант Пэйлин
источник
Самое простое решение? Новый экземпляр всей системы, включая аппаратное обеспечение, пустой, с нуля, одна новая система на каждого арендатора. Если система и данные весьма ценны, это может быть довольно хорошим вариантом. Если вам не нравится новое оборудование для каждого экземпляра - используйте виртуализацию. Это может быть не самым эффективным, но, безусловно, сэкономит массу головных болей.
SF.
Возможно, с точки зрения дизайна это проще всего, но с административной точки зрения это не так. По крайней мере, наши сисадмины не очень рады этому предложению. (И да, мы используем виртуальные машины.) Способ управления большим количеством экземпляров (мониторинг, развертывание и т. Д.) На самом деле мы ищем способы сделать это более управляемым, чтобы получить некоторую физическую изоляцию здесь, но на первый взгляд, это Кажется, что подход меняет простоту разработки на простоту администрирования ...?

Ответы:

11

Помимо накопления данных, вы можете столкнуться с проблемами с

  1. Доступность - с одним арендатором они могут выполнять только DoS самостоятельно, но даже если данные распределены должным образом, арендатор все равно может исчерпать ресурсы.
  2. Ведение журнала - все сообщения журнала принимаются одним арендатором. Если вы не используете журналы для каждого арендатора, ваши сообщения могут стать менее полезными.
  3. Параллелизм - приложения с одним клиентом могут работать при умеренной нагрузке, или высокая конкуренция за несколько блокировок может эффективно сериализовать определенные операции. Если блокировки умножаются на каждого арендатора, вы можете увидеть чередование операций, которых раньше не было. Расовые условия, которые были очень маловероятны, теперь могут проявиться.
  4. Новые источники конкуренции за ресурсы - если раньше у вас могло быть n сокетов и m файловых дескрипторов, теперь умножьте это на каждого арендатора.
  5. Компромисс между компенсируемостью и обратной совместимостью - когда раньше вы могли устаревать компонент при развертывании замены, теперь у вас может быть один клиент, требующий компонента, и один клиент, требующий, чтобы старый компонент, который он заменяет, оставался на неопределенный срок.
  6. Цель вызова - в настоящее время вы являетесь объектом вызова для решения проблем, связанных с вашей компанией. С несколькими арендаторами вам, возможно, придется отвечать на запросы в суд, даже если вы не являетесь участником судебного процесса.

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

  1. Трудности доступа к машинам для отладки.
  2. Запросы на поддержку старых версий.
  3. Запросы разрешить сторонним подрядчикам настраивать.
  4. Меньше контроля над оборудованием, на котором он работает.
  5. Меньше контроля над циклом исправлений / обновлений ОС, на которой он работает.
Майк Самуэль
источник
1

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

Sriram
источник
1

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

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

Расширить ответ Шримама; индивидуальная настройка арендатора в значительной степени запрещена, все, что арендатор может захотеть изменить, должно быть настраиваемым . Например, если ваше решение не учитывает динамическое добавление полей данных хотя бы в нескольких ключевых областях, вы, вероятно, будете завалены запросами на настройку. Это один из немногих случаев , когда немного дополнительной сложности авансом на самом деле окупаются (скажем , это идет вразрез с YAGNI, или , по крайней мере, этот уровень конфигурации практически является ключевым требованием, так что вы это собираетесь нужно).

Даниэль Б
источник
Почему настройка "запрещена"? Это безусловно технически достижимо. Существует множество различных шаблонов, которые позволяют повторно использовать базовую систему для нескольких арендаторов, в то же время предоставляя индивидуальные компоненты для отдельных арендаторов. Если клиент желает заплатить вам за настройку, было бы разумно рассмотреть это. По этой причине существует множество мультитенантных продуктов, которые имеют индивидуальные настройки для каждого клиента. Это больше в духе YAGNI IMO, чтобы обеспечить расширяемость, а не сделать все настраиваемым.
RationalGeek
1
Ну, я имею в виду программное обеспечение как сервисную реализацию, в целом (из «многопользовательского»). Конечно, это технически достижимо, но это идет вразрез с основами SaaS. В финансовом смысле вы достигаете меньших затрат, разделяя реализацию и, возможно, инфраструктуру для многих арендаторов. Это позволяет вам предлагать ваш продукт по более низкой цене, тем самым цепляясь за «длинный хвост» рынка (большое количество людей готовы платить лишь небольшую сумму). Вы можете поддерживать 5 веток системы, но не 15000, и именно на это ориентирован SaaS.
Даниэль Б
На уровне предприятия я часто вижу поставщиков SaaS, которые готовы внести значительные изменения в свой код, чтобы привлечь клиента. Когда клиент платит 6 или 7 цифр за услугу, это, вероятно, разумная бизнес-модель.
RationalGeek
Да, в тех случаях, я так думаю. Большинство изменений, которые я видел, были реализованы как новые настраиваемые функции, которые по умолчанию отключены для существующих клиентов. Проблема, я думаю, заключается в том, что первые 3 или 4 клиента получают специальное лечение, потому что решение еще не принято. Решение оказывается слишком конкретным и создает культуру «ОК, мы его просто взломаем». Но да, я согласен с вашим комментарием вокруг крупных клиентов.
Даниэль Б
Это полезное различие, которое вы, ребята, делаете вокруг возможности настройки. Я думаю, что та же самая концепция могла бы относиться и к управляемости. Наша многопрофильная аренда, вероятно, нацелена на относительно меньшее число крупных клиентов, а не клиентов с длинным хвостом. Если основной целью для нескольких арендаторов является захват длинного хвоста, то это может быть даже не правильным подходом для нас. Спасибо за эти размышления.