Мультитенантность в FinOps: Проектируем ядро системы учета расходов

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для ИТ-директоров и финансовых руководителей. Готовы к ответу? «Виноват» не конкретный человек, а не оптимально работающая инфраструктура. Что же делать? — внедрять FinOps.

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

Мультитенантность: одна система — много клиентов

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

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

Реселлер — поставщик FinOps-услуг. Это может быть внутренний ИТ-департамент крупной корпорации или внешняя компания.

Клиент — тот, кто потребляет FinOps-услугу. У каждого клиента в рамках одного реселлера свой «личный кабинет» (клиентская панель управления) и своя инфраструктура, подключенная к этому «кабинету».

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

Подключение — инфраструктура клиента, имеющая некоторый технологический тип (Яндекс.Облако, AWS, VMware vSphere, Proxmox…) или не имеющая такого типа. От уточнения типа подключения могут зависеть некоторые алгоритмы сбора и обработки данных, поэтому это важный параметр.

Такая «мультитенантная» архитектура позволяет изолировать данные клиентов (потребителей FinOps-услуг), настраивать разные правила и стилистику пользовательского интерфейса для каждого реселлера (поставщика FinOps-услуг) и строить отчеты в любом разрезе — от всего холдинга до отдельного виртуального дата-центра.

Три кита: событие, объект, ресурс

Данные о структуре, расходах, полученных (установленных) и оплаченных мощностях приходят из биллинговых систем.

Данные о нагрузке (фактическом использовании купленного) приходят из мониторинговых систем. Задача FinOps-системы — все это собрать, обогатить и связать. Для этого рассмотрим еще 3 категории сущностей:

Событие — фиксация того, что произошло с инфраструктурой (объектами) в разрезе финансовых расходов и использования оплаченного. Нас интересуют два типа событий:

— Биллинговое событие: «за период X мы получили N единиц ресурса Y объекта Z и оплатили K единиц по такой-то цене, на такую-то сумму (иногда получение может быть явно не связано с оплатой)».

— Событие нагрузки (метрика): «в момент X ресурс Y объекта Z использовался на A% или на B единиц».

Объект (в терминах ITSM/ITIL — конфигурационная единица/configuration item) — то, из чего состоит наша инфраструктура, за что мы несём расходы и за чем мы наблюдаем: виртуальная машина, сервер, база данных. Напомним, что объекты могут быть связанными друг с другом: кластер →хост → диск.

Ресурс — то, что необходимо для создания или функционирования объекта, использование чего измеряется в каких-то единицах (CPU, RAM, диск) и за что мы обычно платим. Объект — это «черный ящик», а ресурсы — его «внутренности».

Модель биллинговых событий: кто и за что платит?

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

Существует международная модель сбора биллинговой информации — Focus (FinOps Open Cost & Usage Specification). Наши требования в целом соответствуют ей, но есть важные различия: в модели Focus иерархия объектов и мест размещения более плоская, чем требуется для сложных инфраструктур с глубокой вложенностью (например, VMware vSphere с семью уровнями).

Модель данных о нагрузке: проценты или ядра?

Данные о нагрузке — это ответ на вопрос «насколько эффективно мы используем купленное?». Мониторинговые системы могут выдавать данные в натуральных единицах (например, «3 ядра CPU загружены») или же в процентах («30% от установленной на объект мощности используется»). При этом в модели данных необходимо предусмотреть два отдельных поля: value_units и value_percent, чтобы избежать ошибок при анализе.

Контроль качества данных: от хаоса к порядку

Управление качеством данных (Data Quality) — это одна из основ аналитической системы, где качество данных оценивается по четырем критериям:

1. Полнота: Все ли ожидаемые файлы загружены? Все ли обязательные поля заполнены?

3. Достоверность: Соответствуют ли данные форматам (валидность) и справочникам (соответствие)? Например, пришел ли тип объекта из нашего справочника типов?

4. Своевременность: Загружены ли данные к установленному сроку?

5. Непротиворечивость: Не нарушена ли логика? Например, дата списания денег не может быть раньше даты создания объекта (если только это не предусмотрено бизнес-правилами).

При обнаружении нарушении возможны два подхода:

— Жесткий: ошибочная запись аварийно завершает весь ETL-процесс.

— Мягкий: ошибка фиксируется в специальном журнале событий контроля качества данных, ETL-процесс продолжает свою работу, игнорируя ошибочные данные.

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

Таблицы фактов и измерения

Основа аналитической системы, построенной на базе пространственного моделирования, — таблица фактов. Каждое событие (биллинговое или нагрузочное) — одна строка в этой таблице. Таблица фактов фиксирует как числа (количество, цена, стоимость, значение нагрузки), так и контекст: ссылки на таблицы-справочники (dim_date_id, dim_resource_id, dim_object_id, dim_location_id).

Типы таблиц фактов:

1. Транзакционные — фиксируют завершенное событие (списание денег). Это основной тип.

2. Периодические моментальные снимки (счетчики) — фиксируют состояние на момент времени (показания нагрузки).

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

Схема «Звезда» (Star Schema): в центре — таблица фактов, вокруг — таблицы измерений, связанные с ней через идентификаторы. Это оптимальный компромисс между скоростью работы (минимум JOIN-ов) и гибкостью. Важное отличие от обработки транзакций в реальном времени, здесь измерения — это не те же самые сущности, что в OLTP. Это просто списки уникальных значений контекста. Их назначение — фильтровать, группировать и давать названия.

Схема «Снежинка» (Snowflake): когда таблицы измерений начинают ссылаться на другие таблицы. Рекомендация: избегать этого, если есть возможность. Это усложняет работу BI-инструментов, хотя на небольших объемах может быть приемлемо.

Виды измерений:

Согласованные измерения — один и тот же справочник используется в разных таблицах фактов и его назначение, смысл и содержание согласован во всех бизнес-подразделениях. Это позволяет строить «галактику» — связывать данные из разных источников (например, расходы и нагрузку) по общим осям.

Измерение «Свалка» (Junk Dimension) — сборник комбинаций низкокардинальных атрибутов (статусы, флаги). Вместо десятка столбцов-флагов в таблице фактов вы создаете один справочник комбинаций. Это уменьшает размер таблицы и ускоряет работу.

Вырожденное измерение — атрибут, который не имеет собственной таблицы справочника (номер счета-фактуры, ИНН, серийный номер). Он хранится прямо в таблице фактов как строка. Такое измерение не нужно нормализовывать, потому что каждое значение уникально.

Измерение «Дата-время» — самый мощный и настоятельно рекомендуемый теорией справочник. В нем хранятся не просто даты, а все возможные атрибуты:

— день недели, номер недели в году;

— признак выходного/праздничного дня;

— квартал, месяц, декада;

— сезон (зима, весна, лето, осень);

— часть дня (утро, день, вечер, ночь);

— час, минута, секунда.

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

Заключение: ваша первая «звезда» на пути к FinOps

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

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

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

3. Стройте «звезду». Таблица фактов с числами и набор таблиц измерений с контекстом — это архитектурный паттерн, проверенный десятилетиями.

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

Узнайте больше о том, как Клаудмастер выстраивает FinOps-процессы, на примере наших кейсов.