Мультиклауд-FinOps: как не разориться на нескольких облаках одновременно

Мультиклауд – важен, но сложен. Готовьтесь к этому.

Представим ситуацию: у вас три облака. Да, все российские (да и как же иначе?), но каждое работает по своим правилам. Одно считает трафик отдельной строкой в счете, второе как-то замешивает его в стоимость виртуалок, третье вообще берет фикс за месяц и не парится. Красота? Да нет, конечно! Потому что как все это складывать, решительно непонятно. Но вот был бы у вас FinOps, жить было бы куда легче. И дешевле.

Почему компании используют несколько облаков одновременно

Мультиклауд – это практика использования нескольких облаков для распределения нагрузки. Это не очень удобно с точки зрения унификации, но в таком подходе есть своя логика:

• Во-первых, если ложится одна площадка, то вторая может взять нагрузку на себя;
• Во-вторых, разные провайдеры могут предлагать специализированные сервисы, которых нет у конкурентов. 
• В-третьих, регуляторные требования тоже вносят свои коррективы. Иногда данные просто обязаны лежать в конкретном облаке с нужными сертификатами, которых нет у других.

У одной компании может быть и 3, и 4 площадки одновременно. Например, основа – это Яндекс Облако, VK Cloud – для экспериментов, Cloud.ru – для работы с госсектором. Конфигурации могут быть самые разные. Главное – суметь свести все расходы воедино и понять, на чем реально можно сэкономить, а на чем – нет.

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

Причем названия сервисов скорее всего тоже будут разные. То, что в Яндексе называется Object Storage, в VK Cloud может быть S3-совместимым хранилищем, а в Cloud.ru обозначаться как-то по-своему.

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

Проблемы миграции с AWS и Azure на российские облака

В 2022 году западные провайдеры ушли с российского рынка довольно резко. AWS, Azure, Google Cloud просто закрыли возможность создавать новые ресурсы, а потом начали постепенно отключать существующих клиентов. У компаний было всего несколько месяцев на то, чтобы перенести всю инфраструктуру куда-то еще.

Поэтому переезжали кто во что горазд, не особо заботясь об оптимизации.

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

На самом же деле сложностей от этого не убавилось. Поскольку 152-ФЗ предъявляет особые требования к хранению персональных данных, многим пришлось раскидывать нагрузку по нескольким облакам. Ведь важна не только территориальная принадлежность провайдера, но и наличие у него определенных сертификатов. Получается, что даже если вы нашли облако с хорошими ценами, использовать его для всех задач скорее всего было нельзя.

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

Просто тарифы у местных провайдеров устроены чуть иначе, чем у зарубежных. В AWS можно было выгодно взять инстанс побольше с запасом по памяти, потому что разница в цене была небольшая. Но у наших та же логика могла привести к переплате в полтора раза. А поскольку многие переносили виртуалки один в один без оптимизации под нового провайдера, не пересчитывая конфигурации под реальную нагрузку, счета росли на 30-40%.

Как спроектировать инфраструктуру для мультиклауда

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

1. Не завязывайтесь на уникальные сервисы конкретного провайдера. Если компания активно использует фирменные managed-базы со специфичными настройками, сервисы ML, которые есть только у этого вендора, проприетарные API, переехать к другому без переписывания половины кода будет невозможно. Используйте стандартные решения там, где это возможно: PostgreSQL вместо фирменной базы, S3-протокол для хранения объектов, Kubernetes для контейнеров.
2. Описывайте инфраструктуру как код. Kubernetes + Terraform дают гибкость. Один раз описали инфраструктуру, развернули в Яндексе. Потом взяли тот же манифест, поменяли параметры провайдера – и без проблем развернули в VK Cloud. Правки будут, конечно: названия инстансов разные, зоны доступности называются по-другому. Но исправить это займет часы, но никак не месяцы.
3. Проверяйте отказоустойчивость на практике. Размазать нагрузку по трем облакам – это еще не мультиклауд. Задумывались ли вы, что будет, если основная площадка ляжет на часов эдак на 8? Как быстро переключится трафик? Кто это будет делать и по какой инструкции? Без подобных учений эти вопросы остаются без ответа до тех пор, пока не сломается что-то реально важное.

Кто в компании должен контролировать облачные расходы

Хорошо, архитектуру продумали, провайдеров выбрали. Теперь вопрос: кто за все это отвечает?

Тут нет универсального ответа. Все зависит от размера компании и того, насколько у вас вообще налажены процессы.

