Модуль 12. Экономика и сайзинг
Зачем считать
Цель — обеспечить SLO BI/витрин минимальной разумной инфраструктурой и иметь прозрачный TCO (Total Cost of Ownership). Смотрим не «цены в вакууме», а нагрузку → ёмкость → стоимость → оптимизации.
Capacity planning: что и как замерять
CPU
-
Интерактивные запросы (Trino/ClickHouse): p95 длительности × пиковая конкурентность.
Оценка: vCPU_need ≈ concurrency × vCPU_per_query × (1 + headroom); для Trino часто 0.5–1 vCPU на активный запрос (без экстремальной агрегации). - BI web: небольшие 1–4 vCPU на под, масштаб по RPS/p95. Воркеры отчётов — отдельно.
- ETL/DAG: считайте задачи одновременно (burst), не DAG/сутки.
Память
- Trino: Mem_need ≈ concurrency × working_set_per_query × (1+headroom). На старте берите 4–8 ГБ/запрос (аналитика средней тяжести), добавляйте spill-диски.
- ClickHouse: зависит от max_threads и набора данных; на «холодном» кэше память критичнее CPU.
- BI web: 1–2 ГБ/реплика; Metabase (JVM) — следите за Xmx и паузами GC.
Диск/IOPS
- Postgres: отдельный быстрый том под WAL; ориентир — сотни/тысячи IOPS на пике; латентность <1–2 мс.
- ClickHouse: последовательные записи (MergeTree) + пики при merge/compaction; NVMe сильно помогает.
- S3/MinIO: пропускная способность сети и параллелизм клиентов важнее IOPS.
Сеть
- Ingress p95/p99, дыра на экспорт/импорт файлов, throughput к S3.
- Внутри кластера — планируйте 10/25 GbE для узлов «тяжёлых» пулов.
Практика замера: прогоните k6 по BI (см. Модуль 8), плюс репрезентативные SQL-наборы по Trino/CH. Возьмите пиковые значения и заложите headroom 20–40% (в отчётные окна).
Requests/Limits и QoS — чтобы «не переплатить»
- Requests ≈ p50, Limits ≈ p95 конкретного сервиса (не «на глаз»).
- У stateful (БД, Kafka, CH) — requests ближе к пику; web — ближе к среднему.
- Не ставьте Limits=Requests у JVM без замеров — получите early OOM.
- QoS классы (Guaranteed/Burstable) и bin-packing: лучше 2–3 «типоразмера» подов/нод, чем зоопарк.
Хранилище: S3 vs блок, hot/warm/cold
Что куда
- Hot (секунды отклика): Postgres (метаданные/оперативные витрины), ClickHouse (горячие партиции). Блок-тома (NVMe/SSD), репликация.
- Warm (десятки секунд): Iceberg/Parquet в S3 + Trino. Образцовый вариант для большинства BI.
- Cold (минуты/часы): архивы, бэкапы, версии снапшотов — S3 с дешёвыми классами хранения.
Стоимость и накладные
- Блок (Ceph/RBD/локальные SSD) дороже за TB, но даёт IOPS/латентность. Учитывайте репликацию (×2–3).
- S3 — дешёв по TB, но платите пропускной/операции и (в облаках) egress. В on-prem MinIO — без egress, но считаем диски/узлы.
- Iceberg требует компакшнов — планируйте compute окна (см. Модуль 7).
Spot/Preemptible и «дешёвые мегаватты»
- Где уместно: Trino workers, статeless web, воркеры Celery, Spark/Flink.
- Где нельзя: координатор Trino, БД, ZooKeeper/метасторы.
- Правила: запускайте на отдельном пуле с taints; держите минимум on-demand для покрытия базового трафика; тестируйте preemption (до 30 сек предупреждения).
Политика логов и метрик (ретеншн = деньги)
-
Логи: разделение по классам:
- доступ/инфраструктура — 7–14 дней,
- безопасность/аудит — 90–180 дней (архив в S3),
- дебаг — 1–3 дня (семплинг).
- Метрики: Prometheus 10–30 дней, долгосрочно — в Thanos/Mimir (S3).
- Трейсы: семплинг (1–10%), горячие 7 дней, архив — S3.
Модель стоимости (скелет)
Compute:
Cost_compute = Σ (nodes_count_pool × price_per_node_month_pool)
Где nodes_count получаем из CPU/Memory требований с учётом headroom и bin-packing.
Storage:
Cost_block = TB_block × price_block × replication_factor
Cost_S3 = TB_S3 × price_S3
Cost_backup = TB_backup × price_backup
Сеть:
Cost_egress = TB_egress × price_egress_per_TB (в он-прем — обычно 0).
Observability:
Cost_logs = GB_logs_month × price_per_GB_month
Cost_metrics = … (если платите внешнему сервису)
Total:
TCO_month = Compute + Storage + Network + Observability + Support/Licenses (если есть)
Типовые архитектуры и драйверы TCO
Вариант 1 — All-in k8s (Ceph + S3/MinIO):
-
Контроль и гибкость, меньше egress. – CAPEX на диски/узлы, накладные Ceph (репликация).
Драйверы: цена блок-хранилища и репликации, доля hot-таблиц на SSD, размер пулов Trino.
Вариант 2 — Гибрид (BI вне k8s):
-
Быстрый запуск, меньше статeless-узлов. – Составная сеть, отдельные VM-издержки.
Драйверы: сеть между VM и k8s, отдельные лицензии/поддержка BI.
Вариант 3 — Lakehouse-first (Trino+S3, минимум ClickHouse/DB):
-
Самый низкий TB-cost. – Больше compute в Trino/компакшны.
Драйверы: объёмы S3, окна компакшна/ресурсы, конкаррентность интерактивных запросов.
Где экономить (без боли для SLO)
- Уберите «малые файлы» в S3 (Iceberg rewrite/compaction) — ускорит Trino и уменьшит метаданные.
- Кэшируйте (Redis, result cache Trino/CH) популярные запросы.
- PgBouncer/лимиты: фиксируйте connection-budget BI/ETL, чтобы HPA не «съел» БД.
- Разделите пулы узлов и включите spot для эластичных workers.
- Ставьте requests по факту, не по «мечте»; используйте VPA-рекомендации для baseline.
- Ретеншн логов: горячие коротко, остальное — в S3 (чем реже нужен поиск, тем дешевле).
- Разумные индексы/партиции в Postgres/CH — снижение CPU/IO без увеличения TB.
- Scale-to-zero в Dev/Stage на ночь/выходные (CronHPA/KEDA).
Риски оценки и как защищаться
|
Риск |
Симптом |
Что сделать |
|---|---|---|
|
Недосайзинг |
SLO падает в отчётные окна |
Headroom 20–40%; хронометраж пиков; canary-тесты |
|
Пересайзинг |
Пустые узлы, высокий счёт |
Requests по факту, bin-packing, меньше «типоразмеров» |
|
Ceph «съел бюджет» |
×3 к TB-стоимости |
Разнести hot (Ceph) и warm/cold (S3), tune RF, учитывать EC |
|
Логи «заливают» |
Рост TB и счёта |
Ретеншн по классам, семплинг, JSON-строгий формат, фильтрация на входе |
|
Spot «роняет» отчёты |
Прерывания в прайм-тайм |
Минимум on-demand для базы трафика, graceful shutdown, retry с idempotency |
|
Egress в облаках |
«Неожиданная» строка в счёте |
Держать BI рядом с данными, кэш, CDN/проксирование |
Практика: калькулятор TCO для 3 вариантов
Что внутри файла (см. ссылку выше):
- Вкладка Inputs — нагрузки (конкурентность Trino/ETL, объёмы данных, логи), спецификации узлов и цены (на узел и на TB-месяц), а также базовые параметры по вариантам (кол-во стейтлесс/DB-узлов и TB под БД).
-
Вкладка Results — пересчёт требуемых ETL-узлов (по формуле из Inputs), объёмов S3/бэкапов/логов и итоговые месячные TCO для трёх архитектур:
- V1: All-in k8s (Ceph + S3/MinIO),
- V2: Гибрид (BI вне k8s),
- V3: Lakehouse-first (упор на S3/Trino).
Как пользоваться, шаг за шагом:
- Замените placeholder-цены в Inputs на ваши (или ₽).
- Подставьте свои пики: Trino concurrency, Airflow concurrent tasks, объёмы raw/curated, логи.
- Проверьте headroom (обычно 0.2–0.4) и overhead для ETL (1.05–1.2).
- При необходимости измените «базовые» узлы/ТБ по вариантам (DB-узлы/объёмы).
- Смотрите Results → TOTAL monthly cost по вариантам, сравнивайте «чувствительность» TCO при изменении параметров (что сильнее всего «двигает» счёт).
Скачать калькулятор TCO (XLSX)
Чек-лист перед бюджетом/пилотом
- Есть реальные измерения нагрузки (k6, SQL-наборы), не экспертные оценки.
- Requests/Limits проставлены и пересмотрены по замерам; QoS понятен.
- Разделены hot/warm/cold уровни с явными классами хранилища.
- Headroom и «N+1» в пиках; планы масштабирования (HPA/KEDA).
- Ретеншн логов/метрик оформлен и принят безопасниками.
- Spot-политика/узлы: где можно — включили; где нельзя — запрещено.
- DR-стоимости (репликации/бэкапы) включены в TCO, не забыты.
- Есть опорные меры оптимизации (компакшн Iceberg, кэш, пулы коннектов, pre-aggregations).
- Runbook «что режем первым» при превышении бюджета (частоты компакшнов, cold-тиир, лимиты экспорта).
