FinOps: оптимизация затрат на облако глазами разработчика

Прямой ответ

FinOps — практика управления затратами на облако, где решение о расходах принимает тот, кто создаёт нагрузку. Для разработчика это означает, что запросы ресурсов, размер инстансов и объём хранимых данных определяют счёт, а не задаются кем-то отдельно.

Основные статьи затрат, на которые влияет код:

Первая по величине ошибка — завышенные запросы ресурсов. Запрос определяет, сколько места кластер резервирует под под, а не сколько под использует:

resources:
  requests:
    cpu: "2"        # резервируется 2 ядра на под
    memory: "4Gi"
  limits:
    cpu: "4"
    memory: "8Gi"

Если под использует 300 миллиядер и 700 мегабайт, кластер держит резерв, за который платит команда. Запрос выставляется по фактическому использованию с запасом 20–30 процентов, а не по опасению; о настройке — в статье про запросы и лимиты.

Вторая статья — постоянное число реплик. Сервис с суточной неравномерностью держит ночной запас днём и наоборот. Горизонтальное автомасштабирование меняет число подов по загрузке:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: {type: Utilization, averageUtilization: 70}

Масштабирование по CPU работает, если сервис масштабируется по CPU. Для сервисов, ожидающих ответа внешних систем, показатель загрузки процессора не отражает нагрузку; о выборе метрики — в статье про HPA.

Третья статья — данные без срока жизни. Логи, метрики высокой детализации и резервные копии копятся годами. Стоимость хранения растёт линейно, а ценность данных падает; о сроках — в статье про сроки хранения.

Четвёртая — работающие тестовые стенды. Окружение, работающее круглосуточно при использовании восемь часов в день, стоит втрое дороже необходимого.

Практика: снижение затрат без потери качества

1. Измеряйте фактическое использование. Метрики потребления CPU и памяти за две недели — основание для запросов. Без них любое значение взято наугад; о планировании — в статье про capacity planning.

2. Выставляйте запросы по факту с запасом 20–30 процентов. Запас в несколько раз резервирует ресурсы кластера и оплачивается как использованные.

3. Включите автомасштабирование. Минимум реплик по ночной нагрузке, максимум — по пиковой; о границах — в статье про HPA.

4. Выключайте неиспользуемые окружения. Задача по расписанию останавливает тестовые стенды вечером и поднимает утром.

5. Установите сроки хранения данных. Метрики высокой детализации живут дни, агрегаты — месяцы, логи — по политике.

6. Используйте прерываемые инстансы для фоновых задач. Пакетная обработка и тесты переносят остановку, поэтому стоимость снижается существенно.

7. Распределите затраты по сервисам. Метки на ресурсах позволяют видеть, кто создаёт расход. Без атрибуции оптимизация не имеет адресата.

8. Проверяйте стоимость изменений. Увеличение числа реплик или объёма кеша — решение с ценой, которую стоит оценивать до применения.

Рекомендации:

1. Не оптимизируйте до измерения. Снижение запросов без данных о потреблении приводит к троттлингу и деградации.
2. Различайте запрос и лимит. Запрос влияет на планирование и резерв, лимит — на максимальное потребление.
3. Учитывайте стоимость передачи данных между зонами. Обращение к базе в другой зоне доступности тарифицируется и добавляет задержку.
4. Проверяйте неиспользуемые ресурсы. Диск без подключений, балансировщик без сервисов и снимки многолетней давности оплачиваются.
5. Фиксируйте стоимость в обзорах архитектуры. Новый сервис имеет цену владения, которую полезно знать до запуска.

Практический сценарий: снижение счёта на треть через запросы ресурсов и расписание стендов

Контекст: ежемесячный счёт вырос вдвое за полгода без сопоставимого роста нагрузки. Анализ показал, что нагрузка выросла на 40 процентов.

1. Диагностика. Метрики потребления показали, что поды используют в среднем 25 процентов запрошенного процессора и 30 процентов памяти. Тестовые окружения работали круглосуточно при использовании в рабочее время.
2. Причина. Запросы ресурсов выставлялись при создании сервисов с запасом и не пересматривались. Окружения поднимались вручную и не останавливались.
3. Действия. (а) Запросы пересчитали по фактическому потреблению за две недели с запасом 25 процентов; (б) включили автомасштабирование с минимумом две реплики вместо постоянных шести; (в) добавили задачу, останавливающую тестовые окружения вечером и поднимающую утром; (г) установили срок хранения метрик высокой детализации 14 дней, агрегатов — год; (д) добавили метку сервиса на ресурсы для атрибуции затрат.
4. Результат. Счёт снизился на 34 процента при росте нагрузки на 40 процентов. Задержка не изменилась, поскольку фактическое потребление осталось прежним, а резерв перестал простаивать.

Вывод: основные затраты создаются не нагрузкой, а запасом «на всякий случай» и неиспользуемыми ресурсами. Оптимизация начинается с измерения фактического потребления, а не с поиска дорогих сервисов.

FAQ

Что влияет на счёт сильнее всего? Запросы ресурсов и число постоянно работающих реплик. Хранилище обычно занимает меньшую долю, но растёт без ограничения срока жизни данных.

Можно ли снизить запросы без риска? Да, если запросы превышают фактическое потребление в разы. Снижение до фактического уровня с запасом 25 процентов не влияет на производительность.

Как понять, какие ресурсы не используются? Метриками потребления за период. Ресурс с нулевым потреблением и отсутствием подключений можно удалить после проверки.

Что делать с тестовыми окружениями? Останавливать по расписанию. Круглосуточная работа стенда, используемого восемь часов в день, увеличивает его стоимость втрое.

Источники: FinOps Framework, Kubernetes docs (ресурсы контейнеров, HPA) — ссылки в шапке.