Розробка мультитенантної AI-платформи (SaaS) для B2B-клієнтів

Уявіть: ваш AI-сервіс обслуговує 50 B2B-клієнтів, і раптом одна компанія отримує доступ до результатів прогнозування іншої. Це не лише репутаційні ризики, а й порушення GDPR. Як цього уникнути? Мультитенантна архітектура з ізоляцією даних — єдине правильне рішення.

Ми проектуємо та реалізуємо мультитенантну AI-інфраструктуру, яка витримує навантаження від 10 до 1000+ B2B-клієнтів, зберігаючи ізоляцію даних, продуктивність та гнучкість кастомізації. За 3–5 місяців ми будуємо платформу з нуля або мігруємо існуючу — під ключ, з документацією та навчанням команди.

Типові больові точки при створенні AI SaaS

Ізоляція даних — основна головна біль. Якщо один тенант випадково отримає доступ до моделі іншого — це втрата репутації та юридичні ризики. Row-Level Security в PostgreSQL вирішує проблему на рівні БД, але не захищає від витоків через ML-артефакти. Ми використовуємо S3 prefixes + IAM-політики для кожного тенанта.

Другий блок — performance при зростанні. Shared schema дешевше, але при 100+ тенантах query latency зростає. Без правильної індексації по tenant_id запити гальмують. Ми заздалегідь проектуємо шардинг та використовуємо пули з'єднань з tenant-aware routing.

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

Порівняння моделей ізоляції

Для AI-навантажень оптимальний другий варіант: Shared DB + Separate Schema для транзакцій + окремі S3 prefixes для ML-моделей. Це дає баланс між вартістю та гнучкістю.

Як ми забезпечуємо ізоляцію даних між тенантами?

Ми використовуємо Row-Level Security в PostgreSQL. Кожен запит автоматично фільтрується по tenant_id. Приклад політики:

-- Включение RLS для изоляции данных тенантов ALTER TABLE predictions ENABLE ROW LEVEL SECURITY; -- Политика: каждый тенант видит только свои данные CREATE POLICY tenant_isolation ON predictions USING (tenant_id = current_setting('app.current_tenant_id')::UUID); 

Middleware на FastAPI встановлює tenant context для кожного запиту (див. код нижче). Це гарантує, що жоден запит не «витече» між тенантами.

# FastAPI middleware для установки tenant context @app.middleware("http") async def tenant_context_middleware(request: Request, call_next): tenant_id = await resolve_tenant(request) request.state.tenant_id = tenant_id async with db.acquire() as conn: await conn.execute( f"SET LOCAL app.current_tenant_id = '{tenant_id}'" ) request.state.db_conn = conn response = await call_next(request) return response 

Приклад з практики

На одному з проектів ми мігрували платформу з 20 тенантів на мультитенантну архітектуру. До міграції кожен тенант мав окрему базу даних, що коштувало $15 000 на місяць. Після впровадження Shared DB + Separate Schema + RLS витрати на інфраструктуру скоротилися на 60%, а p99 latency зменшилося з 800 мс до 120 мс завдяки per-tenant індексам та connection pooling.

Tenant-специфічна AI конфігурація

@dataclass class TenantAIConfig: tenant_id: str allowed_models: list[str] system_prompt_override: str = None monthly_token_limit: int = 1_000_000 concurrent_request_limit: int = 10 custom_models: list[str] = None prediction_log_retention_days: int = 90 pii_detection_enabled: bool = True audit_log_enabled: bool = True class TenantAwareInferenceService: async def predict(self, tenant_id: str, model_name: str, inputs: dict) -> dict: config = await self.get_tenant_config(tenant_id) if model_name not in config.allowed_models: raise PermissionError(f"Model '{model_name}' not allowed") if not await self.rate_limiter.check(tenant_id, config.concurrent_request_limit): raise RateLimitError("Concurrent request limit exceeded") if config.system_prompt_override and 'system' in inputs: inputs['system'] = config.system_prompt_override + "\n\n" + inputs['system'] if config.pii_detection_enabled: inputs = await self.pii_detector.redact(inputs) result = await self.inference_engine.run(model_name, inputs) await self.audit_log.record(tenant_id, model_name, inputs, result) return result 

class TenantOnboardingService: async def provision_tenant(self, signup_data: dict) -> Tenant: tenant = await self.db.create_tenant(signup_data) await self.db_manager.create_schema(tenant.id) await self.db_manager.run_migrations(tenant.id) await self.storage.create_tenant_prefix(tenant.id) await self.config_store.create_default_config(tenant.id) api_key = await self.auth.create_api_key(tenant.id, scope="all") await self.email.send_welcome(tenant, api_key) return tenant, api_key 

Процес роботи: від аудиту до запуску

1. Аналітика — аудит поточної інфраструктури, визначення вимог до ізоляції та масштабу.
2. Проектування — схема БД, API-контракти, вибір стеку (PyTorch, LangChain, PostgreSQL, S3).
3. Реалізація — написання коду, налаштування RLS, створення TenantAwareInferenceService, інтеграція LLM (GPT-4, Claude, LLaMA), fine-tuning, векторні БД (ChromaDB, pgvector).
4. Тестування — навантажувальні тести, пентест на ізоляцію даних.
5. Деплой — CI/CD, моніторинг (Grafana + Prometheus), документація.
6. Супровід — SLA, доопрацювання під нові вимоги.

Наші інженери мають 5+ років досвіду в MLOps та 20+ реалізованих AI-платформ. Ми використовуємо перевірені рішення: PostgreSQL RLS, Kubernetes, vLLM для інференсу. Гарантуємо відповідність GDPR та 152-ФЗ.

Типові помилки при реалізації мультитенантності

1. Відсутність tenant-aware кешування — кеш одного тенанта може віддавати дані іншому. Використовуйте tenant_id як частину ключа кешу.
2. Слабка ізоляція на рівні додатка — фільтрація по tenant_id в коді, а не на рівні БД — ризик випадкового витоку. Завжди комбінуйте RLS з перевірками в middleware.
3. Неправильний вибір моделі мультитенантності — для невеликої кількості тенантів підходить shared schema, але при зростанні latency злітає. Закладайте можливість переходу на separate schema без даунтайму.

Чому наша архітектура вигідніша?

Порівняйте: Shared DB + Separate Schema в 3–5 разів дешевше окремої бази на тенант при 50+ клієнтах. Економія на інфраструктурі становить до $10 000 на місяць для 50+ тенантів. А продуктивність — p99 latency < 200 мс навіть при 1000 одночасних запитів (завдяки connection pooling та per-tenant індексам). Окупність інвестицій настає вже через 6 місяців після запуску.

Терміни та вартість

Розробка займає від 3 до 5 місяців залежно від складності AI-модулів та кількості тенантів. Типова вартість проекту — від $50 000 до $150 000. Точну суму оцінюємо після аудиту — зв'яжіться з нами для консультації. Отримайте попередню оцінку вашого проекту вже сьогодні.