Оптимизация расходов на инфраструктуру

Краткое резюме

Финансовая эффективность инфраструктуры упирается в три вещи:

1. Прозрачная измеримость (тэги, showback/chargeback, $/единицу ценности).

2. Инженерная дисциплина (rightsizing, авто-скейл, правильные классы хранилищ/кэшей/сетей).

3. Архитектурные решения (куда «утекают» байты и миллисекунды).

Цель — понизить TCO при сохранении SLO и скорости разработки.

Бизнес-метрики и unit-economics

$/1000 RPS — стоимость обработки 1000 запросов на ключевых маршрутах.
$/мс p95 — стоимость снижения хвоста задержек на 1 мс (важно для конверсии).
$/игрок/месяц или $/депозит — для iGaming/финтех.
TCO = compute + storage + network egress + managed-сервисы + лицензии + поддержка.
Капитализация технического долга: фиксируйте, сколько стоит «непочиненная» латентность/утечки логов.

Пример:

Если API стоит $120/час и отдает 60k RPS при целевом p95, то $/1000 RPS ≈ $2/ч. Любая оптимизация должна сравниваться с этой «ценою единицы».

Инвентаризация и тэгирование

Тэги обязательны: `env`, `owner`, `product`, `service`, `region`, `cost-center`, `tier`.
Showback/Chargeback: еженедельные отчеты по командам/сервисам.
Контроль «ничейных» ресурсов: без тегов — не разворачиваем, не продлеваем.

SQL-эскиз для DWH отчета (идея):

sql
SELECT env, product, service,
SUM(cost_usd) AS cost_month,
SUM(rps) AS rps_month,
SUM(cost_usd)/NULLIF(SUM(rps)/1000,0) AS usd_per_1k_rps
FROM finops_daily
WHERE usage_date BETWEEN:from AND:to
GROUP BY 1,2,3;

Rightsizing и классы инстансов

CPU/Memory профили: снимайте профили под нагрузкой; снижайте запросы/лимиты до «рабочей точки» CPU 50–70%.
Размер инстансов: часто выгоднее N маленьких вместо M больших (лучше bin-packing + CA).
ARM-инстансы: дешевле при сопоставимой производительности, если стек совместим.
Горячие/холодные пулы: держите небольшой warm-запас вместо постоянного «жира».

Скидки и модели потребления

Reserved/Savings Plans/Committed Use: бронируйте устойчивую базу (40–70% экономии).
Spot/Preemptible: для некритичных/асинхронных задач, CI, аналитики, кэш-воркеров.
Mix-стратегия: база — reserved, пики — on-demand, фон — spot.

Авто-скейлинг и эластичность

HPA/KEDA по SLO-сигналам (latency, queue lag, RPS), а не только по CPU.
Cluster Autoscaler с warm pools и image pre-pull для быстрых стартов.
Scale-down с гистерезисом, чтобы не «пилить» кластеры (анти-флаппинг).

Сеть и egress — тихий «пожиратель» бюджета

CDN/tiered-cache/origin-shield снижают egress из origin.
Сжатие (Brotli/gzip), webp/avif, дифф-API (передавать только измененные поля).
Группируйте вызовы к внешним API, используйте keepalive/retry-budget.
Меньше чатов внутри DC: event-driven, батчинг, агрегация событий.

Хранилища и данные

Классы хранения: горячее (NVMe), теплое (gp2/gp3), холодное (S3/Glacier/архив).
Lifecycle-политики: автоматический перевод «старых» объектов на дешевые классы.
Сжатие/партиционирование в DWH, TTL на временные таблицы/снапшоты.
Отказ от избыточной репликации: разумный RF, экономные snapshot-политики.
Кэширование: Redis/Memcached для hot-set вместо «дорогих» чтений из БД.

Логи, метрики, трейсы — платить с умом

Семплирование логов (rate-limit по уровню/шаблону), «структурные» логи вместо болтовни.
Tail-based sampling для трасс (сохраняем «хвосты» p99 и ошибки, остальное — агрессивно режем).
Downsampling метрик: агрегация в push-гейтах, хранение high-res только 7–14 дней.
Фильтрация PII — снижает и риски, и объем.

Архитектура и «стоимость миллисекунды»

HTTP/2/3 + resumption: меньше handshake → меньше CPU/egress/латентность.
Ключ кэша и TTL: высокий hit-ratio — прямые деньги (меньше origin и DB).
gRPC/протобаф для сервис-сервис: поменьше байтов.
Batch/stream для фоновых задач; идемпотентность → меньше ретраев.
Выбор БД: не храните «все в одной» — дешевые KV/кэши для частых чтений, аналитика — в колонночном DWH.
Схемы данных: короткие поля/сжатые типы, контроль кардиналитета индексов.

DR, резервы и мульти-регион

Цель по бизнесу: RTO/RPO → стоимость DR. Не переплачивайте за актив-актив, если достаточно актив-пассив.
Храните холодные резервные копии в дешевом классе, реплика — дифференциальная.
Единый пакет PoP/регионов: каждая зона тянет ≥60% пика → выдерживаем отказ соседа без «золотой» избыточности.

