Попробуйте как-нибудь чисто из спортивного интереса объяснить жене, почему в прошлом месяце ваш интернет стоил не 900 рублей, как обычно, а 90 000. Аттракцион, прямо скажем, диковатый, но примерно в таком же положении оказывается ваш ИТ-дир, когда видит счета от всех облачных сервисов одновременно. Что не так? Да примерно все. Каждый провайдер считает по своим правилам, выставляет счет в собственном формате, из-за чего объяснить, за что именно платим, оказывается просто супер-сложно. Но ведь не будешь складывать все яйца в одну корзину. Значит, нужно решать этот вопрос как-то по-другому.

Что такое мультиклауд

Мультиклауд сегодня – это не блажь, а насущная необходимость. Особенно в России. Почему особенно? Ну такой уж у нас регуляторный климат:

• Яндекс Облако берем для основной нагрузки;

• Cloud.ru – для работы с госсектором;

• VK Cloud – для экспериментов с нейросетками;

• Плюс старые добрые дедики где-нибудь в подвале.

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

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

Российские реалии: санкции нам на пользу

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

Тут и федеральный закон 23-ФЗ теперь прямо запрещает хранить персональные данные россиян на зарубежных серверах. И уход Microsoft, Google и AWS привел к тому, что местным компаниям пришлось массово мигрировать на отечественные облака. И много чего еще.

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

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

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

Архитектура под мультиклауд

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

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

Поэтому берем Kubernetes и Terraform. Это ваша страховка от будущих мучений (и переплат тоже). Инфраструктуру описываем как код, а потом разворачиваем хоть в Яндексе, хоть в VK Cloud, хоть в Cloud.ru без переписывания половины системы. Мигрировать в один клик потом, конечно, все равно не получится, но так хотя бы не придется переносить все вручную по крупицам.

Ну, и проверяйте отказоустойчивость на практике. Если вы просто размазали нагрузку по разным площадкам, это еще не мультиклауд. А вы проверяли, что будет, если Яндекс Облако ляжет на полдня? А если у VK Cloud будут проблемы с сетью? Нет? То-то и оно.

Кто за что отвечает: организационные модели

Первый вопрос, с которым сталкивается любая компания при внедрении мультиклауд-FinOps — кто будет этим заниматься и как организовать работу. Все зависит от выбранной вами модели.

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

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

• Гибридная модель. Это золотая середина для большинства средних и крупных российских компаний. Есть центральная команда, которая занимается стратегией — переговоры с провайдерами, выбор инструментов, создание политик тегирования, – а есть локальные команды. Они в свою очередь решают тактические задачи — оптимизируют конкретные нагрузки, внедряют рекомендации по правильному сайзингу, управляют жизненным циклом тестовых окружений.

Как понять, какая модель подходит вам?

Ну, в первую очередь отталкивайтесь от своего штата. Если компания маленькая – выбирайте централизованную модель с ручным управлением. Если большая – федеративную или гибридную.

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

Финансовая сторона мультиклауда

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

Cost per unit — штука простая как три копейки, но почему-то многие до нее не доходят. Сколько стоит обработать одну транзакцию? Во сколько обходится активный пользователь в месяц? А гигабайт данных в хранилище? Когда посчитаете такие вещи, непонятки испарятся сами собой. 

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

И еще момент, который почти всегда игнорируют. Связывайте облачные траты с реальными бизнес-показателями. Если выручка выросла на 20%, а расходы на инфраструктуру — на 50%, это не норма. Так быть не должно. А вот если пользователей стало вдвое больше, а счета почти не изменились, – это прекрасно. 

Сеть и трафик в мультиклауд

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

Допустим, вы разместили базу данных в Яндексе, кэш в VK Cloud, а фронтенд – в Cloud.ru. Нагрузка распределена, все логично. Но именно из-за этого теперь каждый запрос пользователя теперь тянет межоблачный трафик. А все это стоит денег.

Чтобы избежать лишних трат, начните со схемы потоков данных. Нарисуйте ее в голове, а реально на бумаге. Так вы увидите, сколько бессмысленных переездов делают ваши данные. Зачастую половину таких расходов можно скостить простой перестановкой сервисов. Поверьте, иногда реально выгоднее продублировать базу в каждом облаке, чем гонять синхронизацию по сети.

Закупки и резервирование мощностей в облаке

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

Первым делом разделите стабильное и переменное. Базовая круглосуточная нагрузка — хороший кандидат на резервирование. А вот пики (точеные), тесты и эксперименты лучше покрывать ресурсами по требованию. Только – заклинаю – не надо зарезервировать все подряд. Иначе получится не экономия, а черт-те что.

Спотовые инстансы — отдельная история. Они могут сэкономить довольно много (аж до 80%), но есть нюанс. Их могут просто отключить в любой момент без предупреждения. Так что для сборки проектов и обработки данных сойдет, а вот продакшен на них лучше не вешать. Что же делать, спросите?

Во-первых, миксуйте. Треть нагрузки на резервах, треть на спотах, остальное по требованию.

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

Ну, и, в-третьих, учитывайте особенности каждого провайдера. Например, один дает хорошие скидки на compute при годовом резервировании. Другой выгоднее в хранении данных. Третий – работает по госконтрактам с фиксированными ценами. В общем, ведите таблички и каждый квартал пересчитывайте, где что выгоднее. Оно, конечно, муторно, но зато таким макаром можно урезать счета аж вдвое.

