Как сэкономить до 75% на виртуальных машинах: делаем FinOps в облаке

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

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

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

Используйте содержание, если не хотите читать текст полностью:

→ Обычная виртуальная машина

→ Прерываемая виртуальная машина

→ Примеры

→ Практика

→ Заключение

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

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

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

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

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

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

Здесь на помощь приходят резервные хосты, которые выполняют одновременно несколько функций.

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

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

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

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

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

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

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

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

Александр работает аналитиком данных и часто имеет дело с инструментами вроде Hadoop и Spark. Его задачи почти всегда требуют значительных вычислительных ресурсов.

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

Лариса работает с нейросетями. Основную часть времени занимают задачи по машинному обучению. Ей приходится активно использовать GPU‑ресурсы для тренировки моделей. Уровень затрат значительный, но снизить его не удавалось: отказаться от части машин — уронить скорость обучения до неприемлемого уровня. Руководство компании это понимало, но и выделить бюджет на аренду дополнительных машин не соглашалось. Однако Лариса узнала о прерываемых ВМ.

Благодаря Ларисе компания получила много дополнительных вычислительных ресурсов, которые были столь необходимы. При этом расходы на инфраструктуру уменьшились кратно.

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

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

Получить прерываемый сервер нетрудно: в панели управления достаточно поставить галочку в разделе Облачная платформа → Серверы → Дополнительные настройки.

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

Уведомление при выключении тоже не придет — если отслеживание момента вытеснения имеет значение, мониторинг доступности потребуется реализовать самостоятельно — например, с помощью shell‑скрипта, публичного API Selectel, сетевой проверки и так далее.

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

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

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

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

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

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

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

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

Возможно, вам также будет интересно: