Чому мультитенантність AI SaaS ламається при зростанні бази
Поки клієнтів десятки, мультитенантність тримається на дисципліні: один спільний контур, спільна база, спільний пул інференсу.
Зі зростанням бази клієнтів ця схема відмовляє одразу в кількох місцях, і кожна наступна відмова коштує дорожче за попередню — від заморожених релізів до розбору інциденту з витоком.
Ізоляція даних клієнтів найчастіше забезпечена фільтром за ідентифікатором тенанта в коді застосунку. Одна забута гілка запиту, один звіт, написаний поспіхом, — і у вибірку потрапляють чужі документи, ембедінги або історія звернень.
Мультитенантна архітектура має спиратися на примусове розділення на рівні сховища та доступу, а не на уважність розробника.
Друге вузьке місце платформи — спільний контур і шумні сусіди. Пул інференсу, черга завдань, кеш і ліміт з’єднань діляться між усіма: один клієнт запускає масову переіндексацію і підвищує час відповіді в інших.
Без квот і пріоритетів на тенанта, а також без метрик у розрізі клієнта, причина знаходиться лише перебором.
Далі розповзаються конфігурації: у частини клієнтів свої моделі та промпти, у частини — регіональні вимоги до зберігання даних.
Налаштування живуть одночасно в коді, у змінних середовища і в ручних правках бази, тому відкат релізу перестає бути передбачуваним, а час реакції на інцидент зростає разом із кількістю винятків.
Масштабувати таку платформу можна лише перезбиранням моделі ізоляції. Розбираємо, як це закривається — від схеми розділення тенантів до квот, конфігурації як даних і спостережуваності за кожним клієнтом.
Що дає платформа: ізоляція, швидкість і передбачуваність
Мультитенантність прибирає цілий клас відмов, який зазвичай спливає вже в проді: запит одного клієнта отримує доступ до чужих даних.
Ми розводимо дані, ключі шифрування та черги за клієнтами, а доступ обмежуємо політикою на рівні самого сховища — перетин стає неможливим за конструкцією, а не за акуратністю розробника. Саму перевірку ізоляції тримаємо в автотестах, які ганяються на кожній зміні прав доступу.
Під навантаженням платформа деградує керовано. У кожного клієнта свої ліміти й пріоритет у чергах, тому важкий перерахунок в одного не забирає ресурси в інших: падає швидкість обробки, але не втрачаються дані й не рвуться інтеграції.
За метриками видно, який контур упирається в стелю, і його піднімають окремо, не зачіпаючи сусідів, — замість загального падіння виходить обмежене уповільнення в одного клієнта.
Підключення нового клієнта — це конфігурація контуру, а не окреме розгортання: ізоляція, ліміти, ролі та шифрування вмикаються шаблоном. Перші робочі сценарії у клієнта з’являються того самого дня, а не через тижні узгоджень, і одразу з тим самим набором гарантій, що в інших.
Відновлення теж прив’язане до клієнта: відкат по одному не зачіпає решти, а повернення в роботу вимірюється хвилинами. Простій перестає бути загальною подією — ми обмежуємо його часткою постраждалих клієнтів і кількістю ручних операцій, які доводиться робити інженеру.
Режими розділення клієнтів: спільний контур, пули, окремі середовища
Мультитенантність AI SaaS — це не лише про те, де зберігаються дані клієнтів, а й про те, як діляться обчислювальні ресурси моделей, квоти та черги запитів.
Режим розділення задає, наскільки пікове навантаження одного клієнта зачіпає інших і які вимоги щодо ізоляції ми можемо підтвердити документально.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Спільний контур | Багато клієнтів зі схожими сценаріями, невисока чутливість даних, важлива швидкість виведення нових можливостей | Немає фізичної ізоляції: активний клієнт підвищує час відповіді в сусідів; розділення даних тримається лише на логіці застосунку |
| Пул клієнтів | Групи зі схожими вимогами: галузь, регіон, рівень чутливості | Усередині пулу ресурси спільні — потрібні окремі квоти й маршрутизація запитів за пулом |
| Виділене середовище | Великий клієнт або дані з особливими вимогами до зберігання й доступів | Більше інженерного часу на супровід і оновлення, нижча щільність використання ресурсів, довший цикл релізу |
| Гібридна схема | Основна маса клієнтів у спільному контурі, чутлива частина — окремо | Дві схеми в експлуатації: потрібен спільний шар управління доступами, версіями моделей і перенесенням даних між середовищами |
Вибір не бінарний: спочатку дивимося на чутливість даних, профіль навантаження та вимоги до оновлень, і лише потім — на режим розділення. Перемикання між варіантами — це зміна конфігурації та перенесення даних, а не переписування продукту.
Етапи впровадження: від аудиту контуру до передачі регламентів
Роботи йдуть послідовно, і кожен етап спирається на артефакти попереднього: до налаштування ізоляції ми не переходимо, поки не зафіксовано межі даних і власників сутностей.
Порядок однаковий і для нового контуру, і для платформи, яка вже обслуговує замовників — різниться лише обсяг міграції.
-
Аудит контуру. Розбираємо поточну схему, джерела даних, інтеграції та точки, де дані різних замовників можуть перетнутися. На виході — карта потоків і перелік сутностей із прив’язкою до тенанта.
-
Модель тенантів. Вибираємо рівень ізоляції: окремі схеми й ключі шифрування на замовника, спільні таблиці з правилами доступу за рядком або гібрид. Рішення фіксується в схемі даних і згодом майже не переглядається.
-
Налаштування ізоляції. Закриваємо розмежування доступу на рівні запитів, окремі сховища для чутливих даних, квоти на обчислення й ліміти одночасних завдань. Окремо гасимо шумних сусідів: важке завдання одного замовника не повинно змінювати відгук для інших.
-
Перевірка під навантаженням. Проганяємо сценарії з кількома активними замовниками: пікові запити, довгі операції, деградація. Дивимося, чи тримаються квоти і чи не протікають дані між тенантами, знімаємо телеметрію по кожному контуру окремо.
-
Приймання та передача. Віддаємо схему ізоляції, налаштування, перелік перевірок і порядок підключення нового замовника. Додаємо інструкцію для чергової зміни: як відкликати доступ, як винести дані на вимогу, куди дивитися під час інциденту.
Артефакти, які залишаються в замовника після робіт
Комплект документації — не додаток до релізу, а частина результату.
Платформа, яку не можна передати іншій команді, залишається прив’язаною до нас, тому кожне рішення ми описуємо так, щоб інженер замовника повторив його сам: розгорнув середовище, підключив нового клієнта, розібрав інцидент уночі без дзвінка підряднику.
- Схеми розгортання — топологія сервісів, точки відмови, схема мережі та маршрутизації, порядок підняття середовища з нуля і відновлення з резервної копії.
- Конфігурації середовищ — параметри розробки, передпродакшену і продакшену в єдиному вигляді, список зовнішніх залежностей і змінних, правила їх зміни через систему контролю версій.
- Політики доступу — ролі й права, принцип ізоляції даних орендарів, розмежування доступу інженерів до клієнтських даних, порядок видачі та відкликання доступів.
- Регламент підключення клієнта — покроковий чек-ліст від заявки до продакшену: створення орендаря, налаштування лімітів, підключення джерел даних, перевірка перед запуском.
- Регламент виведення клієнта — вивантаження даних у відкритих форматах, строки зберігання, порядок видалення орендаря без впливу на інших.
- Інструкції для чергової зміни — перелік типових відмов, що дивитися в першу чергу, які дії безпечні, а які потребують узгодження, і коли ескалювати.
- Журнал інженерних рішень — чому вибрано такі схеми ізоляції та зберігання, які альтернативи відхилили і за яких умов варто повернутися до питання.
Кожен документ прив’язаний до реальної процедури: його перевіряють на навчальному підключенні орендаря до передачі. Якщо за інструкцією не вдається пройти шлях без нас — доопрацьовуємо не текст, а саму процедуру.
Кейс: як прибрали перетини даних між клієнтами
Що було
Платформа працювала на спільному контурі: одна база, спільні таблиці, належність рядка клієнту — звичайна колонка з ідентифікатором.
Фільтр за нею додавав кожен обробник сам, і ізоляція трималася на дисципліні розробників: на десятках запитів це сходило з рук, на сотнях знайшлися місця, де умову забули.
У великого клієнта у вивантаженні з’явилися рядки іншої організації — розбір зайняв кілька днів, бо відтворити сценарій на тестових даних не вдавалося.
Другий збій був не про доступ, а про ресурси. Важкий звіт одного клієнта займав спільний пул, і в інших зростав час відповіді: частка запитів довше секунди в пікові години піднімалася з одиниць відсотків до третини. У підтримці скарги йшли однією чергою, без прив’язки до клієнта, і інциденти розбирали наосліп.
Що змінили
Ізоляцію розділили на два рівні. Доступ до даних перевели на примусові правила на боці СУБД PostgreSQL: політика застосовується до будь-якого запиту, незалежно від того, чи пам’ятає про неї код, — обійти її забутою умовою не можна.
Для чутливих наборів завели окрему схему на клієнта і закрили прямий доступ повз шар перевірки прав.
Обчислення розвели за пулами: у кожного клієнта квота на паралельні важкі завдання, звіти й навчання моделей ідуть окремою чергою і не витісняють оперативні запити.
У регресію додали перевірки ізоляції — на кожен новий обробник проганяється сценарій «запит у контексті одного клієнта не повертає рядки іншого» плюс загальний прогін по всіх шляхах доступу.
Випадків видимості чужих даних — нуль за весь період спостереження, а частка запитів довше секунди повернулася до одиниць відсотків за того самого пікового клієнта.
Онборд нового клієнта скоротився з тижнів до дня: схема й правила доступу піднімаються автоматично, а не правляться вручну в спільних таблицях.
Чим мультитенантна ізоляція даних відрізняється від окремих контурів?
Межа тенанта проходить не по залізу, а по тому, де закінчується один набір прав і починається інший. Код платформи спільний, дані, ключі шифрування та журнали доступу — окремі. Від рівня цієї межі залежать вартість оренди, швидкість оновлень і радіус ураження під час інциденту.
Логічна ізоляція — спільний контур, де кожен запис позначений ідентифікатором тенанта, а доступ обмежений політиками на рівні рядків, як у PostgreSQL. Оновлення ядра викочується один раз для всіх, новий клієнт заводиться за хвилини. Ціна — помилка в політиці доступу перетворюється на витік між клієнтами.
Фізична ізоляція — окрема база або контур на клієнта. Вимоги регуляторів закриваються простіше, оновлення й відкат робляться для одного тенанта, не зачіпаючи інших.
Зворотний бік — експлуатація множиться: стільки ж контурів, копій і налаштувань, між якими накопичується розходження.
На практиці мультитенантність не зводять до «або-або»: клієнтів з типовими вимогами тримають у спільному контурі, а кому потрібен виділений — виносять окремо, і ізоляція стає властивістю тарифу.
Критерії — вимоги до зберігання, обсяг спільних довідкових даних, чи потрібен тенанту свій темп оновлень.
Для супроводу різниця принципова. У спільному контурі одне виправлення закриває інцидент у всіх, але й збій видно всім одразу. У виділених контурах збій залишається всередині одного клієнта, зате оновлення доводиться проводити окремо для кожного. Тому межу тенанта закладають у модель даних на старті.
Часті технічні сумніви перед стартом робіт
Сумніви перед стартом рідко бувають про ідею — частіше про ризик зламати працююче. Відповідаємо на питання, які звучать найчастіше.
Чи можна перевести працюючу систему без зупинки сервісу?
Так. Ізоляцію вводять шарами: орендар визначається за підпискою, запит отримує обов’язковий фільтр, обмеження закріплюються у сховищі — у PostgreSQL це політики доступу до рядків.
Схеми розширюються без блокування, трафік перемикається за окремими клієнтами, тому зупинка потрібна лише для операцій, що зачіпають усіх орендарів одразу.
Як переконатися, що дані клієнта недоступні іншим?
Перевірка автоматична, а не за обіцянкою: на кожен маршрут пишеться тест, який звертається від імені одного орендаря й очікує порожню відповідь або відмову. Такі тести входять у збірку, тому нова функція не потрапить у продукт, не пройшовши перевірку ізоляції.
Що буде при зростанні кількості клієнтів?
Ресурси розподіляються за орендарями: важкі завдання йдуть у черги, частка потужності на клієнта обмежується, сховище ділиться за групами. Один великий клієнт не займе спільний пул і не уповільнить інших.
Хто відповідає за оновлення після передачі?
Ви отримуєте схему розгортання, регламент оновлень, набір тестів та інструкції для чергової зміни. Перші релізи випускаються разом із вашою командою, далі вона веде їх сама; підтримка на нашому боці фіксується окремим договором.
Обговоримо задачу: що підготувати до розмови
Щоб повернутися з оцінкою та планом робіт, а не із загальними міркуваннями, потрібен мінімум ввідних щодо платформи.
Те, що нижче, зазвичай знімає половину питань уже на першій розмові: ми одразу бачимо масштаб мультитенантності, вузькі місця поточної схеми розгортання і те, де ізоляція даних клієнтів уже працює, а де тримається на домовленостях.
Список не обов’язково закривати цілком — якщо чогось під рукою немає, опишіть словами, картину відновимо під час обговорення задачі.
- Модель орендарів. Скільки B2B-клієнтів зараз, яке зростання очікуєте, чи є замовники з окремими вимогами до ізоляції та розміщення даних.
- Поточна схема розгортання. Спільний контур або окремий екземпляр на клієнта, де живуть база, кеш, черга повідомлень і сховище артефактів.
- Межі ізоляції. Що вже розділено за орендарем — дані, ключі шифрування, ліміти споживання, журнали — а що поки спільне для всіх.
- Обмеження та вимоги. Регуляторні рамки, правила розміщення даних, угоди про рівень сервісу, пікові й добові навантаження.
- Точки інтеграції. Які зовнішні системи та моделі платформа викликає і з якою затримкою вони зобов’язані відповідати.
- Адміністрування. Як сьогодні підключають і відключають клієнта: внутрішня панель, ручні операції або скрипти.
- Цілі найближчого етапу. Що болить сильніше — вартість експлуатації, швидкість підключення нового клієнта чи стійкість під навантаженням.
Далі працюємо просто: обговорюємо задачу, фіксуємо обмеження і повертаємося з оцінкою та планом робіт — за етапами, з критеріями приймання на кожному.
