Как правильно подобрать объём облачных ресурсов после стабилизации трафика

Почему счета за облако остаются высокими после остановки роста

Счета за облако редко падают сами по себе. Трафик спадает после запуска, распродажи или платной кампании, но инфраструктура часто остаётся рассчитанной на самый загруженный день.

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

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

Старые прогнозы формируют расходы задолго до того, как изменилась реальность. Финансы могут до сих пор работать по модели роста прошлого квартала. Инженеры планируют по пиковой неделе запуска. Закупки могли подписать зарезервированную ёмкость или годовые контракты, исходя из тех предположений. Компания продолжает платить за спрос, которого больше нет.

Большая часть трат не выглядит драматично на дашборде. Она выглядит нормально. Вычисления остаются рассчитанными на короткие пики. Простаивающие сервисы продолжают работать после завершения экспериментов. Ёмкость базы данных всё ещё отражает старые нагрузочные тесты. Зарезервированные расходы соответствуют целям роста, которых компания не достигла.

Простой пример это проясняет. Стартап получает всплеск трафика после запуска, удваивает количество серверов приложений, апгрейдит базу данных и добавляет узел кэша. Через два месяца ежедневное использование стабилизируется на половине пика, но месячный счёт едва меняется. Ничего не сломано, поэтому никто не чувствует давления действовать. Компания продолжает платить за запас, который ей больше не нужен.

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

Где чаще всего прячется расточительство

Расточительство редко сидит в одном большом и очевидном месте. Оно накапливается в тихих уголках стека после того, как суета уходит.

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

Стейджинг-системы тратят деньги очень обычным образом. Многие команды держат полные копии продакшна круглосуточно, хотя ими пользуются всего несколько часов в будние дни. База данных для стейджинга, кэш, сервер приложений, воркер и балансировщик нагрузки превращаются во второй продакшн-счёт без какого-либо планирования.

Старое хранилище набегает быстрее, чем думают. Снимки (snapshots) остаются после миграций. Отключённые диски остаются после тестов. Неиспользуемые IP-адреса продолжают начислять плату, потому что никто их не освободил. Каждая строка счёта выглядит маленькой, поэтому она переживает каждый ежемесячный обзор.

Логи тоже требуют внимания. Легко хранить 30, 90 или 180 дней логов, потому что это кажется безопасным. На практике команды часто читают последние часы при инциденте, может быть неделю при расследовании, и почти никогда не касаются остального. Большой объём логов плюс длительное хранение могут стоить дороже, чем фича, которая эти логи и породила.

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

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

Начните с ресурсов, созданных для более занятой версии компании. Там обычно сидят самые простые для получения экономии места.

Как проверить текущее использование

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

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

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

Обычная таблица в Spreadsheet обычно работает лучше, чем красивый дашборд. Для каждого крупного элемента укажите, что он делает, работает ли постоянно или по расписанию, сколько стоит в месяц и кто за него отвечает.

Владение важнее, чем многие ожидают. Когда у строки расходов нет владельца, она, как правило, живёт вечно. Старые тестовые кластеры, переувеличенные стейджинг-настройки и забытые плагины мониторинга часто остаются из‑за отсутствия ответственности за их удаление.

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

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

Как перепроверить пиковые паттерны

Используйте два окна времени: вашу самую загруженную неделю запуска и последние два‑три обычных месяца. Поставьте графики рядом. Смотрите трафик, CPU, память, нагрузку на базу, глубину очередей и пропускную способность вместе. Один график в отрыве может ввести в заблуждение.

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

Пик важен только если реальные клиенты его вызвали и если он повторяется. Отделяйте нормальный спрос от разовых событий: запуск продукта, маркетинговая рассылка, миграция, всплеск краулера, нагрузочное тестирование или зацикленная задача. Эти события могут повысить использование на несколько часов и заставить вас платить за них месяцами.

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

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

Держите буфер, но небольшой. Всё ещё нужна возможность выдержать акции, внезапное упоминание и краткие инциденты. Во многих случаях 15–25 процентов запаса достаточно. Больше — обычно плата за тревогу.

Если новый паттерн держится ниже в течение полного квартала, вы можете уверенно менять размеры.

Простой пример после пикa запуска

SaaS‑компания имела сильный месяц запуска. Регистрации выросли, тикетов поддержки стало больше, и команда быстро масштабировала стек, чтобы приложение оставалось стабильным под нагрузкой.

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

