AI SaaS-платформа: мультитенантність, білінг, MLOps

Чому AI SaaS платформа впирається в стелю зростання

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

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

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

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

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

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

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

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

Мультитенантність та ізоляція даних: вимірюваний ефект

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

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

Дані не перетинаються ні в пам'яті, ні на диску, ні в резервних копіях, тому один замовник фізично не може зачепити іншого.

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

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

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

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

Білінг та облік споживання: варіанти схем тарифікації

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

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

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

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

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

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

Етапи впровадження: від аудиту контуру до передачі

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

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

Після передачі контур залишається керованим без нашої участі.

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

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

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

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

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

Точка відліку

Мультитенантна платформа тримала всіх клієнтів в одному контурі Kubernetes: спільні черги завдань, одна база, один конвеєр збирання.

Сусідство давало ефект «шумного сусіда» — сплеск навантаження в одного замовника розтягував відповіді API в інших, а журнал збирав події всіх орендарів в одну стрічку.

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

Що змінили й що отримали

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

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

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

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

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

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

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

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

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

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

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

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

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

Щойно з'являється «дані тільки в нас» — переходимо на гібрид, а повністю виділений контур залишаємо для поодиноких випадків з особливими умовами.

Технічні сумніви щодо платформи перед стартом робіт

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

Як захищаються дані клієнтів на рівні платформи?

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

Хто підтримує моделі після запуску?

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

Обговоримо задачу й повернемося з оцінкою та планом

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

Що уточнюємо, щоб оцінка була реалістичною:

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

Це розмова по суті: щоб обговорити задачу предметно, достатньо описати продукт, орендарів і те, що вже готово.

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