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

Почему AI SaaS платформа упирается в потолок при росте

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

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

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

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

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

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

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

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

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

Биллинг и учёт потребления: варианты схем тарификации

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

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

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

Этапы внедрения: от аудита контура до передачи

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

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

После передачи контур остаётся управляемым без нашего участия.

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

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

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

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

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

Точка отсчёта

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

Что изменили и что получили

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

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

Чем отличается мультитенантность от отдельного контура?

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

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

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

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

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

Технические сомнения по платформе перед стартом работ

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

Как защищаются данные клиентов на уровне платформы?

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

Кто поддерживает модели после запуска?

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

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

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

Что уточняем, чтобы оценка была реалистичной:

• Границы мультитенантности: общая база со схемами на арендатора, отдельные базы или раздельные контуры — и где именно проходит граница данных клиентов платформы.
• Модель тарификации: что берём за единицу — обращение, объём обработанных данных или активного пользователя; как считаем лимиты и что происходит при их превышении.
• Жизненный цикл моделей: где хранятся артефакты и данные обучения, как выкатываем новую версию и откатываемся на предыдущую без простоя.
• Что уже есть в инфраструктуре: облако или собственные серверы, очередь задач, хранилище, мониторинг и оповещения.
• Данные и доступы: персональные данные, журналирование, сроки хранения, кто внутри платформы видит данные арендатора.
• Профиль нагрузки: сколько арендаторов и обращений ожидается, какой отклик считаем приемлемым и что делаем на пике.

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