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

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

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

Именно эту проблему мы и рассмотрим в данной статье.

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

Простая vs. сложная автоматизация облачной инфраструктуры

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

Простой сценарий автоматизации облака — это сценарий, в котором верны следующие условия:

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

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

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

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

Недостаточная автоматизация означает перерасход средств

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

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

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

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

Нюансированный подход к комплексным потребностям автоматизации облака

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

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

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

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

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

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

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

Заключение: новый уровень автоматизации облачных вычислений

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

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