К тому времени трафик стабилизировался в ровном будничном ритме. Большинство пользователей заходило в рабочие часы, ночью активность падала, а по выходным было тихо. Компания всё ещё платила за ёмкость уровня запуска каждый день.

Короткий обзор сделал проблему очевидной. За 30 дней слой приложения был самой явной проблемой. Восемь серверов работали весь день, но обычный будний трафик чаще всего требовал четырёх серверов и шести в короткие полуденные пики. Два лишних сервера едва набирали загрузку выше низких однозначных процентов. Они были там «на всякий случай», но этот случай почти не случался.

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

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

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

Обычно работа идёт так: начните со слоя с избыточным ресурсом, который легко измерить, легко уменьшить и легко откатить, если вы ошиблись.

Как решить, с чего начать

Не начинайте с редизайна. Начните с очевидного: того, что легко заметить, дешево починить и просто отменить. Такой порядок обычно быстро сокращает расходы без риска для доступности.

Самые безопасные изменения — вне пути клиента. Кластер стейджинга, который работает весь уикенд; старый поисковый узел, по которому никто не делает запросов; забытый GPU‑инстанс из теста — всё это ежедневно тратит деньги. Выключите это прежде, чем менять продакшн‑базы, сетевые настройки или правила масштабирования.

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

Плановые отключения часто дают самый быстрый выигрыш. Если ваши разработчики работают с понедельника по пятницу, полная QA‑среда не обязана работать 24/7. Даже базовое расписание может сократить этот счёт вдвое или больше.

Изменения в базе данных и хранилище требуют больше осторожности. Меньше дисков, меньше реплик или более низкий уровень БД могут реально сэкономить, но также замедлить приложение или усложнить восстановление, если вы торопитесь. Сделайте снимок, определите, что значит «откат», и меняйте по одной вещи за раз. Если задержки растут или ошибки увеличиваются, быстро откатитесь.

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

Хорошее правило простое: сначала урежьте то, что можно отменить за минуты, прежде чем трогать то, что трудно вернуть.

Ошибки, которые создают новые проблемы

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

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

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

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

Зарезервированные расходы тоже подводят команды. Кто‑то видит неиспользуемые обязательства и быстро их отменяет, а потом узнаёт, что возврата нет или что другие рабочие нагрузки теперь работают по дорогим on‑demand тарифам. Проверьте даты окончания, условия выставления счетов и реальную стоимость замены, прежде чем трогать обязательство.

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

Пользуйтесь скучным правилом: сделайте одно изменение, наблюдайте полный цикл использования и запишите, что изменилось. Сэкономить 15 процентов — это не победа, если фиксация ломает восстановление или создаёт два дня уборки.

Короткий чек‑лист перед изменениями

Плато трафика меняет математику. Серверы, базы и зарезервированные обязательства, которые имели смысл во время запуска, могут месяцами простаивать наполовину загруженные. Прежде чем менять любой размер, убедитесь, что вы рассчитываете под текущее спрос, а не под пик, который вряд ли вернётся.

Начните с ваших предположений. Посмотрите последние 30, 60 и 90 дней, затем сравните их с вашим самым загруженным прошлым периодом. Если рост выровнялся, берите за основу более спокойный тренд. Если вы всё ещё ожидаете сезонный подъём, включите его в модель и объясните почему.

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

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

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

Если команда не может ответить, кто владеет изменением, как его отменить и какой сигнал докажет успех — подождите день и заполните эти пробелы.

Что делать, если цифры всё ещё кажутся неверными

Если счёт всё ещё кажется слишком высоким после уборки, не гоняйтесь за мелкими строками. Откройте счёт и отчёты по использованию, а затем сосредоточьтесь на трёх крупнейших статьях расходов. В большинстве компаний это вычисления, базы данных и сеть или хранение. Сокращение на 15 процентов в одной большой области важнее удаления десяти мелких сервисов.

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

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

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

Если нужен внешний взгляд, Олег Сотников из oleg.is работает со стартапами и малыми компаниями по вопросам облачных расходов, инфраструктуры и роли Fractional CTO. Полезная часть не в большом редизайне: это практический разбор счёта, контрактов и архитектуры вместе.

Начните с вашей самой большой статьи расходов, назначьте одного владельца и решите, какого результата вы ждёте к концу второго биллингового цикла.