Ізоляція тенантів і ліміти

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

1) Модель загроз і цілі

Загрози

Витік даних між орендарями (логічна/по кешу/через логи).
«Noisy neighbor»: деградація продуктивності через сплески в одного клієнта.
Ескалація привілеїв (помилка в політиці доступу).
Білінг-дрифт (невідповідність використання та нарахувань).
Каскадні відмовостійкі сценарії (інцидент одного призводить до даунтайму багатьох).

Цілі

Сувора ізоляція даних і секретів.
Пертенантні ліміти/квоти і справедливе планування.
Прозорий аудит, спостережуваність і білінг.
Локалізація інцидентів і швидке відновлення per tenant.

2) Рівні ізоляції (наскрізна модель)

1. Дані

'tenant _ id'в ключах і індексах, Row-Level Security (RLS).
Шифрування: ієрархія KMS → ключ орендаря (KEK) → ключі даних (DEK).
Роздільні схеми/БД при високих вимогах (Silo), загальний кластер c RLS для ефективності (Pool).
Політики ретеншну і «право на забування» per tenant, crypto-shredding ключів.

2. Обчислення

Квоти CPU/RAM/IO, пули воркерів на тенанта, «зважені» черги.
Ізоляція GC/heap (контейнери/налаштування JVM/Runtime), ліміти на parallelism.
Пер-тенантний autoscaling + backpressure.

3. Мережа

Сегментація: private endpoints/VPC, ACL по `tenant_id`.
Rate limiting і per-tenant connection caps на кордоні.
Захист від DDoS/ботів з урахуванням плану/пріоритету.

4. Операції та процеси

Поарендаторні міграції, бекапи, DR, feature-flags.
Інциденти - «мікро-бласт-радіус»: ф'юзинг по'tenant _ id'.

3) Контроль доступу та контекст орендаря

AuthN: OIDC/SAML; токени несуть'tenant _ id','org _ id','plan','scopes'.
AuthZ: RBAC/ABAC (ролі + атрибути проекту, відділу, регіону).
Контекст на кордоні: API-шлюз витягує і валідує контекст тенанта, доповнює лімітами/квотами, пише в трейси.
Принцип «подвійного замку»: перевірка в сервісі + RLS/політики БД.

4) Дані: схеми, кеш, логи

• Shared-schema (row-level): максимум ефективності, строгий RLS обов'язковий.
• Per-schema: компроміс ізоляції/операбельності.
• Per-DB/cluster (Silo): для VIP/регульованих.

Кеш: префікси ключів'tenant:{id}:...', TTL за планами, захист від cache-stampede (lock/early refresh).

Логи/метадані: повна псевдонімізація PII, фільтри по'tenant _ id', заборона «склеювання» логів різних орендарів.

5) Лімітування трафіку та операцій

Базові механіки

Token Bucket: згладжені сплески, параметризація «rate »/« burst».
Leaky Bucket: стабілізація throughput.
Fixed Window / Sliding Window: прості/точні квоти за вікном часу.
Concurrency limits: caps на одночасні запити/джоби.

Де застосовувати

На кордоні (L7/API-шлюз) - основний захист і «швидка відмова».
У серцевині (в сервісах/чергах) - для другого контуру і «fair share».

Політики

За тенантом/планом/ендпойнтом/типом операції (публічні API, важкі експорти, адмін-дії).
Priority-aware: VIP отримує більший'burst'і вагу при арбітражі.
Idempotency-keys для безпечних ретраїв.

Приклад профілів (поняття)

Starter: 50 req/s, burst 100, 2 паралельних експорту.
Business: 200 req/s, burst 400, 5 експортів.
Enterprise/VIP: 1000 req/s, burst 2000, виділені воркери.

6) Квоти і справедливе планування (fairness)

