Это история о том, как мы сократили расходы на AWS на 80% всего за две недели.

Для разработчиков AWS — это Клондайк возможностей

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

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

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

Что мы сделали, чтобы сократить расходы на AWS?

Мы небольшая компания, и наши затраты на AWS немногим больше 7 тыс. долларов в месяц по всем учетным записям AWS. Также стоит упомянуть, что мы размещаем только DEV и QA‑стенды, поскольку PROD‑стенды оплачиваются нашими клиентами. Наши ресурсы — это в основном отдельные рабочие машины для разработки, тестовые базы данных и различные специализированные ресурсы для исследовательских проектов, такие как Kinesis Firehose, Sage Maker и т. д. Таким образом у нас множество разнообразных ресурсов, которые сложно классифицировать, структурировать, прогнозировать и контролировать.

Так что же мы сделали, чтобы снизить наши расходы на AWS?

Во-первых, мы начали изучать Cost Explorer и определили самые дорогостоящие позиции:

• Мы обнаружили узел Bitcoin, который без остановки работал последние 4 месяца, и стоил нам 600 долларов в месяц, поскольку для его работы требовался большой SSD с дополнительной предоставленной скоростью. Мы проводили небольшое исследование по ординалам Bitcoin и не удалили эту машину.

Решение: мы заархивировали диск (это обходится нам в $6/месяц) и прекратили работу виртуальной машины. 

Экономия: $594 в месяц.

• Мы нашли машину с GPU Nvidia Tesla, которая обходится нам в $531 в месяц. Мы продолжаем использовать её для экспериментов с генеративным искусственным интеллектом. Мы планируем создать своё приложение, которое будет преобразовывать текст в видео, поэтому эта машина нам нужна. 

Решение: мы переместили диск на spot-инстанс.

Экономия: $360 в месяц.

• Это не была самая дорогая ошибка, но самое удивительное, что мы обнаружили — это то, что забыли удалить демо-PROD стенд в одном из неиспользуемых регионов, где мы развернули наши скрипты terraform для тестирования развертывания PROD «с нуля».

Экономия: $340 в месяц.

• Еще множество мелких позиций. 

Решения: различные. 

Экономия: $1700 в месяц.

Во-вторых, мы начали переносить все, что возможно, на spot‑инстансы. Это простая процедура. Для отдельной машины вам нужно ее выключить, отсоединить диск (не забудьте записать путь к монтированию), а затем остановить работу машины. Затем вы создаете новый spot‑инстанс (неважно, какой AMI, главное — чтобы архитектура CPU была совместима с вашим предыдущим диском). Как только spot‑инстанс создан, отсоедините (и не забудьте удалить!) новый диск и подсоедините предыдущий диск на том же пути монтирования, что и на исходной машине. Для сред Beanstalk процесс еще проще — мы просто изменили настройки мощности, чтобы использовать только spot‑инстансы.

Экономия: $1000 в месяц

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

Экономия: $300 в месяц.

В-четвертых, мы уменьшили некоторые ресурсы. Вопрос в проверке используемого CPU и RAM, и если мы видим постоянное использование менее чем на 50%, мы уменьшаем уровень. 

Экономия: $300 в месяц (было бы в 3 раза больше на on-demand инстансах).

В-пятых, мы настроили автоматическое выключение на отдельных машинах. Мы создали множество функций lambda для разных типов задач: выключение SageMaker Jupyter VM после 1 часа бездействия, выключение отдельных VM, DEV и QA стендов на ночной период, когда никто не работает. Эти функции lambda запускаются на событиях CloudWatch каждый день. Также существуют функции lambda для включения DEV и QA стендов, чтобы облегчить процесс. 

Экономия: $500 в месяц.

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

На сегодняшний день мы уже сократили наши месячные затраты на AWS с $7000 до примерно $1500. Это около 80% от всей суммы! Я и представить не мог, что мы так много тратим на AWS. В итоге наша годовая экономия может достигнуть порядка $66,000.

Как организации подходят к оптимизации облачных расходов?

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

Если оптимизация затрат на облачные сервисы — это такая ключевая задача, то как компании обычно её решают? Давайте рассмотрим различные способы управления расходами на облачные ресурсы, от простых до более сложных и продвинутых.

1. Покупка только виртуальных машин

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

