Модуль 16. Кейсы и шаблоны
Вы уже видели все кирпичики (k8s, сеть, безопасность, GitOps, стеки данных). Теперь собираем их в три практичных шаблона:
- Open-source end-to-end: Kafka/Debezium → S3/Iceberg → Trino → dbt → Superset.
- Гибрид с российским BI: вся data-платформа в k8s, BI вне кластера (SSO, Ingress-обвязка).
- Регулируемая среда: строгая безопасность (сегментация сети, секреты, аудит, DR-контуры).
Каждый шаблон описан одинаково: когда выбирать, референс-архитектура, как развёртывать/эксплуатировать, SLO, стоимостные рычаги, риски и анти-паттерны.
Кейс 1. Open-source стек end-to-end
Когда выбирать
- Нужна максимальная гибкость и независимость от вендоров.
- Акцент на Lakehouse (Iceberg/S3) и горизонтально масштабируемый запросный слой (Trino).
- BI — Superset/Metabase, оркестрация — Airflow/Dagster.
Референс-архитектура (высокоуровнево)
[OLTP PG] --CDC--> [Kafka/Strimzi + Debezium] --> [S3/MinIO raw]
-> [Ingestion/Compaction -> Iceberg curated]
Trino(iceberg,pg,ch) <-- dbt Core --> marts
\
-> Superset (SSO) -> Users
Пулы нод: pool=etl (Kafka/Trino workers), pool=stateful (PG/CH/HMS), pool=stateless (BI/Airflow), при необходимости pool=gpu.
Хранилища:
- Блок (RWO, NVMe/SSD) — Postgres/ClickHouse.
- S3 (MinIO/Ceph RGW) — сырые/curated данные, бэкапы, отчёты.
Сеть: два Ingress-контура (external для BI, internal для платформы), default-deny, mTLS между сервисами.
Внедрение / эксплуатация (шпаргалка)
- GitOps: Argo CD (app-of-apps), Helm для Trino/Airflow/Superset/MinIO, Kustomize для политик.
- Данные: Debezium → S3 Sink (Parquet) → ingestion job → Iceberg; регулярные compaction.
- Трансформации: dbt (инкрементальные merge, тесты, exposures).
- DQ/каталог: dbt tests + Great Expectations для углублённых чеков; OpenLineage → Marquez/каталог.
- Наблюдаемость: kube-prometheus-stack; burn-rate по SLO, метрики Debezium lag/Trino queued/BI 5xx.
- Безопасность: External Secrets + Vault; Kyverno/Gatekeeper; подписи образов (cosign).
Целевые SLO (ориентиры)
- Freshness витрин: 99% ≤ 60 мин (пн–пт 08:00–22:00).
- Trino success-rate: ≥ 99%, p95 интерактивных запросов ≤ 10 с.
- BI availability: ≥ 99.5%, p95 UI ≤ 2.5 с.
- CDC lag: медиана < 60 с, p95 < 5 мин.
Стоимостные рычаги (см. Модуль 12)
- Бóльшая часть TB — в S3 (дешевле блока).
- Spot для Trino workers и воркеров Airflow; on-demand для координаторов/БД.
- Сокращение логов (ретеншн/семплинг), регулярный compaction Iceberg.
Риски / анти-паттерны
- Малые файлы в S3 → медленный Trino. Решение: compaction + корректные микробатчи.
- Топчут источники коннектами. Решение: pgBouncer/лимиты Trino; connection-budget на HPA/KEDA.
- DQ «после факта». Решение: DQ-gate перед публикацией в marts.
- Единичные точки отказа (Redis, HMS). Решение: HA/кластерные конфигурации, PDB/topology spread.
Кейс 2. Гибрид с российским BI (BI вне k8s)
Когда выбирать
- Вендор не поставляет контейнеры/нужен Windows-стек/лицензии по «ядрам».
- Быстрый запуск: платформа в k8s, BI остаётся на VM, но работает с данными из кластера.
Референс-архитектура
+-------------------+ +---------------------------+
Users --> | BI (PIX/Visiology/Модус) | <--(OIDC/SAML)--> IdP |
+-------------------+ +---------------------------+
| \
(mTLS, IP allowlist) \ (S3 pre-signed URLs)
| \
+----------- Internal Ingress -----------+
| Trino | ClickHouse | Postgres | MinIO |
+----------------------------------------+
(внутри k8s)
Сеть: IP-allowlist для подсети BI, mTLS от Ingress к backend, отдельный ingressClass: nginx-internal.
Экспорт: большие отчёты → в S3, пользователю отдаём pre-signed ссылку.
SSO: единый IdP (OIDC/SAML), группы → роли в BI и в источниках.
Внедрение / эксплуатация
- Стабильность рассылок/экспортов: единый scheduler (если у BI возможен дублирующий запуск — перенесите планирование в Airflow по API BI).
- Пулы соединений: PgBouncer/лимиты Trino; не превышать connection budget при росте BI-реплик.
- Наблюдаемость: синтетические проверки доступности BI, отдельные дашборды Ingress-внутреннего контура, алерты на 5xx/latency и freshness.
SLO (отличия от кейса 1)
- Вводим SLO на внутренний Ingress (мост «BI↔k8s») и мониторим ошибки экспортов.
Стоимостные рычаги
- Меньше stateless-узлов в k8s, но возможна плата за VM/лицензии BI.
- Сильно влияет сеть между BI и k8s: держите BI «рядом» (низкая латентность).
Риски / анти-паттерны
- Дубли рассылок при нескольких узлах BI. Решение: single-scheduler или внешний оркестратор.
- Расшитый доступ из BI. Решение: internal Ingress + IP-allowlist + NetworkPolicy default-deny.
- Ручные настройки BI. Решение: экспорт/импорт конфигов «как код».
Кейс 3. Регулируемая среда (строгая безопасность)
Когда выбирать
- Требования отраслевых регуляторов/внутренних стандартов: сегментация, аудит, контролируемые изменения, DR-учения, PII/Sensitive-данные.
Референс-архитектура (зоны)
[DMZ/External] -> только WAF/SSO фронт [App/BI Zone] -> BI, прокси, внешние интеграции (ограниченно) [Data Zone] -> Trino, CH, PG, Kafka, MinIO, Catalog/MDM [Management] -> Argo CD, Vault, Observability, CI/CD, SIEM (Все зоны сегментированы; межзонный трафик по allow-list; мTLS/Policy-as-Code)
Технические практики безопасности
- Сегментация сети: два Ingress-класса, default-deny везде; L7-контроль (Cilium/Service Mesh) для критичных маршрутов.
- Секреты: Vault + External Secrets; краткоживущие креды (DB/Cloud), ротация; запрет Secret-yaml в Git.
- Политики: Pod Security (restricted), Kyverno/Gatekeeper (реестры, привилегии, подписи образов).
- Подписи образов: cosign + проверка в admission.
- Аудит: audit-лог API k8s, Ingress/WAF, BI/каталога в SIEM; неизменяемый архив (WORM).
- DR: Active-Passive (репликация бакетов/журналов, PITR), ежеквартальные учения, «break-glass» доступ.
Мини-фрагмент (идея whitelist для внутреннего Ingress):
metadata:
annotations:
kubernetes.io/ingress.class: nginx-internal
nginx.ingress.kubernetes.io/whitelist-source-range: "10.10.20.0/24"
SLO/процессы
- Дополняем бизнес-SLO контролями соответствия: ротация секретов в срок, покрытие политиками, успешные DR-учения.
- Change-management: CAB, окна, гейты (подписи, уязвимости, DQ), журнал изменений в SIEM.
Стоимостные рычаги
- DR/аудит/хардненг удорожают владение; экономим на lakehouse-подходе (S3 > блок), автоматизации (GitOps), spot-узлах для «эластики».
Риски / анти-паттерны
- «Безопасность победила доступность»: слишком узкие политики → инциденты. Решение: параллельное окружение для теста политик, staged rollout (audit→warn→enforce).
- Неучтённый аудит: данные уходят «мимо SIEM». Решение: карта потоков и источников аудита, регулярные сверки.
- DR «на бумаге». Решение: учения с реальным восстановлением и таймером RTO/RPO.
Сравнение кейсов: компромиссы (ориентиры)
|
Критерий |
Open-source e2e |
Гибрид с BI вне k8s |
Регулируемая среда |
|---|---|---|---|
|
Time-to-Value |
Средний |
Быстрый |
Средний/медленный |
|
Сложность эксплуатации |
Средняя |
Средняя (две зоны) |
Высокая |
|
CAPEX/TCO (при равных объёмах) |
Низкий/средний |
Низкий/средний |
Средний/высокий |
|
Производительность интерактива |
Высокая (Trino/CH) |
Высокая (если сеть близко) |
Высокая (при правильной сегментации) |
|
Соответствие/аудит |
Базовое |
Базовое/среднее |
Продвинутое (обязательно) |
|
Риски интеграций |
Низкие |
Средние (BI-вендор) |
Средние/высокие (политики/сегментация) |
Готовые «кирпичи» по всем кейсам (чтобы не забыть)
- GitOps: app-repo/env-repo, Argo CD, canary/rollouts, release-gates (SLO/DQ/подписи).
- Наблюдаемость: SLO BI/Trino/CDC/freshness, burn-rate, дашборды per-team, аннотации релизов.
- Секреты: только через Vault/ESO; SA-токены не автомаунтим, токены краткоживущие.
- Сеть: internal/external Ingress, default-deny, IP-allowlist на мосты, mTLS, egress-контроль.
- Данные: Iceberg + compaction, dbt incremental/merge, DQ-gates, OpenLineage, каталог.
- DR/HA: PDB/topology spread; standby Trino-координатор; PG PITR; репликация бакетов.
Риски и их снятие (универсальная таблица)
|
Риск |
Где проявляется |
Контрмера |
|---|---|---|
|
CDC lag и рост WAL |
Debezium/PG |
Мониторинг slot lag, быстрый Connect, увеличение wal_keep_size, аварийный план |
|
Коннекты «съедены» |
BI/Trino/PG |
PgBouncer, лимиты Trino/CH, HPA с connection-budget |
|
Малые файлы |
S3/Iceberg |
Ingestion-батчи, compaction schedule |
|
Экспорты «жарят» Ingress |
BI/Web |
Фоновые воркеры + S3 ссылки, лимиты размеров/TTL |
|
Политики ломают деплой |
Regulated |
«audit→warn→enforce», тестовый конинг, шаблоны разрешённых паттернов |
|
DR нерабочий |
Все |
Регулярные учения, чек-листы, таймеры RTO/RPO |
Практика: разбор компромиссов и ADR
Как проводить разбор (workshop, 2–3 часа)
- Осевая матрица (1–5 баллов): Time-to-Value, Сложность, SLO-риск, TCO, Безопасность, Удобство BI.
- Оцените каждый кейс вашими баллами, обсудите расхождения, зафиксируйте обоснование.
- Назначьте go-to кейс на пилот и перечень «усилий» (например, «BI остаётся на VM, но делаем S3-экспорт и internal Ingress»).
- Подготовьте 3–5 ADR на ключевые развилки.
ADR — шаблон (одна страница)
- ADR-ID / Дата / Статус (принято/в работе/заменено)
- Контекст: кратко, какая проблема/ограничение/требования.
- Решение: что выбираем и почему (критерии, сравнение альтернатив).
- Последствия: плюсы/минусы, что меняется в эксплуатации/безопасности.
- SLO/ТCO-влияние: ожидания по доступности/латентности/стоимости.
- Риски/Митигирующие меры: список и как снимаем.
- Миграция/План внедрения: шаги, обратимость/rollback.
- Владельцы / Дата пересмотра.
Примеры ADR (очень кратко)
ADR-001: Формат таблиц Lakehouse — Iceberg
- Контекст: десятки TB, частая эволюция схем.
- Решение: Iceberg (ACID, снапшоты, schema evolution).
- Последствия: компакшн как плановые окна; Trino как основной движок; HMS/REST-каталог.
- Риски: малые файлы → compaction; Снятие: расписания, мониторинг размеров файлов.
ADR-002: BI вне k8s с internal Ingress к платформе
- Контекст: вендорские ограничения.
- Решение: гибрид; IP-allowlist, mTLS, S3-экспорт.
- Риски: дубли рассылок; Снятие: единый scheduler или оркестрация через Airflow API.
ADR-003: DR стратегия — Active-Passive
- Контекст: критичные витрины, RPO≈0, RTO ≤ 30 мин.
- Решение: репликация бакетов/журналов, PG sync реплика, развёртывание compute из Git.
- Риски: стоимость/сложность; Снятие: автоматизация cutover, ежеквартальные учения.
Что отдать в репозиторий (готовые шаблоны)
-
Шаблон env-repo с тремя каталогами кейсов (oss-e2e, hybrid-bi, regulated), где лежат:
- Kustomize overlays (ingress-классы, NetPol по умолчанию, PDB/topology spread).
- Helm values для Trino/Airflow/Superset/MinIO (или прокси для гибрида).
- Политики Kyverno/Gatekeeper (минимальный набор).
- Пример ExternalSecret (секреты БД, S3, SMTP).
- Шаблон ADR (Markdown).
- Чек-лист запуска пилота на 1–2 домена данных.
Короткий «Go/No-Go» чек-лист по кейсам
- SSO/IdP и роли согласованы, BI/каталог подключены.
- Ingress: внешний/внутренний, TLS/mTLS, IP-allowlist.
- Secrets: Vault/ESO, без «секретов в yaml».
- Сеть: default-deny, нужные egress-правила.
- Данные: Iceberg+compaction, dbt incremental, DQ-gate, lineage.
- Наблюдаемость: SLO/алерты, burn-rate, CDC lag, queued queries.
- DR: PITR/репликация бакетов, план учений.
- TCO: оценён (калькулятор из Модуля 12), лимиты логов.
- ADR: ключевые решения оформлены и одобрены.
Кейсы — это «собранные» маршруты внедрения: open-source e2e (максимальная гибкость), гибрид с BI вне k8s (быстрый выигрыш) и регулируемая среда (безопасность по максимуму). Любой из них можно адаптировать под ваш ландшафт через ADR: зафиксировать контекст, решение, последствия и план внедрения/отката. Главное — держать в фокусе SLO, безопасность, TCO и «операционку как код»: тогда выбор будет осознанным, а внедрение — безболезненным.
