Счёт за облако вырос вдвое без роста нагрузки: где искать причину

MAATRIX

Открываете счёт за облачную инфраструктуру и не понимаете, что произошло: сумма выросла в полтора-два раза, а трафик, число пользователей и объём данных остались примерно на том же уровне, что и месяц назад. Первая реакция — искать ошибку биллинга. Но в подавляющем большинстве случаев рост объясняется не ошибкой, а накопившимися мелочами, которые незаметно превращаются в заметную сумму. Ниже — где именно искать причину и что проверить в первую очередь, чтобы не гадать, а найти конкретную статью расходов.

С чего начать: разложить счёт на составляющие

Прежде чем искать виновника, разложите счёт на структуру. Итоговая сумма — это почти всегда сумма из десятка строк: вычислительные ресурсы, диски, снапшоты, исходящий трафик, резервное копирование, отдельные управляемые сервисы (базы данных, очереди, балансировщики), логи и мониторинг. Рост вдвое почти никогда не даёт равномерный вклад по всем строкам — обычно 70-90% прироста сидит в одной-двух категориях.

Порядок действий:

1. Откройте детализацию счёта и отсортируйте позиции по абсолютному приросту в деньгах, а не в процентах. Позиция, выросшая на 300% с 2 до 6 условных единиц, менее важна, чем позиция, выросшая на 20% с 500 до 600.
2. Сравните текущий период с предыдущим по каждой крупной статье отдельно, а не по итоговой сумме.
3. Отметьте, какие статьи выросли, а какие остались на месте — это сразу сужает круг поиска.

Если у провайдера есть экспорт биллинга в CSV — выгружайте его за два-три периода и сравнивайте построчно. Веб-интерфейс часто прячет мелкие, но многочисленные позиции внутри агрегированных цифр:

# псевдо-пример логики сравнения (адаптируйте под формат экспорта вашего провайдера)
diff <(sort billing-prev-month.csv) <(sort billing-this-month.csv) | grep '^>' | sort -t, -k3 -n -r | head -20

Здесь -k3 — условный номер колонки с суммой, у разных провайдеров формат отличается, но идея — сортировать по абсолютному изменению — работает всегда.

Забытые ресурсы: тестовые окружения и осиротевшие инстансы

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

Такие ресурсы редко дают заметную нагрузку — они простаивают, но тарифицируются по факту существования (аренда вычислений, выделенный IP, диск под машиной), а не по факту использования. Поэтому счёт растёт, а метрики нагрузки остаются на прежнем уровне: заброшенный ресурс не даёт нагрузки, он даёт только счёт.

Что проверить:

• Список всех инстансов по всем окружениям (dev, staging, QA, песочницы разработчиков) — не только продакшен.
• Дату последнего входящего трафика или логина на каждой машине. Если ресурс не принимал соединения два-три месяца — кандидат на удаление.
• Ресурсы, созданные людьми, которые уже не работают над проектом.
• Отдельные учётные записи и подпроекты внутри организации — если доступ к биллинговому аккаунту есть у нескольких команд, тестовые окружения плодятся особенно быстро.

Хорошая практика — обязательные теги ресурсов с датой создания, ответственным и назначением ещё на этапе создания. Тогда через полгода не придётся гадать, можно ли удалить безымянную машину.

Снапшоты и диски: тихий накопитель расходов

Снапшоты дисков — вторая по частоте причина. Логика простая: перед рискованным обновлением делаем снапшот «на всякий случай», обновление проходит успешно, снапшот остаётся лежать. Через несколько месяцев таких снапшотов десятки, и каждый тарифицируется отдельно, пропорционально занимаемому месту.

Рост стоимости снапшотов происходит с задержкой и без явного триггера — вы не создавали ничего нового в этом месяце, но старые снапшоты продолжают числиться (у части провайдеров новые снапшоты хранят только дельту от предыдущего, и при удалении промежуточного снапшота из цепочки объём оставшихся неожиданно вырастает).

То же с неприкреплёнными дисками (orphaned volumes): диск отсоединили от машины при пересоздании или миграции, но не удалили. Он продолжает тарифицироваться отдельно, при этом не связан ни с одной работающей машиной — поэтому не отражается ни в одном графике нагрузки.

Что проверить:

• Список всех снапшотов с датой и объёмом, отсортированный по объёму. По каждому снапшоту старше 30-60 дней — вопрос «зачем он ещё здесь».
• Диски, не прикреплённые ни к одному инстансу.
• Автополитики снапшотирования — часто настроены один раз («каждую ночь») без ограничения срока хранения, и копится сотня ежедневных снапшотов вместо нужных 7-14.
• Образы (images), собранные вручную для деплоя — старые версии тоже занимают место.

Подробнее о том, как облачные провайдеры выстраивают эти издержки и в какой момент они перевешивают ожидаемую экономию от эластичности, — в статье «Где облако становится дороже VPS».

Резервное копирование без ротации старых копий

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

Рост стоимости бэкапов коварен тем, что происходит плавно — плюс несколько процентов в месяц, — а через год превращается в заметную долю всего счёта. По дням аномалии не видно: просто линейный рост объёма хранения, который никто не замечает, пока не сравнит счёт годовой давности с текущим.

Отдельная ловушка — резервное копирование одних и тех же данных несколькими независимыми механизмами: штатный снапшот диска плюс отдельный скрипт бэкапа базы плюс репликация в другой регион «для надёжности», настроенные разными людьми в разное время без координации. По отдельности каждый механизм оправдан, вместе — это тройная оплата за одни и те же данные.

