Як прийняти рішення про мультитенантність, яке важко змінити

Мультитенантність — одне з небагатьох рішень архітектури SaaS, що заслуговує слова "незворотнє." Не строго незворотнє — будь-яку архітектуру можна змінити, якщо вистачає грошей і вікна для даунтайму — але досить дороге для зміни, що більшість команд, які обрали неправильно, живуть із неправильним вибором роками.

Три варіанти добре відомі: спільна база даних із рядковою ізоляцією тенантів, схема на тенант у спільній базі даних або база даних на тенант. Більшість статей на цю тему зупиняються на їхньому переліку. Цікаве питання — який варіант підходить якому бізнесу, і відповідь залежить від властивостей ваших клієнтів, а не від властивостей вашого коду.

Як виглядають три моделі

Швидко, для спільного словника:

Спільна база даних, рядкова ізоляція. Одна база даних. Одна схема. У кожній таблиці є колонка tenant_id. У кожному запиті є умова WHERE tenant_id = ?. Ізоляція тенантів забезпечується на рівні застосунку. Це стандарт для більшості SaaS-продуктів і найпростіше у побудові.

Схема на тенант. Одна база даних. Окрема схема для кожного клієнта. Застосунок підключається зі специфічним для тенанта шляхом пошуку або запитами з кваліфікованою схемою. Ізоляція забезпечується кордоном бази даних між схемами. Резервне копіювання, відновлення та міграції відбуваються посхемно.

База даних на тенант. Окрема база даних для кожного клієнта. Застосунок підтримує пул з'єднань, вибирає правильну базу даних для запиту і маршрутизує відповідно. Ізоляція забезпечується найсильнішим кордоном, що пропонує рушій бази даних.

Є також варіанти — спільна база даних із політиками рядкової безпеки (Postgres RLS), гібридні моделі, де одні таблиці спільні, а інші — на тенант, та керовані рішення на кшталт Aurora Serverless або DynamoDB-таблиць на тенант. Фреймворк прийняття рішень стосується і їх.

Чотири фактори, що вирішують

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

Розподіл розміру тенантів. Якщо ваші тенанти приблизно однакові за розміром — малий бізнес, кожен використовує приблизно 100 МБ даних — спільна база даних добре працює і операційна простота величезна. Якщо ваші тенанти відрізняються на три порядки — одні мають 1 МБ, інші — терабайт — спільна база даних починає виробляти патологічні плани запитів для малих тенантів, бо статистика індексів домінована великими. Схема на тенант або база даних на тенант стає структурно кращою.

Ризик "галасливого сусіда". Деякі клієнтські навантаження є сплесковими у спосіб, що впливає на інших клієнтів. Репортинговий запит, що скануватиме весь архів тенанта, може заблокувати спільну базу даних, якщо вона погано побудована. У спільній моделі помилка одного клієнта деградує всіх. Вартість ізоляції реальна, але і вартість її відсутності — для клієнтів із нерівномірним навантаженням — теж.

Регуляторні та контрактні обмеження. Деякі клієнти підпишуть корпоративний договір лише якщо їхні дані знаходяться в базі даних, що належить лише їм. В деяких галузях — охорона здоров'я, фінансові послуги — це є очікуванням за замовчуванням, а не виключенням. Якщо ваша команда продажів зіткнеться з цим протягом наступних двох років, будівництво спільної бази даних зараз означає міграцію пізніше. Міграція — найдорожча частина всього рішення щодо архітектури.

Операційна зрілість. Спільна база даних — одна річ для резервного копіювання, одна для патчингу, одна для міграції. Тисяча баз даних — тисяча речей. База даних на тенант працює лише якщо ваш операційний інструментарій може поводитися з тисячею як із флотом — автоматизоване провізіонування, автоматизований патчинг, автоматизована перевірка резервних копій, автоматизований моніторинг витрат. Команди, що обирають базу даних на тенант без цього інструментарію, тонуть в операціях протягом року.

Фреймворк прийняття рішень

Чесно зіставте чотири фактори:

• Тенанти однакові за розміром, немає проблеми "галасливого сусіда", немає регуляторного тиску, мала ops-команда → спільна база даних. Це правильна відповідь для більшості ранніх SaaS.

• Тенанти відрізняються на порядок-два, деякі достатньо великі, щоб спричиняти проблему "галасливого сусіда", немає регуляторного тиску → схема на тенант. Дає ізоляцію без операційного вибуху окремих баз даних.

• Тенанти включають корпоративних клієнтів, що вимагають ізоляції даних, регуляторні обмеження в рамках, ops-команда має fleet-інструментарій → база даних на тенант. Часто правильна відповідь для sales-led enterprise SaaS, майже завжди неправильна для self-serve SaaS.

Гібридна модель — щось спільне, щось на тенант — часто є фактичним результатом після кількох років зростання. Це не модель для старту. Це результат початку в одному місці та виявлення, що інша модель підходить конкретній підмножині клієнтів.

Що будувати зараз, навіть якщо зміниться пізніше

Кілька звичок роблять майбутню міграцію дешевшою, з якою б моделі ви не почали.

Зробіть ID тенанта першокласною концепцією у доменній моделі з першого дня. Навіть в однотенантному прототипі модель даних повинна його мати. Заповнення цього постфактум — болісне; проєктування одразу — безкоштовне.

Ставтеся до скопінгу тенантів як до єдиного шматка коду, а не умови WHERE, розкиданої всюди. Шар репозиторію або query builder, що автоматично вставляє скоп, означає, що баги ізоляції тенантів стають дуже рідкісними. Написані вручну запити, що "пам'ятають" включати фільтр, означають, що баги ізоляції стають неминучими. Ми бачили реальні гроші, втрачені через це.

Будуйте абстракцію пулу з'єднань з підтримкою маршрутизації на тенант, навіть якщо ви її не використовуєте. Коли настане день міграції — проводка вже буде. Це одна з найдешевших випереджальних інвестицій, які ви можете зробити.

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

Чесне резюме

Вибір мультитенантності справді складний і справді вартий часу. Це рішення, яке інженерна команда не може прийняти сама — відповідь залежить від того, кому ви продаєте, і як це зміниться протягом наступних трьох років. Зберіть керівництво продажів і інженерне керівництво в одній кімнаті до прийняття рішення. Команди, що втрачають гроші на цьому рішенні, зазвичай втратили їх у кімнаті, де рішення було замовчуванням, а не обговоренням.