Оптимизируем расходы на Amazon AWS

Прайсинг в Amazon AWS устроен так, что разобраться в ипотеке от сбербанка проще, чем понять куда ежемесячно уходят ваши доллары. Почасовая оплата, разные цены для разных availability zones, burst performance, reserved instances, spot instances, плата за трафик, хранение, передачу данных… Я потратил несколько дней, чтобы в этом разобраться. А тут поделюсь результатами.

Для кого это всё

По своему опыту, я выделяю 5 уровней людей, использующих AWS:

1. Так, сейчас быстро запустимся (или переедем от другого хостера) — потом разберёмся
2. Что-то разбираться некогда, вроде и не дорого получается
3. Блин, а чё как дорого?
4. Ладно, пора в этом разобраться
5. О, теперь нормально
6. Опять дорого( Ладно наймём экспертов, пусть всё порешают

Пост будет максимально полезным для вас, если вы на уровне 3 или 4.

Предварительный анализ

Для начала, попробуем разобраться, сколько и за что мы платим сейчас. Для этого идём в Cost Explorer — выбираем период за последние полгода и группируем по сервисам. У нас получилась примерно такая картина:

Будем стараться снизить траты в столбцах ec2-instances, rds и elasticache — везде можно использовать одинаковые подходы. Приятный бонус – понизив общий ценник мы так же уменьшим и столбец tax.

Сразу оговорюсь, что способы типа «сейчас мы весь трафик с этого пятидесятиядерного облака перенесём в кластер из rasberry pi в офисе и сэкономим 500к/сек» рассматривать не будем — оптимизируем только расходы, не уменьшая ресурсы.

Для начала разберёмся в биллинге за инстансы.

On Demand Instance

Самый простой тип оплаты. У нас есть гарантированный доступ к инстансу и мы делаем с ним всё, что хотим. При этом мы ничего не обещаем — можем отключить его в любой момент и забыть. За такие условия мы и платим дороже всего. Наверняка если вы не углублялись в прайсинг AWS — у вас используются именно такие инстансы.

Reserved Instance

Тут всё почти как у On Demand, но обязательства есть не только со стороны Amazon, но и с нашей — мы договариваемся, что будем платить за определённый тип инстанса в течение фиксированного промежутка времени, обычно это 1 или 3 года. При этом мы можем просто договориться с AWS и платить по скидочному тарифу каждый месяц, а можем внести предоплату — частичную или полную за весь срок. Чем дольше срок и больше предоплата — тем больше скидка.

Reserved instance можно купить не только у AWS, но и у других компаний-реселлеров — интерфейс для покупки используется один.

Так же есть 2 offering class для reserved инстансов. От класса зависит то, какие атрибуты мы можем менять у инстансов:

Как обычно у AWS о̵ч̵е̵н̵ь̵ ̵и̵н̵т̵е̵р̵е̵с̵н̵о̵,̵ ̵н̵о̵ ̵н̵и̵х̵е̵р̵а̵ ̵н̵е̵п̵о̵н̵я̵т̵н̵о̵ много деталей, поэтому всё упростим. Будем говорить только про standard reserved instances, распростаняемые самим AWS с договором на год без предоплаты. В среднем скидка при такой конфигурации составляет примерно 30–40% от on demand.

За всеми деталями сюда.

Важно понимать, что reserved instance — это не конкретный инстанс. Если вы хотите перенести существующий on demand в reserved — не нужно будет проводить миграцию, мы просто «подписываем соглашение» с amazon: с сегодняшнего дня в течение года мы будем использовать инстанс типа, например, m5.large. Амазон выберет один инстанс этого типа из всех запущенных и выставлять счёт за него будет по новой схеме.

Spot Instance

Spot instance — инстансы без гарантии. AWS в любой момент может прийти и сказать «так, собирай свои манатки и проваливай, у тебя 2 минуты». И через 2 минуты инстанса у нас не будет — за это время мы можем что-то сделать. Сложный вариант: автоматизация с запуском других инстансов, простой — прислать в слак сообщение «я выключаюсь, решайте сами, что будете делать с этой информацией». За такие неудобства нам идут на уступки— цены даже ниже, чем reserved на 3 года с предоплатой. Можно экономить 60–90% от on demand.

И снова детали: работают spot-инстансы по принципу аукциона и цена на них не фиксированная. Мы говорим, сколько мы готовы платить максимально, а AWS уже решает, кому предоставить вычислительные мощности. При этом принцип выбора цены в сторону покупателя — если мы готовы платить 0.1$ в час, а рыночная цена — 0.05$, то платить мы будем именно 0.05$.

Хотите автоматизировать работу со спот-инстансами? Вот хорошая статья для старта.

Буквы, цифры, размеры футболок

Следующий момент, который нужно понимать для правильного выбора инстанса — их именование и различия типов. Все инстансы именуются по правилу <type><generation>.<size>:

• size — small, medium large, etc. От размера зависит количество vCPU и памяти. Подбирать нужно под ваше приложение
• generation — всё как с айфоном. Чем выше — тем лучше. Разница только в том, что за апгрейд мы обычно не доплачиваем: просто переходим на новое поколение и либо платим меньше, либо столько же, но получаем бонус. Например +1 vCPU при апдейте с t2.small на t3.small или -22$/m с cache.m3.large на cache.m5.large.
• type — тут начинается зоопарк, в котором стоит разобраться.

У каждого типа свои особенности, на которые стоит обращать внимание при выборе и цена, относительно других типов — разберём самые распространённые. Для сравнения добавлю текущую цену за инстанс c 2 vCPU.

• a — инстансы с arm-архитектурой. Дешевые, но ARM-архитектура часто не подходит, например если вы используете какие-то компилируемые библиотеки. $37.23/m (a1.large)
• t — инстансы с «повышаемой производительностью» (ниже чуть больше про них). $30.368/m (t3.medium)
• ta — burstable performance (как в t) + процессор amd. Самые дешевые — $27.448/m (t3a.medium)
• c — cpu optimized. $62.05/m (c5.large)
• m — инстансы для «общих целей». Памяти побольше, чем в c. $70.08/m (m5.large)
• cn — как c + чуть больше памяти (но меньше, чем в m) + повышенная пропусная способность сети (100 гигабит). $78.84/m (c5n.large)

Среди этих типов выделяется t, т.к. он сильно дешевле. Хитрость в том, что он работает по схеме cpu-кредитов. Пример: если ядро инстанса t3.medium утилизирует менее 20% CPU (“baseline performance”), он копит cpu-кредиты (и может скопить максимум 576). Как только это значение будет выше 20% — он начнёт потреблять накопленные кредиты. Когда дойдёт до 0 — мы будем платить дополнительно. Подробнее.

Детальный анализ

Ок, в прайсинге и типах разобрались — время генерить гипотезы, как мы можем экономить. Как обычно, для гипотез нам нужна аналитика. Создаём вот такую таблицу (можно использовать как шаблон) куда забиваем информацию про каждый наш запущенный инстанс. Да, тут придётся немного поработать руками, зато примерно за 15–20 минут можно получить общую картинку того, как мы используем ресурсы AWS.

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

Добавляем:

• название
• тип
• spot или обычный?
• сколько платим сейчас?
• CPU utilization — лучше в разбивке дня и последних двух недель
• Рекомендация и прогноз цены. Про алгоритм ниже

Подбор инстанса

Почти на всех проектах у нас похожие схемы: может быть один или несколько веб-инстансов за лоад балансером (ALB), один или несколько background инстансов, зависит от специфики. Может использоваться elasticache для redis и RDS для базы данных. Мы используем rails + sidekiq, но алгоритм будет ±один для других стеков. Мы исключили a-инстансы, т.к. ARM архитектура нам не подходит. Возможно вам есть смысл рассмотреть ещё и их.

Итоговая схема получилась такая:

• Есть несколько web-инстансов и если выключить один, сервис не страдает (смотрим на среднее время ответа в newrelic и CPU utilization используемых серверов) — выключаем
• Staging/dev-сервера — используем spot
• Дополнительный веб-сервер: spot
• Дополнительный background-сервер: spot
• Основной веб/background-сервер: reserved. Так мы будем застрахованы от ситуации, когда амазон заберёт все наши spot-инстансы в один момент (возможно вам нужно более одного гарантированного инстанса).
• Сервер бд/elasticache — если есть вероятность роста в ближайший год — берём on demand, иначе берём reserved на год.
• Если на графике CPU utilization видно, что сервер в обычном состоянии потребляет меньше 30% и лишь иногда видны пики — берём t, иначе c или m (зависит от необходимой вам памяти)

В таблице есть пример такого анализа для нескольких серверов и рекомендации. В такой конфигурации экономия составила бы 61,57%.

TL;DR

• Используйте spot-инстанс, когда не нужна гарантия его 100% работы
• Используйте reserved-инстанс, когда уверены, что за год его не нужно будет менять или выключать
• Используйте t-инстанс когда cpu большую часть времени простаивает ниже 20–30%
• Я провёл анализ только самого базового способа экономии, при котором не нужно изменять приложение и только для EC2/RDS/Elasticache. Больше инструментов оптимизации расходов AWS тут. Ещё можно попробовать переход на другие сервисы (ecs, lambda, etc). В первый год нужно использовать free tier. А ещё есть saving plans
• Прайсинг AWS это сложно, но чем больше понимаешь — тем оптимальнее можно использовать ресурсы

— — —

Остались вопросы или вы знаете ещё пару способов сэкономить на AWS ? Напишите мне в телеграмм @alexsubbotin. И подписывайтесь на канал Saturday Night Hack.