Что сделать:

• Задать явную политику ротации: сколько последних ежедневных копий храните, сколько еженедельных, сколько ежемесячных — и настроить автоудаление того, что старше.
• Проверить, не дублируется ли копирование несколькими механизмами.
• Периодически, а не только при инциденте, проверять, что старые бэкапы действительно удаляются по политике, а не просто «должны» — иногда правило настроено, но не работает из-за прав доступа или изменившегося формата хранилища.

Как рассчитать разумный срок хранения и глубину ротации, подробно разобрано в статье «Сколько хранить бэкапы и какая нужна ротация».

Трафик между регионами и зонами доступности

Эта причина реже приходит в голову первой: почему трафик должен вырасти, если число пользователей не изменилось? Ответ — трафик пользователей и внутренний трафик инфраструктуры считаются раздельно, и второй часто растёт независимо от первого.

Типичный сценарий: приложение и база данных изначально были в одной зоне доступности, а затем часть компонентов — реплику для аналитики, узел кеша, сервис очередей — развернули в другом регионе. Трафик между регионами и зонами у большинства провайдеров тарифицируется отдельно и заметно дороже трафика внутри одной зоны, иногда дороже исходящего трафика в интернет. Если два интенсивно обменивающихся данными компонента оказались территориально разнесены, счёт за передачу данных может вырасти в разы без единого дополнительного пользователя приложения.

Похожий эффект даёт межзонная избыточность: балансировщик, который распределяет запросы между узлами в разных зонах «для отказоустойчивости», без настроенных affinity-правил может гонять трафик между зонами там, где вся цепочка обработки запроса могла бы уместиться в одной зоне.

Что проверить:

• Топологию сервисов: какие компоненты в каком регионе и зоне физически находятся, не разъехались ли связанные сервисы за последние месяцы.
• Настройки репликации баз данных и очередей — межрегиональная репликация часто настроена один раз и не пересматривается, даже когда исходная причина (например, временная миграция) неактуальна.
• Правила балансировки нагрузки на предмет ненужного межзонного трафика.
• Раздел биллинга с внутренним трафиком между сервисами и регионами — он часто скрыт глубже, чем исходящий трафик в интернет.

Отдельно о том, как вообще устроена оплата исходящего трафика и где она незаметно накручивается даже без миграции между регионами, — в статье «Плата за исходящий трафик: как её накрутить незаметно для себя».

Смена тарифов провайдера и превышение бесплатных лимитов

Не всегда причина в ваших ресурсах — иногда меняются условия на стороне провайдера. Тарифная политика периодически пересматривается: меняется цена за единицу ресурса, вводятся новые пороги, при которых прежде бесплатная функциональность становится платной, меняется сам способ тарификации сервиса (например, переход с оплаты за число запросов на оплату за время выполнения, что для одних нагрузок выгоднее, а для других заметно дороже). Такие изменения обычно анонсируются заранее в рассылках, но легко теряются среди прочих технических писем. О том, как безобидный на первый взгляд тариф превращается в дорогую подписку без явного предупреждения, — в статье «Скрытая цена "безлимитного" тарифа».

Второй вариант — вы сами подключили новый сервис в рамках бесплатного уровня (free tier), не рассчитав реальные объёмы. Бесплатные лимиты обычно рассчитаны на лёгкое или тестовое использование: определённое число запросов, объём хранения или вычислений в месяц. Если сервис — логирование, очередь сообщений, функцию по требованию — начали использовать всерьёз, легко незаметно перейти границу бесплатного уровня, и каждая следующая единица уже тарифицируется, причём первый платный порог у некоторых сервисов дороже последующих.

Что сделать:

• Проверить архив уведомлений от провайдера за последние два-три месяца на предмет изменения тарифов.
• Сверить список активных сервисов с историей их подключения — не появился ли новый сервис примерно в то время, когда начался рост.
• Для сервисов с бесплатным уровнем — явно посмотреть текущее потребление относительно лимита, а не полагаться, что «мы туда не дотягиваем».

Чек-лист диагностики и профилактика на будущее

Когда счёт вырос, а разбираться нужно быстро, полезно идти по проверенному порядку, а не хвататься за всё сразу:

Если после прохода по списку явная причина не нашлась — запросите у поддержки провайдера подробную детализацию по конкретным ресурсам за период: у крупных провайдеров она обычно доступна, просто не показывается в сводном интерфейсе по умолчанию.

Чтобы не попасть в ту же ситуацию через полгода: заведите регулярный, а не разовый аудит (15-20 минут раз в месяц по списку выше — почти всегда дешевле, чем потом разбираться задним числом за несколько месяцев роста); обязательные теги для всех ресурсов (назначение, ответственный, срок жизни); бюджетные оповещения при превышении заданного порога расходов за период; явные политики жизненного цикла для снапшотов, бэкапов и временных окружений — заданные как автоматическое правило, а не как устное «не забыть удалить».

Часть непредсказуемости облачного счёта — не ошибка эксплуатации, а особенность самой модели: цена складывается из десятка переменных величин, и даже при аккуратной эксплуатации точную сумму заранее предсказать сложно. Для нагрузок со стабильным профилем потребления, не требующих постоянного автомасштабирования, практическая альтернатива — собственный сервер известной конфигурации с фиксированной ежемесячной стоимостью, где заранее понятно, за что вы платите, без переменных статей вроде межзонного трафика или накопительной тарификации снапшотов.

Частые вопросы