Мультиарендность без жаргона: руководство для основателя

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

Я сидел напротив множества нетехнических основателей — людей с острой идеей для SaaS-продукта и без особого интереса к базам данных. Хорошая новость в том, что вам не нужно учиться программировать, чтобы принять это решение правильно. Вам нужны ясная мысленная модель и короткий список вопросов. Именно этим и является данное руководство. Никаких модных словечек, никаких диаграмм архитектуры, на которые вы больше никогда не взглянете, — только то, что ваш разработчик хотел бы, чтобы вы понимали до первой строки кода.

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

Что на самом деле значит «мультиарендный»

Представьте многоквартирный дом. У каждого жильца своя квартира — свой ключ, своя мебель, своя входная дверь. Но все они делят одну конструкцию: фундамент, трубы, крышу, лифт. Управляющий обслуживает одно здание, а не пятьдесят отдельных домов, и именно это делает аренду доступной. Мультиарендное ПО работает ровно так же. Одно приложение обслуживает множество клиентов — «арендаторов», — и каждый воспринимает его как своё личное пространство, хотя все они работают на одной общей системе под капотом.

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

Почти каждый продукт, которым вы пользуетесь ежедневно, мультиарендный. Ваша почта, ваш бухгалтерский инструмент, ваша система бронирования, CRM, в которой живёт ваш отдел продаж. Вы и тысяча других компаний делите одно и то же ПО под капотом, и никто из вас никогда не видит остальных. Эта невидимость — эта чистая разделённость — и есть всё искусство мультиарендности.

Почему это решение затрагивает весь ваш бизнес

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

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

Обратная сторона в том, что совместное использование инфраструктуры повышает ставки в вопросе разделения. В многоквартирном доме авария труб может затронуть не одну квартиру. В мультиарендном ПО ошибка в том, как вы разделяете арендаторов, не просто доставляет неудобства одному клиенту — она может раскрыть данные всех сразу. Это не повод избегать мультиарендности. Это повод построить её правильно, с тем, кто уже делал это раньше.

Три способа держать арендаторов раздельно

Когда разработчики спорят о мультиарендности, обычно они спорят о том, насколько раздельными должны быть данные каждого арендатора. Есть три распространённых подхода, и они лежат на скользящей шкале от «максимум общего, минимум затрат» до «максимум разделения, максимум затрат». Вам не нужно выбирать самому — но вам стоит понимать компромисс, который ваш разработчик делает от вашего имени.

1. Общая база, общие таблицы

Данные всех лежат в одной базе, в одних таблицах, со скрытой меткой — «идентификатором арендатора», — отмечающей, какие строки кому принадлежат. Программа отвечает за то, чтобы всегда фильтровать по этой метке, так чтобы клиент А видел только строки клиента А. Это самая дешёвая и лучше всего масштабируемая модель, ею пользуется большинство ранних SaaS-продуктов. Подвох: разделение живёт в коде, поэтому один пропущенный фильтр — и данные утекают. Это требует аккуратной, дисциплинированной работы.

2. Общая база, отдельные отсеки

Одна база, но каждый арендатор получает в ней свой огороженный раздел (разработчики называют их «схемами»). Разделение сильнее, чем в первой модели, всё ещё разумно эффективно, и проще, скажем, чисто экспортировать или удалить данные одного клиента. Компромисс — больше движущихся частей в управлении по мере роста до сотен и тысяч арендаторов.

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

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

То, что нельзя сделать неправильно: изоляция

Если есть одно место, на которое стоит потратить своё беспокойство, то это здесь. Изоляция арендаторов — это гарантия того, что клиент А никогда, ни при каких обстоятельствах, не сможет увидеть, изменить или даже почувствовать существование данных клиента Б. Звучит очевидно. Это также самый частый источник серьёзных ошибок в мультиарендных продуктах, потому что сбой тихий — всё выглядит хорошо вплоть до того дня, когда кто-то открывает отчёт и видит в нём клиентов незнакомца.

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

Есть и более тихий родственник этой проблемы: «шумный сосед». Поскольку арендаторы делят инфраструктуру, один клиент, делающий что-то тяжёлое — гигантский импорт, разогнавшийся отчёт, — может замедлить систему для всех остальных, так же как одна квартира со всеми открытыми кранами может уронить напор воды во всём доме. Хорошая мультиарендная архитектура учитывает это с помощью лимитов и справедливого распределения. Об этом стоит спросить, особенно если вы ожидаете нескольких очень крупных клиентов.

Когда одноарендность на самом деле верный выбор

Мультиарендность — выбор по умолчанию для SaaS, но это не религия. Есть честные причины дать клиенту свою отдельную копию, и хороший советчик скажет вам, когда вы дошли до такого случая, а не станет втискивать всё в общую модель.

• Клиент из регулируемой отрасли — здравоохранение, финансы, госсектор, — чьи правила соответствия по сути требуют, чтобы его данные лежали где-то доказуемо отдельно.
• Один крупный клиент, платящий достаточно, чтобы выделенная конфигурация того стоила, и желающий глубокой настройки, которую вы не хотите пропускать в опыт всех остальных.
• Данные настолько чувствительные, что цена межарендаторской утечки положила бы конец бизнесу, из-за чего максимальная изоляция стоит дополнительных расходов.
• Требование on-premise, когда ПО должно работать внутри собственных стен клиента, а не в вашем облаке.

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

Вопросы, которые стоит задать прежде, чем кто-то напишет код

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

1. 1
   Как вы будете держать данные арендаторов раздельно?

   Вы слушаете структурный ответ — система обеспечивает это, — а не «мы будем аккуратны». Это пункт, не подлежащий обсуждению.
2. 2
   Какую модель мы используем и почему?

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

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

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

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

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

Короткий, реалистичный пример

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

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

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

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

Частые вопросы