Модуль Terraform для AWS Spot Instance: как настроить и сэкономить на ресурсах

В предыдущей статье мы вместе с инженером по облачным сервисам и архитектором AWS Владимиром Самойловым разбирались, что такое Spot Instance от Amazon Web Services (AWS) и как можно бороться с прерываниями.

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

В Terraform-модуле есть несколько вариантов поведения, которые могут быть полезны:

• spot_price_current_min — хотя бы один Instance Type в хотя бы одной AZ;
• spot_price_current_optimal — хотя бы один Instance Type во всех AZ;
• spot_price_current_max — все Instance Type во всех AZ;
• spot_price_current_max_mod — все Instance Type во всех AZ с повышенной надежностью.

Пройдемся по ним от простого к сложному на примере матрицы цен:

Сначала получим текущий spot_price без открытия UI и Spot price history, это самый простой пример:

Видим, что достаточно передать всего лишь одну зону доступности, один тип инстанса и получить результат. Ответ здесь будет 0,20, потому что мы передали только r5 и только зону доступности 1a.

Минимальная цена

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

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

Смотря в нашу таблицу, мы увидим, что в зоне доступности 1b есть только один инстанс типа r5a с минимальной ценой 0,10. В процессе изменения цен вы каждый раз будете получать самую минимальную цену. Например, если в одной зоне доступности начала расти цена, то при следующем Terraform apply вы получите следующую минимальную цену, допустим, из другой зоны доступности. Конечно, такое поведение вызовет самые частые прерывания, и если цена хотя бы немного вырастет, то вы сразу лишитесь этого инстанса.

Поэтому такое поведение не очень эффективно, и лучше поискать оптимальный баланс между ценой и доступностью.

Оптимальная цена

Это поведение дает возможность запустить хотя бы один Instance Type во всех зонах доступности, что избавит вас от проблемы с определением какой Instance Type выгоднее: t3, t3a, c5 или какой-то из r. При изменении цен будет переключение на самые выгодные типы инстансов для каждой зоны доступности, а в случае повышения цен вы будете терять зоны доступности по одной, как и в случае их отключения. Вернувшись к таблице, видим намного больше вариантов:

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

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

Максимальная текущая цена

При таком поведении могут быть запущены все типы инстансов во всех зонах доступности. Это решит проблему отсутствия Spot Instance за счет определения цены для разных типов. Также такое поведение допускает большую задержку между Terraform apply, и их можно будет запускать реже. Это особенно удобно, если модуль запускается где-то вручную, а не в CI/CD.

Судя по таблице, в этом случае может быть запущен любой Instance Type в любой AZ, потому что ни один из них не превышает максимальную цену. Это значит, что если вы запустите r5 в 1a, который стоит 0,20, то будете платить эту цену вплоть до ее повышения до 0,30. Такое поведение позволяет не зависеть от типов инстансов и зон доступности. Если добавить много типов инстансов, то можно покрыть вообще все кейсы и быть всегда со спотами.

Модифицированная цена

На случай, если нужно еще больше стабильности, и вы готовы иногда доплачивать за это на 5-10% больше, есть поведение spot_price_current_max_mod:

Это поведение снижает вероятность прерывания из-за незначительных колебаний цены и поможет если Terraform запускается очень-очень редко или в ручном режиме. Вы сможете заранее указать, что готовы платить, например, плюс 10% к текущей цене, то есть 0,33 вместо 0,30. Это небольшая переплата за снижение прерываний.

Но стоить помнить, что переплата сильно зависит от количества инстансов, которые вы используете. Разница в +2 цента может вылиться в 14$ за месяц на каждый EC2 Instance, а если их 100 — превратиться в 1400$. Поэтому просчитывайте, стоит ли того снижение вероятности прерываний. Если вы все-таки считаете, что стоит, то через custom price modifier это поведение можно применить ко всем другим сценариям.

Области применения EC2 Spot Price-модуля

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

Если у вас есть ECS Capacity провайдер, EKS-worker ноды, GitLab runners, любая нагрузка, которую можно прервать, билд-машины, побочные вещи мониторинга, DevTest окружение — их можно запускать полностью на спотах. Если в ECS использовать специальный флаг ECS_ENABLE_SPOT_INSTANCE_DRAINING или для EKS применять EKS Node Termination Handler, то можно запускать даже продакшн. Есть примеры, когда он целиком работает на спотах.

Но более типичные примеры — когда запускают один-два ondemand инстанса на случай, если у вас всё заберут. А всё, что скейлится, отправляют на споты, потому что неизвестно какая будет нагрузка и ничего нельзя заранее купить.

Полезные ссылки по теме:

https://aws.amazon.com/ru/ec2/spot/instance-advisor/ https://ec2spotworkshops.com/ https://github.com/awslabs/ec2-spot-labs/ https://github.com/aws/aws-node-termination-handler https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-spot.html

Видео выступления Владимира Самойлова на DevopsConf 2021.

13 и 14 июня пройдет объединенная конференция DevOpsConf 2022 и TechLead Conf 2022. Место проведения — кампус Сколково, самая инновационная и технологичная площадка в Москве.

Обсудим инженерные процессы в IT от XP до DevOps & Beyond, must have инструменты и практики изменений в командах для быстрых и качественных релизов. Программа практически сформирована. Билеты можно купить здесь.

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