6 неочевидных причин завышенной стоимости облака

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

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

Разберём 6 неочевидных причин, из-за которых облачные счета продолжают расти, и покажем, почему «меньше нагрузки» не равно «меньше расходов».

Остаточные ресурсы, которые никто не учитывает

Первая, самая распространённая и самая явная причина — оплата простаивающих ресурсов. Как правило, это: 

• неиспользуемые диски;
• старые снапшоты;
• резервные IP-адреса;
• временные ресурсы, созданные «на время»;
• тестовые окружения, которые забыли выключить.

Проблема в том, что такие ресурсы:

• не влияют на производительность;
• не отображаются в метриках нагрузки;
• редко проверяются вручную.

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

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

Хранилище дорожает быстрее, чем вычисления

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

• данные копятся быстрее, чем удаляются;
• используются дорогие storage-классы «по умолчанию»;
• снапшоты хранятся годами;
• нет политики жизненного цикла данных.

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

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

Сетевые расходы не зависят от числа пользователей напрямую

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

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

К счастью, некоторые провайдеры (и мы среди них!) не тарифицируют ни внутренний, ни внешний трафик. Выберите себе такого провайдера — и контролировать нужно будет меньшее число статей расходов.

Резервирование «на всякий случай» не уменьшается само

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

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

• фактическая загрузка падает или не растёт до расчётного уровня;
• архитектура остаётся прежней;
• стоимость инфраструктуры не меняется.

И вот облако было нормальным по цене, а теперь становится дорогим. Но не потому, что нагрузка выросла, а потому что архитектура не адаптировалась к нагрузке. 

Managed-сервисы незаметно увеличивают стоимость

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

• Иногда переход на более дорогие тарифы совершается автоматически.
• Стоимость SLA и поддержки может увеличиться без извещения.
• Платные функции могут включаться «по умолчанию».
• Оплата происходит за операции, а не за нагрузку.

Со снижением нагрузки логично ожидать уменьшения цены. А managed-сервис может продолжать работать в прежнем режиме, а то и добавлять в тариф новые статьи расходов.

Операционные расходы не уменьшаются вместе с инфраструктурой

Последняя, но часто самая дорогая причина — операционные издержки. Сюда входят:

• поддержка сложной архитектуры;
• время инженеров;
• сопровождение CI/CD;
• реагирование на инциденты;
• взаимодействие с провайдерами и подрядчиками.

Даже если инфраструктура стала использоваться меньше, её сложность остаётся прежней. А сложность — это деньги. В результате стоимость облака может снизиться меньше ожидаемого, хотя бизнес-нагрузка существенно сократилась.

Корень проблем и решения

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

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

Ну а снижать вручную — это чаще вовсе не снижать, чем снижать как следует. Так что можем рекомендовать системный подход:

1. Регулярный аудит ресурсов и хранилища.
2. Политики жизненного цикла данных и логов.
3. Пересмотр резервирования под текущий масштаб бизнеса.
4. Контроль managed-сервисов и их тарифов.
5. Упрощение архитектуры там, где рост больше не ожидается.

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

Заключение

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

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