Квоти за ресурсами: сховище, об'єкти, повідомлення/хв, завдання/год, розмір черг.
Weighted Fair Queuing / Deficit Round Robin: «зважений» доступ до загальних воркерів.
Per-tenant worker pools: жорстка ізоляція для галасливих/критичних клієнтів.
Admission control: відмова/деградація до виконання, коли квоти вичерпані.
Backoff + jitter: експоненціальні затримки, щоб не синхронізувати сплески.

7) Спостережуваність і білінг per tenant

Обов'язкові теги: `tenant_id`, `plan`, `region`, `endpoint`, `status`.
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Usage-метрики: лічильники за операціями/байтами/секундами CPU → агрегатор → інвойси.
Ідемпотентність білінгу: снапшоти на кордоні, захист від подвійних списань/втрати подій.
Дашборди сегментами: VIP/регульовані/нові орендарі.

8) Інциденти, деградація і DR «по орендарях»

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

9) Відповідність вимогам (residency, приватність)

Пінning тенанта до регіону; чіткі правила крос-регіональних потоків.
Аудит доступу до ключів/даних, журналювання адмін-операцій.
Управління ретеншном і експортом даних per tenant.

10) Міні-референс: Як зібрати разом

Потік запиту

1. Edge (API-шлюз): TLS → витягти'tenant _ id'→ валідація токена → застосувати rate/quotas → проставити трейси.
2. Полісі-движок: контекст'tenant _ id/plan/features'→ рішення про маршрут і ліміти.
3. Сервіс: перевірка прав + мітки'tenant _ id'→ робота з БД під RLS → кеш з префіксом.
4. Usage-збір: лічильники операцій/байтів → агрегатор → білінг.

Дані

Схема/БД по стратегії (row-level/per-schema/per-DB).
KMS: ключі на орендаря, ротація, crypto-shredding при видаленні.

Обчислення

Черги з вагами, пули воркерів per tenant, caps по concurrency.
Autoscaling по пертенантним метрикам.

11) Псевдо-політики (для орієнтації)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) Чек-лист перед продом

• Єдине джерело істини'tenant _ id'; скрізь прокидається і логується.
• Включений RLS/ACL на рівні БД + сервісна перевірка (подвійний замок).
• Ключі шифрування per tenant, документована ротація/видалення (crypto-shredding).
• Ліміти/квоти на кордоні і всередині; протестовані сплески і «burst».
• Fair-queuing і/або виділені воркери для VIP; caps на concurrency.
• Пер-тенантні SLO і алерти; дашборди за сегментами.
• Usage-збір ідемпотентний; зведення з білінгом перевірено.
• DR/інциденти локалізуються до орендаря; ф'юзинг по'tenant _ id'відпрацьовує.
• Кеш/логи розділені по орендарях; PII маскована.
• Процедури міграцій/бекапів/експорту - поарендаторні.

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

RLS відключений/обійдений «службовим» користувачем - ризик витоку.
Єдиний глобальний лімітер → «noisy neighbor» і порушення SLO.
Загальні кеші/черги без префіксів → перетин даних.
Білінг рахує за логами, які губляться при піках.
Відсутність поарендаторного ф'юзингу - каскадні падіння.
Міграції «одним махом» без можливості стопнути проблемний'tenant _ id'.

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

Регульовані/VIP: Silo-дані (per-DB), виділені воркери, строгі квоти і residency.
Масовий SaaS: Shared-schema + RLS, сильні ліміти на кордоні, fair-queuing всередині.
Навантаження «шумне/пульсуюче»: великі'burst'+ жорсткі concurrency-caps, backpressure і пріоритети за планами.

Висновок

Ізоляція тенантів і ліміти - це про межі і справедливість. Чіткий'tenant _ id'крізь стек, RLS і шифрування на даних, лімітування і квоти на кордоні і в серцевині, справедливий планувальник, спостережуваність і локалізація інцидентів - все це разом дає безпеку, передбачувану якість і прозорий білінг для кожного орендаря, навіть при агресивному зростанні платформи.