SQS? Нет. DynamoDB? Нет. Просто используйте виртуальные машины EC2 и устанавливайте на них все, что нужно.

Плюсы:

• Расходы можно спланировать очень точно, потому что цена каждой машины EC2 заранее известна

• Разработчики могут установить на доступные машины все, что им нужно. Это похоже на работу в обычном дата-центре, так что деньги тратятся эффективно.

Минусы:

• Вы теряете все преимущества автомасштабирования

• Разработчики тратят время на создание функционала, который на самом деле уже есть

• Вы пропускаете автообновления, которые могли бы быть установлены автоматически. 

В общем, эта стратегия по типу «снять хостинг на GoDaddy и делать всё самим» — не лучший подход при работе с облаком.

2. Проверять каждый запрос

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

Представьте, что разработчику нужна конечная точка Kinesis Firehose (да, я упоминаю сервис, о котором вы, скорее всего, даже не слышали). Будет ли простой задачей для разработчика объяснить контролеру, что он хочет? Затем разработчику также придется объяснить причину масштабирования и, возможно, даже доказать, что выбор архитектуры является эффективным и не требует лишних затрат.

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

И это только верхушка айсберга. Теперь представьте:

• Ресурс становится ненужным из-за изменения архитектуры

• Разработчик увольняется и не удаляет ресурсы, которые использовались для индивидуальной разработки

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

Плюсы:

• Разработчикам разрешено максимально использовать преимущества управляемых ресурсов AWS

• Затраты хорошо контролируются.

Минусы:

• Могут появиться излишки облачных ресурсов из-за ненужных и неудаленных элементов

• Команда управления затратами должна обладать высоким уровнем знаний AWS

• Уровень бюрократии может негативно сказаться на бизнесе.

3. Нанять команду FinOps

Более современный подход — это найти и привлечь специалистов по AWS, которые будут следить за нашими расходами. У AWS есть куча встроенных инструментов для контроля расходов. Это, например:

• «исследователь расходов» (он как детектив, который анализирует, куда уходят деньги)

• система тегов (это чтобы знать, какой проект или команда «кушает» больше всего)

• зарезервированные экземпляры и планы экономии (чтобы сэкономить на долгосрочных проектах)

• отслеживание аномалий в расходах (если что-то необычное происходит с расходами, они вам об этом скажут)

• И многое другое.

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

Есть такое направление, как FinOps — это в основном команда DevOps, но с акцентом на финансах.

Плюсы:

• Разработчикам доступны все преимущества AWS

• Минимум бюрократии для разработчиков

• Финансовая команда контролирует расходы по разным направлениям: по проектам, по командам и так далее

• Разработчики сознательно используют ресурсы.

Минусы:

• Нужны специалисты высокого класса, а таких ещё практически нет на рынке, так что придётся обучать своих сотрудников

• Есть риск ошибок из‑за «человеческого фактора»

• Если мы проверяем ресурсы не каждый день, то какой-нибудь неиспользуемый сервер может простаивать неделями, а мы об этом даже не узнаем.

4. Использовать программное обеспечение для управления облачными ресурсами

Если вы серьезно думаете о найме (или создании своей собственной) команды FinOps, вы также должны рассмотреть возможность использования стороннего программного обеспечения для оптимизации облачных затрат, например Infinops. Это ваш автоматический член команды FinOps, который работает 24/7 и не подвержен человеческим ошибкам. Такое программное обеспечение автоматически контролирует ваше облако на предмет недостаточно используемых ресурсов и других известных способов экономии, таких как:

• Использование спотовых экземпляров

• Использование зарезервированных экземпляров

• Сокращение числа кластеров OpenSearch в QA-окружении

• Отключение персональных VM на ночь

• Автоматическое отключение дорогих VM SageMaker с Jupyter

• и т.д.

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

Плюсы:

• Отличный инструмент для команды FinOps

• Помогает новичкам в FinOps с методами оптимизации

• Сокращает риск человеческого фактора

• Обеспечивает периодический обзор потребления ресурсов

• Двигает к использованию тегов, управлению жизненным циклом и т.д.

• Позволяет отслеживать несколько учетных записей AWS одновременно.

Минусы:

• Имеет свою стоимость (обычно намного меньше, чем экономит).