Мульти-тенантне ядро

Мульти-тенантне ядро - це базовий шар платформи/продукту, який обслуговує безліч незалежних клієнтів (тенантів) на загальних ресурсах при гарантованій ізоляції, керованих лімітах і безпечної кастомізації. Добре спроектоване ядро знижує TCO, прискорює онбординг, спрощує релізи і забезпечує передбачувану якість для кожного орендаря.

1) Модель орендаря та межі ізоляції

Визначення

Тенант (Tenant/Org/Account): логічна організація з власними користувачами, даними, політиками і лімітами.
Ізоляція: здатність запобігати впливу одного орендаря на дані, продуктивність і безпеку іншого.

Рівні ізоляції

1. Дані: окремі БД/схеми/таблиці, шифрування «ключем орендаря», фільтри'tenant _ id'.
2. Обчислення: квоти CPU/RAM/IO, пул воркерів на тенанта або «зважені» черги.
3. Мережа: сегментація, приватні endpoints/VPN, списки дозволів по орендарях.
4. Операції: міграції, бекапи, DR та інциденти з кордонами впливу «на одного орендаря».

Патерни багатотенантності

Silo (жорстка ізоляція): окремі кластери/БД на тенанта. Максимальна безпека, висока ціна.
Pool (загальні ресурси): загальна інфраструктура з логічною ізоляцією; краща ефективність, вище ризик «noisy neighbor».
Bridge/Hybrid: гібрид - загальна площина управління + вибірково «silo» для VIP/регульованих клієнтів.

2) Ідентифікація та маршрутизація орендарських запитів

Дозвіл орендаря (Tenant Resolution)

За доменом: `https://{tenant}.example. com`

По дорозі: `/t/{tenant}/…`

За заголовком: 'X-Tenant-Id','X-Org'( перевірка підпису)

За токеном: клейми'tenant _ id','org _ id','plan','scopes '

Маршрутизація

L7-шлюз (API-шлюз/Ingress) витягує'tenant _ id', збагачує контекст ('plan', ліміти, регіон), записує в трейси/логи.
Функціональні сервіси приймають контекст «тільки для читання»; рішення по маршруту і лімітам приймає гейтвей/полісі-рушій.

3) Дані та схеми: стратегії

Варіанти зберігання

Shared-schema, row-level: один набір таблиць, поле'tenant _ id', строгі RLS (Row-Level Security).
Shared-DB, per-schema: одна СУБД, окрема схема на тенанта; баланс між керованістю та ізоляцією.
Per-DB/cluster: окрема БД/кластер на тенанта; дорожче, простіше для суверенних вимог.

Ключові практики

Скрізь явно передавати'tenant _ id'і включати його в складові ключі/індекси.
RLS/політики доступу на рівні СУБД + сервісна валідація «подвійним замком».
Шифрування: ієрархія ключів (root KMS → key-envelope на тенанта → DEK на об'єкт).
Архів/ретеншн і «право на забуття» управляються політиками на рівні орендаря.

4) Налаштування, фічі та версії

Конфігурації по тенанту

Таблиця/сховище'tenant _ config'( план, квоти, фіча-прапори, локалізація, SLA).
Пріоритети конфігурації: дефолт → план → тенант → оточення → користувач.
Кешування конфігів з коротким TTL і інвалідацією по події.

Фіча-прапори та сумісність

Включення функцій точково (per-tenant/per-cohort), канарні розкатки.
Версіонування API: стабільний контракт + адаптери на кордоні (back/forward-compatible формати).

5) Ліміти, квоти та білінг

Політики споживання

Rate limiting: 'requests/sec'per tenant/route, «токен-бакет» з пріоритетами планів.
Quotas: об'єм сховища, кількість об'єктів, повідомлень/хв, jobs/год.
Fairness: «зважений розклад» черг + ізоляція воркерів для VIP.

Білінг

Лічильники по'tenant _ id'( usage-метрики) → агрегатори → інвойс.
Снапшоти usage на кордоні (ідемпотентність і захист від втрати подій).
Моделі: фіксований план + перепис consumption, пост-пей/пре-пей, знижки «tiered».

6) Безпека та доступ

Автентифікація/авторизація

OIDC/SAML з клеймами'tenant _ id','roles','scopes'.
RBAC/ABAC: ролі на рівні орендаря (Owner/Admin/Reader), атрибути проекту/відділу.
Делегований доступ (service-to-service) з mTLS і обмеженими токенами.

Межі довіри

Політики прийняття запитів: перевірка підпису заголовків, nonce/timestamp, прив'язка до джерела.
Секрети та ключі: ротація per-tenant, окремі KMS-контексти, аудит ключових операцій.
Multi-region & data residency: пінning тенанта до регіону, контрольовані крос-регіональні потоки.

7) Спостережуваність «по орендарях»

Трасування та метрики

