Как сэкономить $10К в месяц в Google Cloud Platform, и потратить $2к за один день

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

Так случилось с недавним проектом, над которым работала команда Mad Devs. Мы работали над оптимизацией стоимости облачных вычислений для PaaS проекта. Сегодня мы разберемся как можно сэкономить $10К в месяц в Google Cloud Platform, что мы для этого сделали и почему нам пришлось потратить $2К за один день. В статье вы узнаете:

• О проекте
• Как определили проблемы в проекте
• Подготовка списка ресурсов на оптимизацию
• План работ и сами работы по архивации
• Удалось ли сэкономить?

О проекте

Команда Mad Devs работает над одним американским стартапом, который занимается PaaS разработкой продукта, который позволяет по записи голоса определить тип и степень психических проблем у человека. Коллеги из стартапа говорят о продукте следующее:

Это технология голосовых биомаркеров, которая использует мощь искусственного интеллекта и голоса для выявления признаков депрессии и беспокойства. Благодаря платформе API-first наш продукт встраивается в существующие клинические рабочие процессы и помогает врачам в режиме реального времени.

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

Поиск проблем

Коротко об инфраструктуре проекта: она построена на двух столпах — Google Cloud Platform (GCP) и GitLab. Никаких сторонних систем кроме комплаенса Vanta команда не использует по внутренним причинам.

В рамках оптимизации, первой рабочей задачей был рефакторинг основного terraform кода продукта для развертывания окружений dev, staging и prod в отдельных проектах и миграция на новые окружения. На тот момент, в проекте IaC не функционировал из-за значительных расхождений между кодом Terraform и текущим состоянием, которое управлялось вручную. IaC представляет собой метод, при котором код управляет инфраструктурой, включая приложения и программы. В данном случае, изменения в инфраструктуре были внесены вручную, без соответствующих изменений в коде Terraform. Если бы мы запустили этот код, все ручные изменения были бы перезаписаны, и мы потеряли бы продуктовую инфраструктуру. Чтобы решить эту проблему, мы переработали код и развернули отдельную новую инфраструктуру, на которую мы затем перенесли наш проект, а старую инфраструктуру удалили.

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

Мы составили план по оценке расходов:

1. Выгрузить отчет с биллинга и провести его анализ обращая внимание на крупные траты.
2. Составить список ненужных/неиспользуемых/очень дорогих сервисов и опросить команду о возможности сократить расходы.
3. На основании обратной связи сформировать план по сокращению расходов.

Подготовка списка ресурсов на оптимизацию

После первичного ревью отчета с биллинга выяснилось, что в GCP находится около 30 проектов в непонятном состоянии, некоторые из которых тратят огромное количество денег в месяц.

Что нам удалось выяснить:

1. Основной проект продукта имел 3 окружения, dev/staging/prod, соответственно стоимость развертывания можно умножать на 3.
2. В dev/staging был развернут сервис Cloud IDS для прохождения SOC2 и HIPAA комплаенсов который используется только в prod. (Примерно $2300–3000 в месяц за проект в зависимости от объема тестов, $4600–6000 в месяц суммарно).
3. В проекте Shared Infra больше $8000 в месяц тратилось на содержание непонятных на тот момент дисков.
4. Существовало две старых версии продукта, с суммарным расходом в $2600 в месяц и которые больше не использовались.

План работ и сами работы по архивации

На основе имеющейся информации был разработан план по оптимизации по которому были выполнены следующие задачи:

1. Был выключен CloudIDS в dev/staging на стороне Terraform за счет флага “env_prod: true/false”
2. Были удалены старые проекты после архивирования чувствительных данных.
3. Были заархивированы и удалены старые, неиспользуемые диски. Подробнее мы остановимся ниже.

Стоимость диска мы рассчитывали по следующей формуле:

Где, disk size — это размер диска, а k type — это коэффициент стоимости использования диска в месяц в зависимости от типа.

В проекте преимущественно использовались Balanced PD с k type = 0.1 Гб в месяц, при среднем размере в 2 ТБ стоимость использования одного диска составляла $200 в месяц. При этом важно помнить, что на дисках использовалась не вся доступная память. Что при архивировании также помогло сэкономить деньги.

Одной из самых недорогих опций по хранению большого количества данных стал для нас Google Cloud Storage. Выбрав тип Coldline storage мы добились того, что наш коэффициент стал k type = 0.004, что в 25 раз меньше предыдущего и помогает сэкономить значительную сумму денег.

Для переноса данных мы написали bash скрипт на основе gsutil для копирования данных в Google Cloud Storage бакеты.

Если вы хотите ускорить процесс копирования, используйте флаг -m, например gsutil -m cp ./local_folder gs://bucket_name/, это сильно ускорит процесс копирования данных.

Как результат, после переноса данных и удаления дисков планировалось сэкономить $11 тысяч.

Примерно вот так это должно было выглядеть:

Удалось ли нам сэкономить?

Увы, но нет. В апреле к нам обратились новые коллеги из ML Team, которым резко понадобились 2 виртуалки c 4 Nvidia Tesla A100 40G в каждой. Каждое GPU в них стоит $2141, 1 виртуалка нам начала обходиться в $9 тысяч в месяц.

Итого $18 тысяч в месяц за две виртуалки, к сожалению, коллеги из ML team самостоятельно сделали себе виртуалки не сообщив нам об этом, что испортило наши планы и расчеты.

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

Если посмотреть на график, то на первый взгляд мы вообще не сэкономили:

По предварительным расчетам (при условии, что никто не создаст ничего нового) мы будем тратить около $22 тысяч. Если учитывать, что мы удаляли старые/архивные диски, а ML Team инженеры в любом случае развернули бы свои виртуальные машины на $8–10 тысяч в месяц, то мы бы пришли к стоимости в примерно $30–35 тысяч в месяц.

Заключение

Какие выводы можно сделать? Напрашивается сразу несколько:

1. Старайтесь делать регулярный внутренний аудит инфраструктуры, следите за расходами.
2. Контролируйте процесс внедрение новых фич и делайте оценку их стоимости перед внедрением.
3. Чаще задавайте вопросы, “А нужно ли нам это? Мы точно понимаем как будем пользоваться этим?”.
4. Сокращение расходов это вечная борьба, надо стараться расслабиться и получать удовольствие.