О чем статья?

В статье Создание собственной системы 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, согласно которому архитектура начинается с формирования видения, или принципов. 

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

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