AI Архитектура высоконагруженной платформы Magnit F&R

[AI]

О чем статья?


В статье Создание собственной системы F&R в «Магните»: функциональный дизайн было рассказано о том, что компания «Магнит» столкнулась с ограничениями существующих решений класса Forecast & Replenishment, по производительности, гибкости и скорости реакции.

Так мы решили создать собственное решение.

Я Алексей Соболеков, ИТ-архитектор в Magnit Tech, расскажу о ключевых архитектурных принципах и решениях Magnit F&R. Будет полезно Архитекторам, Техлидам, CTO, и всем, кто проектирует архитектуру высоконагруженных облачных решений на базе Open Source технологий.

Где место F&R в ИТ ландшафте компании?

F&R – это выделенная система в ИТ-ландшафте. Она:

1. 
   Загружает мастер-данные из корпоративных систем и систем планирования цепочек поставок;
   
   
2. 
   Загружает транзакции из учетных систем;
   
   
3. 
   Рассчитывает прогноз спроса и предложения по пополнению;
   
   
4. 
   Выгружает результаты в системы исполнения цепочек поставок – ERP, Backend магазинов, WMS.
   

F&R выступает в роли «мозгового центра» цепочек поставок, анализирует текущие запасы, прогнозирует будущий спрос и формирует заказы на закупку и распределение товаров по сети.

Какие принципы лежат в архитектуре?

TOGAF как методология управления корпоративной IT-архитектурой | CORS Academy | Дзен

Мы в «Магните» используем фреймворк TOGAF, согласно которому архитектура начинается с формирования видения, или принципов.

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

1. Полнота функционального покрытия

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

Архитектурные принципы:

• 
  Унифицированный интерфейс – единая точка входа с поддержкой совместной работы пользователей.
  
  
• 
  Комплексная модель данных – полное отражение состояния цепочки поставок с возможностью расширения.
  
  
• 
  Модульная полнота – исчерпывающий набор функций с открытой архитектурой для масштабирования.
  

Magnit F&R полностью заменит унаследованные системы автозаказа и обеспечит сквозное управление товарными запасами «Магнита».

2. Гибкость и адаптивность системы

Для сокращения time-to-market платформа должна предоставлять широкие настройки интерфейса и бизнес-логики.

Ключевые решения:

• 
  Создание платформы UI, настраиваемой пользователями.
  
  
• 
  Модульная архитектура UI на базе микросервисов и микро фронтендов.
  
  
• 
  Реализация self-service аналитики на базе готовых BI-решений с интеграцией в ClickHouse.
  
  
• 
  Применение Low-Code для расчета плана пополнения и рекомендаций заказов.
  

Такая архитектура обеспечивает гибкость бизнес-процессов без модификации ядра системы.

3. Производительность

Для обслуживания сети из 35 000 магазинов система должна обрабатывать экстремальные объемы данных в реальном времени.

Архитектурные принципы обеспечения производительности:

• 
  Выбор технологий только совместимых с облачными сервисами. Возможность гибкой утилизации ресурсов облака.
  
  
• 
  Поддержка кластеризации, шардирования и многопоточности. Отказ от технологий, не способных горизонтально масштабировать свою производительность.
  
  
• 
  Доменная организация модулей и данных решения. Низкая связанность модулей решения, деление продуктовых команд на стримы согласно модулям.
  
  
• 
  Централизованное управление бизнес-процессами и мониторинг всех технологических процессов Magnit F&R.
  

Платформа в себе сочетает:

• 
  Возможности BigData-платформ для обработки больших объемов
  
  
• 
  Характеристики операционных систем реального времени
  
  
• 
  Гибкость облачных решений
  

Подобные системы только начинают появляться на мировом рынке, что позиционирует Magnit F&R как технологического лидера в области планирования товарных запасов.

4. Отзывчивость

Система обеспечивать реакцию на события в цепочке поставок:

• 
  Реал-тайм мониторинг логистических событий по цепочке поставок, таких как приход товара, отгрузка, приемка, продажа и прочих;
  
  
• 
  Оперативный и точечный ad-hoc пересчет прогноза спроса и плана пополнения;
  
  
• 
  Детализация параметров пополнения и расчетов до уровня конкретного товара, магазина и дня.
  

Архитектурные принципы:

• 
  Модель данных и расчеты на уровне Товар-Локация-Период (день, час);
  
  
