NatalyClassic
New member
Полтора года назад я открыл очередной инвойс от облачного провайдера и честно замер: сумма выросла почти втрое за год, хотя нагрузка выросла процентов на тридцать. Никакой катастрофы не случилось, релизы выходили, метрики были зелёными, но каждый месяц я платил всё больше и больше и не мог внятно объяснить, за что именно. Тогда я решил, что хватит жить по принципу «работает — не трогай», и затеял ревизию. Через два месяца счёт стал меньше на сорок один процент, а производительность не просто не упала — в паре мест стала лучше. Расскажу, как это было и что из этого может повторить любой, у кого есть хоть какой-то продакшн в облаке.
Первым делом я перестал спорить с графиками и занялся тегами. Оказалось, что больше половины ресурсов не имела ни одного тега, а значит, я не мог ответить на простейший вопрос: какая команда и какой продукт тянет деньги. Мы потратили неделю на инвентаризацию и пометили всё: окружение, владельца, продукт, критичность. Именно этот шаг дал самый большой эффект, потому что дальше разговор из эмоционального «нам надо экономить» превратился в конкретный: «вот этот кластер в деве съедает восемнадцать процентов бюджета, и он никому не нужен по выходным». Без тегов любая оптимизация превращается в гадание на кофейной гуще, так что совет номер один — начните с учёта, а не с резервирований.
Дальше я взялся за размеры инстансов. Классическая история: сервис стартовал три года назад на четырёхъядерной машине, разработчики с тех пор переписали половину кода, а инстанс так и остался прежним. Я собрал статистику по реальному потреблению процессора, памяти и диска за месяц и обнаружил, что почти везде утилизация держится в районе десяти-пятнадцати процентов. Мы уменьшили размеры там, где был запас, и выиграли сразу около двенадцати процентов бюджета. Никакой магии: если утилизация памяти стабильно ниже сорока процентов, а пики короткие, инстанс почти наверняка переразмерен. Единственное, от чего я предостерегу: не режьте размеры по среднему значению, смотрите на девяносто пятый перцентиль и на пиковые часы, иначе получите красивую экономию и ночные инциденты.
Отдельная песня — нерабочие окружения. У нас были стенды для разработки, тестирования и демо, которые жили круглосуточно и круглогодично, хотя реально использовались в рабочие часы. Мы настроили расписание: ночью и по выходным среда гасится, базы переводятся в более дешёвый режим, а утром всё поднимается автоматически. Это дало ещё примерно восемь процентов и почти ноль рисков, потому что продакшна изменения не касались вовсе. Заодно мы вычистили мусор: осиротевшие диски, старые снапшоты, забытые балансировщики, тестовые базы, оставшиеся после ушедших сотрудников. Мой любимый случай — снапшоты трёхлетней давности, которые хранились «на всякий случай» и стоили как приличный сервер.
Следующий пласт — тарифная политика и типы инстансов. Продакшн с предсказуемой нагрузкой мы перевели на долгосрочные обязательства, а пакетную обработку, рендеринг отчётов и ночные джобы — на прерываемые машины, которые стоят в разы дешевле. Тут важна честность с самим собой: если сервис не умеет переживать внезапное выключение узла, прерываемые инстансы превратятся в источник седых волос. Мы потратили две недели на идемпотентность и ретраи, и это окупилось с лихвой. Плюс мы перестали держать переизбыточную репликацию в горячем хранилище и настроили жизненный цикл: старые логи и бэкапы уезжают в холодный класс хранения, где стоят в разы меньше.
И ещё один пункт, который обычно недооценивают, — сеть и архитектура. У нас оказалось прилично трафика между зонами доступности и наружу, а это те самые строки в счёте, которые никто никогда не читает. Мы добавили кэширование на границе, убрали лишние обращения к внешним сервисам из горячего пути, переписали часть внутренних вызовов так, чтобы данные не гонялись туда-сюда между зонами, и включили сжатие там, где это имело смысл. Мелочь на первый взгляд, но в сумме набежало около семи процентов. Экономия в облаке почти всегда складывается из десятка небольших решений, а не из одного героического хода.
Самое важное, что я вынес: экономия без наблюдаемости превращается в авантюру. Мы поставили алерты на аномальный рост потребления, ежемесячный отчёт по тегам и короткий ритуал — тридцать минут раз в две недели, где команда смотрит на свой счёт и решает, что можно улучшить. Звучит скучно, но именно эта привычка не даёт бюджету снова расползтись, как тесто на тёплой кухне. Плюс я перестал бояться разговаривать с провайдером: иногда там есть скидки, программы поддержки стартапов или более выгодные тарифы, о которых вы просто не знаете.
В итоге мы получили минус сорок один процент к счёту, более предсказуемые расходы и, что приятно, чуть более быстрые ответы сервисов за счёт меньшего числа лишних прыжков по сети. Никого не уволили, ни один релиз не сдвинули, архитектуру не переписывали с нуля. Если хотите повторить, начните с тегов и инвентаризации, посмотрите на реальную утилизацию, выключите то, что не нужно ночью, и только потом идите в резервирования и прерываемые инстансы. А теперь расскажите: какой самый неожиданный источник расходов вы находили в своём облаке и что помогло вам его приручить? Буду рад поучиться у сообщества — уверен, у вас есть истории не хуже моих.
Первым делом я перестал спорить с графиками и занялся тегами. Оказалось, что больше половины ресурсов не имела ни одного тега, а значит, я не мог ответить на простейший вопрос: какая команда и какой продукт тянет деньги. Мы потратили неделю на инвентаризацию и пометили всё: окружение, владельца, продукт, критичность. Именно этот шаг дал самый большой эффект, потому что дальше разговор из эмоционального «нам надо экономить» превратился в конкретный: «вот этот кластер в деве съедает восемнадцать процентов бюджета, и он никому не нужен по выходным». Без тегов любая оптимизация превращается в гадание на кофейной гуще, так что совет номер один — начните с учёта, а не с резервирований.
Дальше я взялся за размеры инстансов. Классическая история: сервис стартовал три года назад на четырёхъядерной машине, разработчики с тех пор переписали половину кода, а инстанс так и остался прежним. Я собрал статистику по реальному потреблению процессора, памяти и диска за месяц и обнаружил, что почти везде утилизация держится в районе десяти-пятнадцати процентов. Мы уменьшили размеры там, где был запас, и выиграли сразу около двенадцати процентов бюджета. Никакой магии: если утилизация памяти стабильно ниже сорока процентов, а пики короткие, инстанс почти наверняка переразмерен. Единственное, от чего я предостерегу: не режьте размеры по среднему значению, смотрите на девяносто пятый перцентиль и на пиковые часы, иначе получите красивую экономию и ночные инциденты.
Отдельная песня — нерабочие окружения. У нас были стенды для разработки, тестирования и демо, которые жили круглосуточно и круглогодично, хотя реально использовались в рабочие часы. Мы настроили расписание: ночью и по выходным среда гасится, базы переводятся в более дешёвый режим, а утром всё поднимается автоматически. Это дало ещё примерно восемь процентов и почти ноль рисков, потому что продакшна изменения не касались вовсе. Заодно мы вычистили мусор: осиротевшие диски, старые снапшоты, забытые балансировщики, тестовые базы, оставшиеся после ушедших сотрудников. Мой любимый случай — снапшоты трёхлетней давности, которые хранились «на всякий случай» и стоили как приличный сервер.
Следующий пласт — тарифная политика и типы инстансов. Продакшн с предсказуемой нагрузкой мы перевели на долгосрочные обязательства, а пакетную обработку, рендеринг отчётов и ночные джобы — на прерываемые машины, которые стоят в разы дешевле. Тут важна честность с самим собой: если сервис не умеет переживать внезапное выключение узла, прерываемые инстансы превратятся в источник седых волос. Мы потратили две недели на идемпотентность и ретраи, и это окупилось с лихвой. Плюс мы перестали держать переизбыточную репликацию в горячем хранилище и настроили жизненный цикл: старые логи и бэкапы уезжают в холодный класс хранения, где стоят в разы меньше.
И ещё один пункт, который обычно недооценивают, — сеть и архитектура. У нас оказалось прилично трафика между зонами доступности и наружу, а это те самые строки в счёте, которые никто никогда не читает. Мы добавили кэширование на границе, убрали лишние обращения к внешним сервисам из горячего пути, переписали часть внутренних вызовов так, чтобы данные не гонялись туда-сюда между зонами, и включили сжатие там, где это имело смысл. Мелочь на первый взгляд, но в сумме набежало около семи процентов. Экономия в облаке почти всегда складывается из десятка небольших решений, а не из одного героического хода.
Самое важное, что я вынес: экономия без наблюдаемости превращается в авантюру. Мы поставили алерты на аномальный рост потребления, ежемесячный отчёт по тегам и короткий ритуал — тридцать минут раз в две недели, где команда смотрит на свой счёт и решает, что можно улучшить. Звучит скучно, но именно эта привычка не даёт бюджету снова расползтись, как тесто на тёплой кухне. Плюс я перестал бояться разговаривать с провайдером: иногда там есть скидки, программы поддержки стартапов или более выгодные тарифы, о которых вы просто не знаете.
В итоге мы получили минус сорок один процент к счёту, более предсказуемые расходы и, что приятно, чуть более быстрые ответы сервисов за счёт меньшего числа лишних прыжков по сети. Никого не уволили, ни один релиз не сдвинули, архитектуру не переписывали с нуля. Если хотите повторить, начните с тегов и инвентаризации, посмотрите на реальную утилизацию, выключите то, что не нужно ночью, и только потом идите в резервирования и прерываемые инстансы. А теперь расскажите: какой самый неожиданный источник расходов вы находили в своём облаке и что помогло вам его приручить? Буду рад поучиться у сообщества — уверен, у вас есть истории не хуже моих.