• В маленьких компаниях обычно один DevOps на все. Он и мониторит расходы, и общается с провайдерами, и поддерживает инфраструктуру. Просто потому что больше некому. Такой подход называется централизованным и работает до тех пор, пока проектов немного и бюджет считается на коленке. Но как только начинается рост, вся схема ломается. Человек физически не успевает отследить расходы по десяткам сервисов в трех облаках.
• Крупные компании идут другим путем. Каждое подразделение получает свой бюджет и само решает, как его тратить. Маркетинг управляет своими аналитическими системами, разработка продукта своими, бэкенд-команда своими. Это федеративная модель. Тут главное, чтобы сверху были единые правила: как тегировать ресурсы, какие отчеты предоставлять, кто принимает решения о резервировании мощностей. Без этого получается хаос, где никто не знает, кто виноват в перерасходе.
• Золотая середина – это гибридная модель. Она предполагает, что есть небольшая центральная команда, которая договаривается с вендорами, выбирает инструменты учета, пишет политики использования облаков. А исполнение остается за подразделениями. То есть центр задает стандарты, команды их выполняют.

Как понять, что система работает нормально? Посмотрите, какой процент расходов вы можете объяснить. Если половина бюджета уходит непонятно куда, без привязки к проектам и командам, значит контроль не работает. В идеале вы должны быть способны объяснить буквально каждый рубль.

Cost per unit и другие метрики для контроля облачных затрат

Допустим, вы внедрили контроль расходов, назначили ответственных. Теперь надо понять: а работает ли это вообще? На какие цифры смотреть, чтобы увидеть реальную картину?

Начните с простого – посчитайте стоимость базовых действий в вашем сервисе:

• Одного письма
• Одного заказа
• Одного показа страницы пользователю

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

Дальше смотрим за динамикой. Если количество пользователей выросло вдвое, а счета за инфраструктуру втрое, значит, что-то пошло не туда. Может, архитектура плохо масштабируется. А может, кто-то забыл выключить дорогой инстанс после теста. А вот если наоборот, то тогда хорошо. Это верный знак, что масштабирование прошло правильно.

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

Как снизить расходы на межоблачный трафик

Все думают, что деньги жрут виртуалки. В целом, да: GPU, мощные инстансы, терабайты дисков – все это стоит денег. Но на самом деле главной неожиданностью является трафик.

Причем внутренний трафик, когда данные ходят между вашими сервисами в одном облаке, обычно бесплатный или почти бесплатный. А вот исходящий в интернет и межоблачный — дорогие. У некоторых провайдеров гигабайт исходящего может стоить как час работы небольшой виртуалки.

К чему это ведет: API лежит в одном облаке, статика раздается из второго, аналитика собирается в третьем. Каждый запрос пользователя теперь не просто обрабатывается, а гоняет данные туда-сюда между площадками. Миллион запросов в день по 50 килобайт каждый – и вот вам счет на сотни тысяч рублей лишь за трафик.

Чтобы остановить это, начните с рисования схемы потоков данных. Реально возьмите бумагу или откройте какой-нибудь draw.io и прикиньте, куда ходят ваши данные и зачем. В результате получится, что логи пишутся в одно облако, обрабатываются во втором, результаты складываются в третье. И половину этих переездов можно убрать, просто переставив сервисы поближе друг к другу.

Ну и в довесок еще момент. Иногда дешевле продублировать данные в каждом облаке, чем постоянно синхронизировать их по сети. База на 100 гигабайт в хранении стоит копейки. Зато если ее дергать из другого облака по сотне раз в минуту, счета взлетят так, что мама не горюй.

Резервирование мощностей и спотовые инстансы: как экономить на облаках

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

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

Спотовые инстансы дают скидку до 70-80%, но могут отключиться в любой момент. Поэтому для продакшена они не подойдут. Но для CI/CD, обработки данных, рендеринга это то, что нужно. Хотя если архитектура спроектирована правильно, можно часть нагрузки держать на спотах с автоматическим переключением на обычные инстансы при отключении. В общем, тут смотрите сами. На худой конец, посоветуйтесь со спецами в сообществе Практики FinOps.

Также учитывайте сезонность. Если ваш сервис связан с онлайн-торговлей, готовьтесь к разного рода распродажам заранее. Если с образованием – к сентябрю и или к новому году. Провайдеры дают возможность зарезервировать дополнительные мощности на конкретный период. Это дешевле, чем докупать их в последний момент, когда всем нужно вчера.

Ну и не забывайте сравнивать провайдеров. Один дает хорошие скидки на вычисления, другой на хранение, третий на трафик. Поэтому, чтобы ничего не упустить, заведите себе табличку и пересчитывайте условия раз в квартал. Расценки могут меняться вообще без видимых для внешнего наблюдателя факторов. От вас лишь требуется не профукать эти изменения.