Обов'язкові теги: `tenant_id`, `plan`, `region`, `endpoint`, `status`.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Дашборди та алерти за сегментами (VIP/регульовані/нові).

Логи і аудит

Журнали дій (хто/що/коли/де) з незмінним сховищем і ретеншном по політиці орендаря.
Передагрегація подій для дешевого зберігання, відновлення деталізації «по кліку».

8) Продуктивність і «noisy neighbor»

Анти-шумові заходи

Ліміти на рівень черг/воркерів, CPU-shares та IO-пропорції per tenant.
Розділення кешів: префікси ключів'tenant:{id}:...', TTL за планами, захист від «cache stampede».
Індекси та плани запитів з урахуванням селективності по'tenant _ id'.

Холодні старти і «теплі» пули

Перед-прогрів для VIP/пікових вікон.
Еластичні пули воркерів за сигналами метрик (backpressure/автоскейлінг).

9) Оновлення та міграції без простою

Стратегія

Backward-сумісні міграції (expand → migrate → contract).
Міграції «по орендарях»: батчі з контролем прогресу, «пауза/відкат» для конкретного'tenant _ id'.
Семплювання та «канарські» міграції на підмножині орендарів.

DR та інциденти

DR-план з RTO/RPO per tenant; частковий «read-only режим» без глобального даунтайму.
Ізоляція інциденту: ф'юзинг по'tenant _ id', гасіння «гарячого» орендаря не зачіпає інших.

10) API та протоколи

REST/gRPC з обов'язковим контекстом орендаря (в клеймах/заголовках).
Події (event-driven): топіки з неймінгом'tenant. {id} .event', фільтри і ACL на підписки.
Глобальні точки входу: L7-шлюз валідує контекст, застосовує ліміти, шифрує PII з політики тенанта.

11) Життєвий цикл орендаря

1. Провіжінінг: створення запису орендаря, генерація ключів/конфігів, прив'язка регіону.
2. Активація: випуск клієнта OIDC/SAML, створення ролей/політик, первинних квот.
3. Експлуатація: моніторинг, білінг, оновлення прапорів/планів.
4. Суспенд/троттлінг: заморожування зі збереженням даних/експорту.
5. Видалення/експорт: ретеншн, законсервовані бекапи, крипто-стирання ключів (crypto-shredding).

12) Міні-еталон архітектури (словесна схема)

Edge (API-шлюз): TLS/mTLS, витяг'tenant _ id', ліміти, аудит.
Control Plane: каталог орендарів, конфіги, фіча-прапори, білінг, політики.
Data Plane (сервіси): stateless-сервіси, черги, воркери з квотами; Redis/kv з префіксами по тенанту.
Storage: RLS-БД/окремі схеми/БД; KMS з ключами на орендаря; об'єктне сховище c envelope-шифруванням.
Observability: трейсинг/метрики/логи з тегом'tenant _ id', алерти per plan.
Admin: ізольовані операції (міграції/бекапи) на підмножині орендарів.

13) Контрольний список перед продом

Єдиний спосіб визначення'tenant _ id'на кордоні і в сервісах.
Політики RLS/ACL перевірені тестами і «негативними сценаріями».
Квоти/ліміти/білінг валідуються на реальних навантаженнях; є захист від «білінг-дропів».
Спостережуваність і SLO per tenant; алерти для VIP/регульованих.
Міграції сумісні, є частковий відкат і поарендаторні батчі.
DR-сценарії з RTO/RPO per tenant і регулярні навчання.
Шифрування «ключем орендаря», ротація і аудит ключів.
Документація контрактів API/подій і політики версіонування.

14) Типові помилки

Глобальні міграції «одним махом» без можливості зупинити на проблемному орендарі.
Прихована залежність від'tenant _ id'в кеші/чергах → витоку даних/перетину черг.
Змішування контекстів (admin-операції випадково без'tenant _ id').
Відсутність «подвійного замку»: тільки сервісна перевірка без RLS в БД.
Єдиний лімітер на весь кластер → «noisy neighbor» і порушення SLO.
Непрозорий білінг без ідемпотентності та аудит-трейлу.

15) Швидкий вибір стратегії

Сувора ізоляція/регулювання: Silo (окремі БД/кластери), регіон-лок.
Збалансована ефективність: Shared-DB per schema + RLS, ключи per tenant.
Високий real-time трафік: спільні черги з «зваженими» квотами та виділеними воркерами для VIP.
Багато кастомізацій: фіча-прапори + адаптери API, зберігання конфігів за пріоритетами.

Висновок

Мульти-тенантне ядро - це дисципліна інженерних кордонів: явне визначення «tenant _ id», сувора ізоляція на всіх шарах, керовані квоти і прозорий білінг, плюс спостережуваність і сумісність релізів. Слідування описаним патернам дозволяє масштабувати продукт, не жертвуючи безпекою, якістю і швидкістю змін для кожного орендаря.