Избегайте распыления всего вашего облачного бюджета

Легко пришло, легко ушло.

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

#1 Неожиданное потребление

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

Вот несколько распространенных ошибок, которых следует избегать:

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

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

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

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

#2 Случайный выбор самой дорогой ВМ

«Меня не волнует, сколько это будет стоить, нам нужно быстро масштабировать. Дайте мне самую большую виртуальную машину, которая у них есть».

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

Хорошо, босс. В зависимости от того, с каким облачным провайдером вы работаете, эта «самая большая» виртуальная машина будет выглядеть так:

• AWS: 448,00 виртуальных ЦП, 6144,00 ГБ, 1310 долларов США в день

• GCP: 224,00 виртуальных ЦП, 896,00 ГБ, 62 доллара США в день

• Azure: 416,00 виртуальных ЦП, 5700,00 ГБ, 1190 долларов США в день.

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

:::Информация

Цены актуальны на момент написания статьи.

#3 Утечка учетных данных вашей учетной записи администратора

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

#4 Чрезмерная составляющая

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

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

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

#5 Взрыв из прошлого - Инстансы, ставшие неиспользованными незамеченными

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

Звучит знакомо? Спустя годы вы натыкаетесь на некоторые экземпляры и задаетесь вопросом, для чего они использовались?

Отменить зависимость службы в коде довольно просто. Просто используйте v2 вместо v1 в URL-адресе API. Однако процесс вывода из эксплуатации, который позаботится об устаревших экземплярах службы, редко встречается в организации. И каждый инстанс, подключенный к сети в облаке, стоит и берет часть вашего облачного бюджета, независимо от того, используется инстанс для чего-то значимого или нет.

Мои рекомендации по решению этой проблемы следующие:

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

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

1. Будьте смелее и выводите из эксплуатации то, что больше не нужно.

#6 Отсутствие активного управления размерами экземпляров

Для используемого приложения вполне нормально иметь взлеты и падения в его использовании с точки зрения 1 года. Например, интернет-магазин обычно имеет примерно одинаковую загрузку в течение всего года, но испытывает сильные пики во время особых событий, таких как рождественские распродажи или распродажи в Черную пятницу.

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

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

У всех основных облачных провайдеров есть решения именно для этой проблемы.

В AWS они называются группы автоматического масштабирования (ASG), в Azure масштабируемые наборы виртуальных машин, а в GCP группы управляемых экземпляров (MIG). У них разные имена, но они делают одно и то же. Масштабируйте группу одинаково настроенных экземпляров на основе события. Событие может быть простым, как расписание, или чем-то более сложным, как метрика, такая как загрузка ЦП, среднее использование сети или количество запросов. Некоторые поставщики облачных услуг также позволяют вам настраивать пользовательские показатели, которые лучше подходят для вашего приложения.

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

#7 Опечатка автомасштабирования

Это полусерьезно. Представьте, что вы установили свою группу автомасштабирования минимум на 1 и максимум на 5. Однако вы не заметили, что набрали 55 вместо 5. И тогда действительно возникнет пик нагрузки. Однако вместо распродажи в Черную пятницу, которая приносила бы доход, это была бы DDoS-атака. Ваши 55 инстансов смело защитят вас от DDoS-атаки, но жертвой станет ваш облачный бюджет. Вы также не заметите DDoS, потому что ваши 55 экземпляров покроют вас.

#8 Хранение серверов сборки в горячем резерве

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

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

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

Чао!

:::Информация

Данные о ценах были взяты с нашего веб-сайта на момент написания статьи.