Окружения и CI/CD

Автоспячка стейджингов/превью-окружений, авто-TTL.
Runner-ы CI на spot, кэш артефактов, ограничения параллелизма.
Тест-данные компактные, генерация on-the-fly, а не хранение гигабайт.

Управление поставщиками и лицензиями

Пересматривайте объемы и прайс-типы раз в квартал.
Конкурентный бэкап-провайдер — аргумент в торге.
Лицензии (АПМ/безопасность): рассчитывайте $ за полезный сигнал, а не за «все логи мира».

Процессы и управление

FinOps-церемонии: еженедельный отчет по командам, ежемесячный Cost Review (топ-10 «утечек», action items).
Guardrails: квоты на проект/неймспейс, бюджет-алерты, запрет разворачивать ресурсы без тегов.
Blameless пост-морем по «ценовым инцидентам» (утечка логов, runaway autoscale).
IaC: все лимиты, классы, TTL — в репозитории, PR-ревью.

Чек-лист экономии

Тэги/шоубэк/чарджбэк включены, «ничейных» ресурсов нет.
Rightsizing по профилям, ARM/другие типы оценены.
Коммит-скидки закрывают базу, spot — фон/аналитика/CI.
HPA/KEDA по SLO-метрикам, CA с warm-пулами.
CDN/tiered-cache, сжатие, ключ кэша без «шума».
Хранилища: классы, lifecycle, TTL, кэши для hot-set.
Логи/трейсы: семплирование, tail-based, PII-фильтры.
DR по RTO/RPO, холодные бэкапы в дешевом классе.
Окружения с авто-TTL, CI на spot.
FinOps-ритмы и guardrails в IaC.

Типичные ошибки

«Оптимизация без метрик»: нет $/1000 RPS → нельзя сравнить варианты.
Отключенные/неиспользуемые ресурсы висят месяцами.
Хранение «всего» в горячем классе, отсутствие lifecycle.
Логи как «черная дыра»: 100% ingest, 0% употребления.
Авто-скейл по CPU без учета latency/очередей → переплата и SLO-регресс.
Слишком агрессивный DR без бизнес-обоснования.
Микросервисы «для галочки» — рост межсервисного трафика и накладных.

Мини-плейбуки

1) Быстрый аудит счета (48 часов)

1. Срез по топ-10 сервисам/региону. 2) По каждому — $/1000 RPS, hit-ratio CDN, egress.
2. Выкатить TTL/кэш-ключи, выключить «шумные» логи. 4) Включить lifecycle на S3/объекты.

2) Снижение egress на 25%

1. Tiered-cache+shield, `stale-while-revalidate`. 2) Сжать изображения в webp/avif.
2. Дифф-API и gzip/brotli на текст. 4) Проверить повторные запросы/ретраи.

3) Срез затрат на БД

1. Топ-запросы (p95/IO) → индексы/батчирование. 2) Hot-set в Redis.
2. Архивация старых данных (TTL), read-replicas на дешевом сторе.

4) Прекращение «пилы» скейла

1. Увеличить stabilization/cooldown. 2) MinReplicas > 0 на пике.
2. Предпрогрев коннектов/TLS. 4) Срезать лишние ретраи.

Пример «экономного» Nginx (сжатие, кэш, SWR)

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=EDGE:512m max_size=50g inactive=7d;

server {
listen 443 ssl http2 reuseport;

Compression brotli on; brotli_comp_level 5; gzip on;

Static: year, immutable location/assets/{
add_header Cache-Control "public, max-age=31536000, immutable" always;
try_files $uri =404;
}

Semi-dynamics: s-maxage + SWR location/catalog/{
proxy_cache EDGE;
add_header Cache-Control "public, s-maxage=600, max-age=120, stale-while-revalidate=900, stale-if-error=86400" always;
proxy_ignore_headers Set-Cookie;
proxy_pass https://origin_catalog;
}
}

Специфика для iGaming/финтех

Пики (матчи/турниры): заранее поднять `minReplicas` и прогреть CDN/TLS, но держать headroom точечно — только на горячих путях (каталоги, лобби, матчи), остальное — в деград-режим.
Платежи/PSP: кэш справочников (BIN, лимиты), идемпотентность снижает стоимость дублей, отдельный egress-пул для белых списков провайдеров.
Антифрод/боты: «серые» маршруты и дешевые челленджи на краю вместо дорогой глубокой проверки по каждому запросу.
Лайв-контент/провайдеры: кэш на краю + ограничение частоты обновлений; CDN-контракты пересматривать к крупным ивентам.

Итог

Оптимизация расходов — это не разовая чистка, а постоянный FinOps-процесс: измеряйте ценность ($/единицу), автоматизируйте экономные решения (кэш/TTL/семплирование), используйте скидки и правильные классы ресурсов, держите эластичность под SLO и не усложняйте архитектуру там, где она не окупается. Так вы снизите TCO, сохранив скорость продукта и устойчивость платформы.