Мультиклауд и безопасность

Чем больше облаков, тем больше у злоумышленников возможностей для атаки на вас. Каждое новое соединение между площадками — это потенциальная дыра. И тут FinOps тут может помочь неожиданным образом.

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

В этом смысле FinOps и DevSecOps дадут наилучший эффект.

Так вы будете не только контролировать бюджет, но и сможете узнавать о подозрительных активностях раньше, чем станет поздно. (ц) Джейсон Стэтхэм.

Полезные индикаторы для мониторинга:

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

• Создание инстансов в регионах, где у вас нет инфраструктуры

• Резкий рост расходов на хранение данных без видимых причин

• Аномальный сетевой трафик между облаками

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

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

Техническая кухня мультиклауд

Технически мультиклауд-FinOps строится вокруг централизованного хаба для сбора биллинговых данных. На Западе для этой цели используют FOCUS (FinOps Open Cost and Usage Specification). Это попытка свести разношерстные биллинговые отчеты воедино, чтобы добиться единого формата таблиц, схем и полей.

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

У нас действуют по-старинке:

• Подтягивают сырые данные через API или выгрузки;

• Подгружают их в свой дата-лейк;

• Нормализуют ETL-пайплайнами (Airflow, dbt, что под руку попадется);

• И уже сверху накатывают собственную схему тегов и справочников.

Самое важное тут автоматический контроль качества данных. API провайдера может измениться без предупреждения, и колонка с тарифами вдруг окажется под другим именем. Без тегов вы просто утонете. Каждая виртуалка, каждый бакет должны иметь метки проекта, владельца и окружения. А в части лимитов просто ориентируйтесь на самое капризное облако.

Визуализация может быть любой: Grafana, Yandex DataLens, кастомные панели. Главное, чтобы руководители видели живые графики и понимали, куда утекают деньги. А автоматизация правил не даст разориться на зомби-ресурсах, которые жрут бюджет в фоне.

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

Клаудмастер от Inferit FinOps входит в реестр российского ПО и умеет работать с основными облачными провайдерами и частными облаками. Она берет на себя всю самую скучную работу, которую вы сами делать точно не захотите. Это и автоматический сайзинг инстансов (чтобы не переплачивать за мощность, которую не используете), и уборка зомби-ресурсов (висящих дисков, забытых IP-адресов, древних снапшотов), и покупка инстансов со скидкой на год вперед. Особенно полезна функция автоматической оптимизации. Система анализирует реальную нагрузку на ваши виртуалки и предлагает уменьшить их мощность. Звучит просто, а денег экономит прилично. Плюс никаких санкционных рисков и техподдержка говорит по-русски.

Kubecost + Prometheus решают специфическую, но болезненную проблему кубернетес-кластеров. Просто знать, что кластер стоит 300 тысяч в месяц — одно. А понимать, что 250 из них жгет один под с машинным обучением, который какой-то дата-сайентист запустил на выходных и забыл — совсем другое.

Удобно, что Kubecost интегрируется с Prometheus (который, скорее всего, у вас уже есть для мониторинга) и показывает стоимость каждого пода, неймспейса, даже отдельных запросов к кластеру. Даже алерты можно настроить. Тогда, если кто-то превысит бюджет неймспейса, вы сразу получите уведомление с именами тех, кому не сносить головы. 

Самописные решения в российских компаниях встречаются чаще, чем на Западе. Кто-то, наверное, посмеется. Но иногда простой Python-скрипт, который раз в день дергает API биллинга и присылает отчет в Telegram-чат, может оказаться не хуже навороченной платформы. Ну и в чем тогда дело?

Главное — не увлекаться изобретением того, что уже существует. Нужен простой мониторинг превышения бюджетов? Пишите скрипт. Хотите сложную аналитику с машинным обучением? Лучше возьмите готовое решение.

Практический чек-лист

Чтобы понять готовность к управлению затратами в мультиклауде, пробегитесь по этому списку:

Стратегия и архитектура

• Архитектура позволяет переносить нагрузки между облаками без тотальной переделки

• Нет жесткой завязки на уникальные сервисы одного провайдера

• Регулярно тестируются сценарии отказа одной площадки

Данные и аналитика

• Биллинг всех облаков подтягивается в единый хаб

• Настроен автоматический контроль схемы и качества данных

• Вся инфраструктура покрыта тегами: проект, владелец, окружение

Финансы

• Есть метрики стоимости транзакции, активного пользователя, хранения

• Прогнозы расходов учитывают сезонные пики и валютные риски

• Закупки планируются на основе статистики, а не интуиции

Автоматизация

• Автоматические правила убирают зомби-ресурсы

• Настроены алерты на резкий рост дорогих ресурсов

• FinOps и DevSecOps совместно отслеживают аномалии

Мультиклауд-FinOps – не просто модное словечко, а способ превратить хаотичный набор облаков в управляемый бизнес-инструмент.  Неважно, где лежит ваша нагрузка. Без единой системы контроля ваши расходы так и будут оставаться чем-то, что вам не подвластно. А с правильно настроенным FinOps у вас хотя бы появится шанс превратить облако из статьи расходов в свое конкурентное преимущество. Но это, как говорится, уже совсем другая история.