Case 12. Multi-tenant Data Platform¶

Практикум · Связанная теория · Редакционный стандарт

Тип материала — практический архитектурный кейс. HYPOTHETICAL — все численные параметры, сценарий и схемы. INFERENCE — выбор и критерии. UNKNOWN — фактическая производительность и параметры, которые предстоит согласовать.

1. Business problem¶

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

2. Functional requirements¶

Управлять tenant identity, quotas, routing, access, billing tags, export, retention и deletion. Предоставлять observable tenant-level SLO.

3. Non-functional requirements¶

Измерять headroom по пулу и по tenant. Выделять security boundary и noisy-neighbor budgets. Restore и replay одного клиента имеют ограниченный scope.

4. Assumptions и вопросы заказчику¶

Assumption — 60 tenants, крупнейший даёт 35% среднего ingress. Спросить isolation tier, legal residency, key ownership, burst quota, per-tenant restore, deletion и общие metadata.

5. Оценка нагрузки и объёма данных¶

HYPOTHETICAL. Средняя скорость 12000 events/s, пик 24000 events/s, payload mean/p95/p99 1100/2400/5000 B. Перцентили заданы отдельно для тестового профиля, среднее используется для объёма. Суточный профиль упрощён до постоянного среднего, накладные расходы протокола, индексов и WAL исключены.

Метрика	Формула и подстановка	Результат
Объём событий	12000 × 86 400	1036800000 событий/сутки
Сырые данные	1036800000 × 1100 B	1140.48 GB/сутки
Retention без сжатия	1140.48 GB × 14 суток	15966.72 GB
Broker copies при RF=3	15966.72 GB × 3	47900.16 GB, из них 31933.44 GB дополнительные копии
Producer bandwidth, среднее	12000 × 1100 × 8 / 10⁶	105.6 Mbit/s
Producer bandwidth, пик	24000 × 1100 × 8 / 10⁶	211.2 Mbit/s
Partitions при 30% headroom	max(ceil(24000 × 1,3 / 1 500), ceil(24000 × 1100 × 1,3 / 1 800 000))	21 partitions
Consumer parallelism	ceil(24000 × 1,3 / 1 500)	21 workers на группу при принятой производительности
Backfill одних суток при 3× средней capacity и живом среднем потоке	(12000 × 86 400) / (3 × 12000 − 12000)	43 200 с = 12 ч

GB и Mbit здесь десятичные. 1 500 events/s на partition/worker и 1,8 MB/s на partition — допущения теста. Для варианта без брокера строки RF/partitions относятся к альтернативному потоку или downstream outbox. RF не моделирует egress каждого consumer: добавьте по одной копии трафика на активную группу и репликационный трафик до RF−1 дополнительных копий. Пересчитайте отдельно при catch-up на пике, skew и p99 payload. Если capacity ≤ live rate, конечного времени восстановления нет.

Крупный tenant условно 0,35 × 12 000 = 4 200 events/s, при двукратном пике 8 400/s. При mean 1 100 B это 73,92 Mbit/s payload в пике. Shared cost allocation по byte-days, scanned GB, compute seconds и reserved capacity.

6. Варианты архитектуры¶

A — shared broker/compute/storage с tenant-aware routing и ACL. B — dedicated stacks для high-isolation tenants. C — shared control plane с выделенными pools по tiers.

7. Сравнение вариантов и выбор¶

Выбрать C с явными promotion criteria. A экономичен на малых workloads. B упрощает blast radius и isolation evidence ценой выделенной инфраструктуры и drift.

8. Component / data-flow¶

Иллюстративная схема выбранного варианта.

flowchart LR
 A["Tenant ingress"] --> B["Quota and identity guard"]
 B --> C["Partitioned processing and storage"]
 C --> D["Scoped consumers and billing"]

9. Normal processing sequence¶

sequenceDiagram
 participant A as Tenant ingress
 participant B as Quota and identity guard
 participant C as Partitioned processing and storage
 participant D as Scoped consumers and billing
 A->>B: Send identified input
 B->>C: Authorize tenant and commit isolated chunk
 C-->>B: Return tenant generation and usage evidence
 B->>D: Advance only with durable evidence

Получить trusted tenant ID из auth context, проверить quota, направить в partition/pool, записать scoped generation и usage facts. Reader проверяет tenant scope независимо от маршрута.

10. Failure / recovery sequence¶

sequenceDiagram
 participant B as Quota and identity guard
 participant C as Partitioned processing and storage
 participant O as Recovery owner
 B->>C: Attempt write or advance
 Note over B,C: Hot tenant consumes shared capacity
 O->>C: Throttle tenant and rebuild scoped data
 C-->>O: Durable outcome or explicit gap

При burst throttling применяется per tenant. Rebuild использует исходный tenant cut и scoped credentials. При подозрении на утечку остановить доступ в affected scope и провести evidence review. Deletion replay проверяет tombstone/version guard.

11. Data model и contracts¶

tenant_id включён в auth context, identity keys, partition manifests и usage facts. Storage keys и catalog привязаны к tenant. Deletion request имеет scope, disposition и evidence.

12. Consistency boundaries¶

Quota reservation и work acceptance согласованы в одном guard или bounded token protocol. Consumer view не заменяет tenant authorization. Cross-tenant publication блокируется policy.

13. Scaling и capacity planning¶

Использовать weighted fair scheduling, separate queues и per-tenant retry budget. Partition key tenant + bounded hash, если нет требования полного порядка по tenant. Dedicated pool для hot tier.

14. Observability¶

Per-tenant lag, quotas, throttled bytes, saturation, restore age, usage cost, access denies и cross-tenant anomaly. Ограничивать cardinality labels.

15. Data Quality и reconciliation¶

Сверять keysets и billable usage с независимым evidence. Deletion проверять по raw, views, archives, backups и catalog policy. Отдельно фиксировать legal hold.

16. Security и compliance¶

Tenant-aware ACL и storage policies, секреты по namespace, encryption, rotation и проверка обходных путей. Cache keys и log redaction защищают shared plane.

17. Implementation roadmap¶

Внедрить trusted identity, quotas и evidence. Затем noisy-neighbor rehearsal, dedicated tier, tenant restore и deletion drills.

18. Testing и acceptance criteria¶

Подать mismatched tenant ID, hot traffic, replay чужого scope, stale deletion и burst. Acceptance — нулевая видимость чужих данных в тестовом наборе, измеренная изоляция и подтверждённая usage сверка.

19. Trade-offs и ограничения¶

Shared инфраструктура эффективна при умеренном skew. Dedicated pools требуют автоматизации эксплуатации. Квоты могут отклонять legitimate bursts, поэтому нужны fairness и approved overrides.

20. Interview questions¶

Достаточно ли tenant_id в SQL WHERE? Проверки должны покрывать storage, cache, catalog и export. Как справедливо распределить общую стоимость? Разделить measured usage и reserved capacity с явной policy для общих расходов.

Первичные источники¶

Проверка источников: 2026-11-03. Документация описывает свойства компонентов. Результаты испытаний выбранной системы требуют отдельного evidence.