White-label ШІ платформа: мультитенантність і кастомізація

White-label AI платформа: де ламається мультитенантність

Мультитенантна White-Label AI платформа обіцяє зрозумілу економіку: одна кодова база, один контур оновлень, багато клієнтів під власними брендами. Ламається така схема не на моделях, а на межах між орендарями — і зазвичай у чотирьох передбачуваних місцях.

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

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

Друге — ручна видача доступів: ролі, ключі, ліміти та квоти заводяться людиною за чек-лістом. Час виведення нового орендаря зростає від днів до тижнів, і там же зростає ціна помилки в правах: зайва роль у підрядника клієнта не відкликається місяцями.

Третє — розповзання кастомних збірок. «Зробіть кнопку інакше» перетворюється на окрему гілку, оновлення ядра перевіряється для кожного орендаря вручну, і ізоляція орендарів закінчується разом із нею.

Четверте — спостережуваність: метрики, логи та ліміти спільні, тому інцидент в одного клієнта виглядає як деградація у всіх. Розбираємо, як ці точки відмови SaaS-схеми закриваються архітектурно.

Що дає мультитенантний контур: вимірювані метрики після запуску

Розрізнені інсталяції під кожного замовника дають передбачувану ціну: нова копія ядра, свої міграції, своя гілка підтримки.

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

Ефект дає розділення на спільне ядро та тонкі перевизначення орендаря: ліміти, права, маршрути й перемикачі живуть як конфігурація, а не як окрема гілка коду.

Контур розгортається на Kubernetes — простір імен, квоти та мережеві політики на орендаря, тому дані й ресурси не перетинаються, а оновлення ядра проходить один раз.

Навантаження на підтримку зміщується з ручних правок на супровід платформи, а метрики впровадження стають однаково обчислюваними за всіма орендарями: час виведення, частка повторно використовуваних модулів, кількість інцидентів на клієнта.

Варіанти ізоляції орендарів: спільний, сегментний, виділений

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

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

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

Етапи впровадження: від розбору даних до передачі платформи

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

1. Аудит даних. Розбираємо джерела, сутності та те, що зараз позначено власником неявно. На виході — карта даних: що можна об’єднувати, а що не можна змішувати за жодних умов.
2. Проєктування схеми орендарів. Обираємо розділення — окрема база, окрема схема або спільний контур з обов’язковим ключем орендаря. Рішення фіксуємо в схемі, а не в коді застосунку: політику можна змінювати без переписування логіки.
3. Ролі та ліміти. Розмежовуємо доступ адміністратора, оператора та кінцевого користувача, задаємо квоти на запити, обсяг зберігання й кількість орендарів. Ліміти живуть на рівні платформи — один клієнт не впливає на інших.
4. Перевірка ізоляції. Проганяємо сценарії, де орендар намагається дістати чужі дані через запити, звіти, експорт і пошук. Окремо дивимося фонові завдання, проміжні сховища й вивантаження — там витоки трапляються найчастіше.
5. Дослідна експлуатація. Підключаємо одного-двох клієнтів на реальних задачах і знімаємо метрики: час відповіді, частка відмов, поведінка платформи при зростанні кількості орендарів.
6. Передача платформи. Віддаємо конфігурації, схему орендарів, політики доступу, порядок підключення нового клієнта й випуску оновлень, навчаємо вашу команду на вашому ж контурі.

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

Пакет передачі: конфігурації, схеми, політики доступу, регламенти

Пакет передачі — не архів із файлами, а комплект, за яким платформу можна підняти й вести без нас. До нього входить усе, що визначає поведінку системи: конфігурації, схеми даних, політики доступу та регламенти.

Комплектність перевіряємо на прийманні: розгортаємо середовище за документами й звіряємо результат з еталонним.

• Робочі конфігурації — параметри контурів розробки, тестування та промислового, ліміти за орендарями, налаштування черг і пріоритетів запитів.
• Схеми маршрутизації — як запит доходить до моделі, де вмикаються модерація й логування, який резервний шлях працює у разі відмови основного.
• Схеми даних — структура зберігання, зв’язки між орендарями, правила ізоляції, строки та порядок зберігання історії.
• Політики доступу — ролі та області видимості, розділення прав адміністратора платформи й адміністратора орендаря, порядок видачі та відкликання ключів.
• Регламенти експлуатації — оновлення моделей, порядок відкату, реакція на деградацію якості відповідей, планові роботи та повідомлення.
• Документація — архітектура, точки інтеграції, інструкції для підтримки, матриця відповідальності між командами.
• Набори перевірок — тестові сценарії та критерії приймання, за якими ви самі підтверджуєте працездатність після змін.

Віддаємо все в редагованому вигляді та з версіонуванням: правки вносяться без нас і не ламають сумісність.

Кейс: як сервіс прибрав ручну видачу доступів орендарям

Що було до переходу

Сервіс вів кілька десятків клієнтських контурів на одній платформі, і кожен новий орендар заводився вручну.

Інженер підтримки створював адміністратора, прописував ролі, прив’язував домен і налаштовував оформлення за інструкцією на кілька сторінок — від чотирьох годин до двох днів на одного орендаря.

Запити на доступи надходили поштою та в месенджери, губилися в листуванні, а права видавалися із запасом: погодити зайвий доступ швидше, ніж розбиратися в матриці ролей.

Навантаження зростало разом із кількістю орендарів: до 40 звернень на тиждень, майже половина — однотипні. Зміна тарифу або підключення модуля вимагали ручної правки кожного контуру, а розбіжності в налаштуваннях між ними накопичувалися й спливали вже на стороні клієнта.

Що змінили і що показали вимірювання

Видачу доступів перевели в Кабінет орендаря: адміністратор сам створює контур, обирає модулі, домен і оформлення, ролі роздаються за шаблонами й успадковуються від тарифу. Правки застосовуються до всіх контурів однією операцією, а журнал змін фіксує, хто і коли змінював права.

Метрики до та після на дослідній експлуатації: із 40+ контурів перевели 15, строк видачі доступу скоротився з двох днів до 5–7 хвилин, частка запитів, закритих самообслуговуванням, — 92%, потік звернень у підтримку впав із 40 до 7–9 на тиждень, доступи з надлишковими правами — з 12% до 0,8%, підключення нового орендаря — 15 хвилин замість одного-двох днів.

Вимірювання знімали тижневими зрізами за журналами доступу та системою заявок: порівнювали ті самі показники на тих самих контурах за період до переходу й після двох місяців роботи.

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

Чим відрізняється мультитенантність від копій розгортання?

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

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

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

Швидкість оновлень — головна розбіжність. У єдиному контурі виправлення або нова можливість викочуються одним релізом і доїжджають до всіх клієнтів синхронно, відкат теж один.

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

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

Робоча схема для white-label платформи — єдиний контур з розмежуванням як основа, а виділене розгортання лише для клієнтів із жорсткими вимогами до ізоляції даних.

Технічні сумніви: ізоляція даних, тарифікація, оновлення

Інженерні заперечення щодо white-label платформи зводяться до трьох: чи не витечуть дані між орендарями, як рахується споживання, як кастомізація уживається зі спільними релізами. Розбираємо по порядку.

Як налаштовуються ліміти та тарифікація орендарів?

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

Чи не ламає кастомізація спільні оновлення?

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

Обговоримо задачу: зберемо схему орендарів під ваш продукт

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

З цим набором ми за один дзвінок знімемо невизначеності та повернемося зі схемою орендарів, планом етапів і оцінкою робіт — без проміжних «уточнимо пізніше».

Що варто підготувати до розмови:

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

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