• 
  Возможность выборочного запуска модулей для произвольных товарных групп и магазинов;
  
  
• 
  Интеграция данных в Stream и Micro-batch режимах.
  

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

Это позволяет перевести систему в класс Intelligent Control Tower, где система управляет цепочкой поставок как диспетчерская вышка аэропорта движением самолетов.

Какие технологии и паттерны применяем?


Архитектуру Магнит F&R можно представить как несколько взаимосвязанных архитектурных слоев.

1. Бизнес-архитектура

Слой бизнес-архитектуры описывает как будет работать бизнес на еще не созданной системе. Это сложно. Город (система) еще не построен, но надо уже определить как люди должны в нем жить и работать.

Была определена целевая оргструктура и верхнеуровневые бизнес процессы. Специфичные процессы «Магнита» разделены на целевые ноу-хау и нецелевые, подлежащие замене на отраслевые. Сформировано 560+ функциональных и 150+ нефункциональных требований.

Это создало «конституцию» системы — четкие требования и стандарты для дальнейшей разработки.

2. Интерфейс пользователя

Для интерфейса пользователя выбрали архитектуру микро фронтендов на базе Webpack и Module Federation с общими библиотеками.

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

Для обмена данным применяются протоколы REST, GraphQL и WebSocket.

Выделены основные библиотеки UI:

• 
  Основное окно решения – это контейнер, отвечающий за общую разметку, стили, загрузку других модулей, навигацию и маршрутизацию запросов.
  
  
• 
  Библиотека компонентов содержит «кирпичики» системы, из которых строится приложение.
  
  
• 
  UI-конструктор интерфейса позволяет пользователям настраивать свои дашборды.
  
  
• 
  Конструктор процессов выполняет бизнес-процессы и генерирует уведомления.
  
  
• 
  Блок исключений выполняет фоновую работу по уведомлению пользователей.
  
  3. Бизнес – логика
  

Система поддерживает пользовательские правила расчетов, уведомлений, проверок. Правила описываются в стиле Low Code, далее они интерпретируются в соответствующих модулях системы.

Low Code применяется в тех модулях системы, где требуется максимальная гибкость, и при этом не критична для стабильности и производительности основных расчетов.

К таким модулям относятся:

• 
  уведомления пользователей,
  
  
• 
  первичное наполнение открываемых магазинов,
  
  
• 
  закупки под промоакции,
  
  
• 
  настройки методов и параметров расчетов,
  
  
• 
  валидация вводимых пользователями данных,
  
  
• 
  методики оптимизации запасов (страховые запасы, округление под под квант отборки, распределения, пополнение под промо и прочие, вариативные алгоритмы).
  
  4. Расчетные слои
  

Система имеет три основных расчетных модуля – Интеграция, Прогнозирование и Пополнение. При этом профиль их нагрузки и методики расчетов различаются.

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

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

5. Слой данных

В решении применяется несколько архитектурных стилей и технологий для организации данных.

Разнообразные системы-источники предоставляют данные, которые забираются различными ETL/ELT конвейерами. Они реализованы при помощи Debezium, Airtflow, SparkSQL, DBT, Kafka.

Далее данные обрабатываются по слоям согласно Data Lake архитектуре с использованием технологий Parquet, Delta.io, S3, Trino.

Для обеспечения совместной пакетной и потоковой обработки применяется Lambda-архитектура на базе Apache Flink.

А что с единой платформой?

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

• 
  Сроки
  

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

• 
  Требования
  

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

• 
  Технологии
  

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

• 
  Компетенции
  

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

• 
  Подходы
  

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

В итоге, эволюционным путем мы пришли к тому, что Magnit F&R является не единой платформой, а модульным решением, где есть платформенные модули: Платформа UX/UI и Общих сервисов, Платформы расчетов Пополнения и Прогнозирования и Платформа Общих данных (Интеграции).

Что в итоге получилось?

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

Каждая технология и паттерн выбраны из нескольких вариантов, рассмотрены альтернативы, проведены исследования Proof of Concept (PoC).

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

Ключевые советы:
1) Четкие архитектурные принципы, основанные на бизнес-требованиях, — это фундамент для масштабирования. Они помогают новым членам команды оценивать свои предложения через призму общих целей и решений. Это позволяет сохранять архитектурную целостность, избежать бесконечного перепроектирования и быстро достигать консенсуса.

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

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