Как подружить FinOps и облако? Прерываемые виртуальные машины

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

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

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

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

→ Обычная виртуальная машина
→ Прерываемая виртуальная машина
→ Примеры
→ Практика
→ Заключение

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

Как выглядят железные хосты виртуализации в Selectel.

Доступные конфигурации

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

• фиксированными — пользователь не может изменить ни предлагаемый набор компонентов, ни их количество;
• произвольными — в панели управления можно «накликать» любые ресурсы и объемы.

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

Примеров фиксированной конфигурации может быть много.

Помимо стандартных сочетаний RAM и CPU, востребованными оказываются линейки Shared Line с использованием только доли вычислительной мощности ядра и, наоборот, HighFreq Line с процессором до 3,6 ГГц и локальным диском от 30 до 960 ГБ.

Конечно, в эпоху больших данных и машинного обучения растет спрос на GPU Line с видеокартами T4, A2, A30, A100, A2000, A5000, RTX 2080 TI, RTX 4090.

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

Сравнение плотности утилизации ресурсов. Слева — при фиксированной конфигурации, справа — при произвольной.

Особенности облачной архитектуры

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

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

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

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

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

Оптимизация

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

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

Пример сравнения стоимости обычной и прерываемой ВМ при одинаковой конфигурации.

Особенности решения

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

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

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

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

Тестирование

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

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

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

— Олег, руководитель команды тестирования

Аналитика данных

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

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

Я просил руководство арендовать еще нескольких машин с большой оперативкой. Мы бы и текущую работу выполняли быстрее, и срочные задачи не конкурировали бы с запланированными. «Дополнительные машины по большей части будут простаивать, что вызовет ощутимую финансовую нагрузку», — так мне отвечали.

Прерываемые виртуальные машины оказались настоящей находкой.

В работе мы используем платформу Apache Spark. За управление отвечает Kubernetes. Драйверы размещаем на обычных виртуалках, а воркеры и экзекуторы — на прерываемых. Краткосрочная недоступность виртуальной машины не является проблемой для наших задач. Если какая ВМ оказалась выключена, задачи перераспределяются и выполнятся на других воркерах.

— Александр, аналитик данных

Машинное обучение

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

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

— Лариса, ведущий ML‑инженер

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

Периодические задачи

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

Когда я узнал, что можно арендовать ресурсы на короткое время, но под страхом внезапной остановки, то не сразу понял кому это нужно. Рассказал ребятам, чтобы посмеяться: какой‑нибудь интернет‑магазин то будет работать, то нет.

Виктор (работает DevOps‑инженером) сходу оценил идею и предложил схему. Данные и так хранятся на сетевом диске. Можно «прикрутить» Кубер — он сам будет перезапускать остановленные виртуалки, которые продолжат свою работу после рестарта.

Вот так и выяснил, что услуга нужна мне. Могу и расценки сделать более привлекательными, и по времени исполнения конкурентов опережать. А интернет‑магазинам, наверное, и правда ни к чему. Хотя теперь уже не уверен.

— Степан, начинающий инженер данных

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

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

Переключение виртуальной машины в режим прерываемой панели управления Selectel.

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

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

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

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

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

Настройка автовосстановления в панели управления Selectel.

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

Прерываемая ВМ в Kubernetes.

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

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

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

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

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

• Статья: «Как подобрать конфигурацию ML-системы и повысить ее утилизацию»
• Документация: «Создать прерываемый облачный сервер»