FinOps по-казахски: как мы оптимизировали расходы на облако для логистической компании на 40%

В последние пару лет каждый второй IT-директор в Казахстане с гордостью заявляет: "Мы переехали в облако!". Вендоры обещали золотые горы: платите только за то, что используете, масштабируйтесь в один клик, забудьте про закупку серверов. Но проходит полгода, и финансовый директор, глядя на выписку с корпоративной карты, задает резонный вопрос: "А почему мы платим за этот ваш Google Cloud в три раза больше, чем раньше за локальный ЦОД?".

Знакомая боль? Добро пожаловать в суровую реальность, где облако не прощает архитектурных ошибок. Если вы просто берете свои старые виртуальные машины из подвала и переносите их "как есть" в облако (подход "lift-and-shift"), вы не экономите. Вы начинаете переплачивать. Сегодня мы поговорим о FinOps (Financial Operations) — культуре управления облачными расходами. И разберем на реальном кейсе лаборатории ОЗАТ, как мы "похудели" ежемесячный счет крупной логистической компании на 40%, не пожертвовав при этом ни байтом производительности.

Как логисты облако покупали (и почему им стало больно)

К нам обратилась логистическая компания, оперирующая сотнями фур по всему Казахстану и СНГ. У них был сложный монолитный софт для трекинга грузов, маршрутизации, складского учета и CRM. Год назад они устали от постоянных падений собственных серверов и мигрировали в Google Cloud Platform (GCP).

Архитектура была классической (и совершенно не облачной): с десяток огромных виртуальных машин (Compute Engine) с 16-32 vCPU и кучей оперативки, здоровенный инстанс Cloud SQL (PostgreSQL), который работал на износ, и несколько гигабайтных дисков (Persistent Disks) с "очень важными историческими данными". Счет за инфраструктуру перевалил за отметку, от которой у фаундеров начал дергаться глаз. И самое обидное — система все равно периодически тормозила в часы пик, хотя в остальное время процессоры простаивали.

Мы провели аудит и схватились за голову. Инфраструктура была похожа на огромный внедорожник, который сутками стоит в алматинской пробке с включенным кондиционером и двигателем на холостых оборотах. Бензин (деньги) горит, а мы никуда не едем.

Шаг 1. Rightsizing: прекращаем кормить "воздух"

Первое правило FinOps: выключи то, что не используешь, и уменьши то, что используешь наполовину. Мы запустили Recommender API в GCP и проанализировали метрики утилизации CPU и RAM за последние 30 дней.

Выяснилось, что из 32 ядер на сервере базы данных в среднем утилизировалось от силы 4. Разработчики логистов просто выбрали машину "с запасом", чтобы точно не упало. Мы провели даунсайзинг инстансов Cloud SQL и Compute Engine до адекватных размеров.

Результат: Моментальная экономия в 15% от общего счета. Без единой строчки кода. Просто потому, что мы перестали платить за простаивающие мощности.

Шаг 2. Расписание для тестовых сред (Scheduling)

В GCP у клиента было развернуто три окружения: Dev, Stage и Prod. И все три работали 24/7. Внимание, вопрос: зачем среде разработки работать в субботу в 3 часа ночи, если все программисты спят (или сидят в баре)?

Мы настроили простую автоматизацию с помощью Cloud Scheduler и Cloud Functions. Теперь Dev и Stage окружения автоматически выключаются (shut down) в 20:00 вечера и просыпаются в 09:00 утра в будние дни, а на выходных отдыхают вместе с командой.

Результат: Затраты на тестовые среды упали на 65%. Мелочь, а финансовому директору приятно.

Шаг 3. Переход на Serverless: Cloud Run как панацея от простоя

Логистика — бизнес с ярко выраженными пиками. Утром диспетчеры массово выписывают путевые листы, грузчики сканируют штрих-коды, система пыхтит. Ночью фуры просто едут по трассе, генерируя легкий телеметрический трафик (GPS-координаты). Держать для этого огромный кластер серверов бессмысленно.

Мы предложили разбить самый тяжелый кусок монолита (модуль трекинга и приема телеметрии) на микросервисы и перенести их в Google Cloud Run. Cloud Run — это serverless-платформа, которая автоматически масштабирует контейнеры от нуля до тысяч в зависимости от трафика, и вы платите только за время выполнения запроса (с точностью до 100 миллисекунд).

Когда ночью запросов мало, Cloud Run ужимается до минимума. Когда утром диспетчеры логинятся в систему — он мгновенно поднимает десятки инстансов.

Результат: Мы не только срезали косты на 20%, но и полностью избавились от проблемы утренних "тормозов". Система стала эластичной.

Шаг 4. Укрощение BigQuery и Cloud Storage

Данные о перемещениях машин за последние 5 лет логисты хранили в горячем хранилище и регулярно "селектили" их тяжелыми аналитическими запросами в BigQuery.

Что мы сделали:

• Настроили Object Lifecycle Management в Cloud Storage. Теперь данные старше 90 дней автоматически перемещаются из дорогого класса Standard в дешевый Coldline, а старше года — в копеечный Archive.
• В BigQuery мы внедрили партиционирование (Partitioning) и кластеризацию таблиц по дате и ID машин. Раньше каждый запрос аналитика сканировал терабайты данных (и стоил по 5 долларов за клик). Теперь запрос сканирует только нужный день, обходясь в пару центов.
• Ограничили квоты (Custom Quotas) на запросы для стажеров-аналитиков, чтобы случайный SELECT * не прожег дыру в бюджете компании.

Шаг 5. Spot Instances (Preemptible VMs) для фоновых задач

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

Мы перевели эти воркеры на Spot VMs (прерываемые машины). Это вычислительные мощности, которые Google сдает со скидкой до 80-90% при условии, что он может забрать их в любой момент, если они понадобятся кому-то другому по полной цене. Для batch-обработки, рендеринга видео или обучения нейросетей — это идеальный инструмент.

Результат: Затраты на ночные вычисления упали в 4 раза.

Итоги FinOps-операции

За месяц работы мы снизили ежемесячный счет за инфраструктуру на 40% (а в абсолютных цифрах это были тысячи долларов). При этом надежность системы выросла, а перфоманс в часы пик стал эталонным.

FinOps — это не про то, чтобы "сделать подешевле и похуже". Это про осознанное потребление облака. Вы не должны платить за воздух. Инфраструктура должна дышать вместе с вашим бизнесом: расширяться, когда идут продажи, и сжиматься, когда клиенты спят.

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

Высокого аптайма и низких счетов за GCP!