Как финансовый контроль помогает ловить проблемы с безопасностью

Чем больше облаков, тем больше шансов, что что-то где-то может сломаться или подвергнуться атаке. Вот только при чем тут FinOps? Речь же о безопасности, а не об экономии.

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

Технический мониторинг может не заметить продуманную атаку без явных признаков. А вот счет не обманешь. Он просто не может вырасти без причины. Появились расходы на GPU, которые команда не заказывала? Трафик между облаками удвоился без изменений в коде? Каждый такой случай требует разбора. Что-то да найдете.

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

Решения для учета расходов в облаке

Привести данные о расходах из нескольких разных облаков, которые приходят в разных форматах, к общему виду действительно непросто. Поэтому без специальных инструментов тут не обойтись.

За границей для этой цели используют FOCUS (FinOps Open Cost and Usage Specification). У нас про такое пока не слышали, поэтому решают проблему своими силами. Кто-то пишет скрипты на Python, которые собирают данные через API. Кто-то использует готовые ETL-инструменты вроде Airflow. Кто-то просто скачивает CSV и сводит в Excel.

Но какой бы путь вы ни выбрали, есть базовые вещи, без которых система не заработает:

• Провайдеры обновляют API без предупреждения. Сегодня поле с ценой называется cost, завтра price, послезавтра total_amount. Из-за этого ваши скрипты ломаются, отчеты начинают показывать нули, а вы узнаете об этом только когда руководство спрашивает, почему счета не сходятся. Автоматические проверки на изменения в структуре данных решают эту проблему.
• Без меток project, owner, environment в мешанине из сотен инстансов вы точно не разберетесь. Каждый ресурс должен знать, к какому проекту относится, кто владелец, какое окружение. Думаете, что запомните? Не обольщайтесь. Через месяц никто не вспомнит, зачем вообще была нужна та ВМ и можно ли ее выключить.

Теперь про конкретные инструменты. В России их пока не так много, но они все-таки есть:

• Клаудмастер от Inferit FinOps. Российская разработка, которая входит в реестр отечественного ПО. Система смотрит на реальную нагрузку и предлагает корректировки размеров, чтобы не переплачивать за простаивающие мощности.
• Kubecost + Prometheus решают специфическую проблему кубернетес-кластеров. Prometheus собирает метрики о том, сколько ресурсов потребляет каждый под, каждый контейнер. Kubecost берет эти метрики и накладывает на них цены провайдера. В результате видите не абстрактные CPU и память, а рубли.
• Самописные решения. Это может быть дашборд в Grafana, который собирает данные из API провайдеров раз в час, скрипт на Python с утренней сводкой в Telegram или что-то другое. Для первых шагов будет вполне достаточно.

Практический чек-лист готовности к мультиклауд-FinOps

Теория это хорошо, но нужно обязательно проверить, все ли у вас настроено правильно:

1. Начните с архитектуры. Если завтра понадобится перенести часть нагрузки в другое облако, сколько времени это займет? Неделю правок в конфигах или три месяца переписывания кода? Используете ли проприетарные сервисы провайдера там, где можно обойтись стандартными решениями? Когда последний раз проверяли, что будет при отказе одной из площадок?
2. Дальше про данные. Биллинг из всех облаков собирается автоматически или кто-то вручную скачивает CSV раз в месяц? Есть ли проверки на изменения в структуре данных от провайдеров? Все ли ресурсы помечены тегами с проектом, владельцем и окружением? Если на последний вопрос ответ нет, начните именно с этого.
3. Финансовая часть. Можете ли посчитать, сколько стоит одна транзакция в вашей системе? Один активный пользователь за месяц? Гигабайт данных в хранилище? Учитываются ли в прогнозах сезонные пики нагрузки? Закупки ресурсов планируются заранее на основе статистики или покупаете все по требованию когда припрет?
4. Автоматизация и безопасность. Настроены ли правила для автоматической уборки забытых ресурсов? Алерты на резкий рост расходов без видимых причин? Совместно ли команды FinOps и безопасности отслеживают аномалии в потреблении?

Если хотя бы на половину вопросов ответили утвердительно, уже неплохо. Если меньше, есть над чем работать. Мультиклауд без контроля расходов превращается в черную дыру для бюджета. Но с правильно настроенным FinOps получаете не только экономию, но и дополнительный инструмент для мониторинга безопасности и стабильности всей инфраструктуры. Так что дерзайте. Хуже точно не будет.