MLOps с микросервисами: Тематическое исследование в морской области

Основная информация

• ID статьи: 2506.06202
• Название: MLOps with Microservices: A Case Study on the Maritime Domain
• Авторы: Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
• Учреждения: Jheronimus Academy of Data Science (JADS), Eindhoven University of Technology (TUe), Tilburg University (TiU)
• Классификация: cs.SE cs.AI cs.LG
• Дата публикации: arXiv:2506.06202v2 cs.SE 11 Aug 2025
• Ссылка на статью: https://arxiv.org/abs/2506.06202

Аннотация

Данное тематическое исследование описывает проблемы и извлеченные уроки при разработке системы Ocean Guard — системы, включающей машинное обучение (MLES) для обнаружения аномалий в морской области. В статье сначала представлены спецификация и архитектура системы. Ocean Guard использует архитектуру микросервисов, позволяющую нескольким командам работать параллельно. Затем обсуждается, как разработчики адаптировали проектирование на основе контрактов для MLOps с целью достижения этой цели. Как MLES, Ocean Guard использует контракты кода, модели и данных для установления руководящих принципов между сервисами.

Предпосылки исследования и мотивация

Контекст проблемы

1. Ускорение цифровой трансформации в морской отрасли: Согласно Международной морской организации (IMO), современные суда стали "плавающими центрами обработки данных", оснащенными сотнями датчиков, генерирующих большие объемы разнородных данных
2. Сложная операционная среда: Морская область характеризуется постоянным движением через границы, разнообразными нормативно-правовыми базами, подверженностью влиянию погодных условий
3. Проблемы обработки данных: Требуется система, способная масштабируемо получать, обрабатывать и анализировать различные потоки данных, сохраняя при этом операционную надежность в условиях быстро меняющейся связности

Мотивация исследования

1. Потребность в технологической интеграции: Объединение лучших практик MLOps с архитектурой микросервисов для решения задач прогнозной аналитики, обнаружения аномалий и оптимизации маршрутов в морской области
2. Многопрофильное сотрудничество: Необходимость поддержки параллельной разработки командами инженеров-программистов, специалистов по данным и инженеров машинного обучения
3. Масштабируемость системы: Архитектура микросервисов особенно подходит для требований модульности, масштабируемости и устойчивости морской области

Основные вклады

1. Предложен метод проектирования на основе контрактов, применимый к MLES: Расширение концепции контрактов кода из микросервисов на контракты данных и модели
2. Построена полная архитектура системы обнаружения аномалий в морской области: Система Ocean Guard на основе микросервисов, поддерживающая параллельную разработку несколькими командами
3. Проверена применимость DDD в MLOps: Использование проектирования, управляемого доменом, для создания единого языка, улучшающего коммуникацию между многопрофильными командами
4. Предоставлены практические опыт разработки MLES: Выявлены и решены три основных вызова: связанность, согласованность и коммуникация

Подробное описание методологии

Спецификация системы

Функциональные требования

Функциональность Investigator (Исследователь):

• I1-I6: отображение географического положения, фильтрация, идентификация типов объектов, извлечение из нескольких источников данных, просмотр метаданных, отслеживание траектории
• I7-I9: выделение аномалий, фильтрация аномалий, просмотр объяснений аномалий

Функциональность Anomaly Detector (Детектор аномалий):

• A1-A3: обнаружение аномалий, перечисление аномалий, объяснение аномалий

Нефункциональные требования

1. Интерпретируемость: Использование интерпретируемых моделей или методов объяснения черного ящика (SHAP, LIME)
2. Совместимость: Соответствие стандартам ЕС, поддержка быстрой интеграции с другими системами
3. Устойчивость: Обработка источников данных с высокой емкостью и высокой скоростью
4. Соответствие нормативным требованиям: Соответствие европейским нормативным актам, включая GDPR и AI Act

Архитектура системы

Проектирование пяти подсистем

1. Получение данных (Data Acquisition)
   • Поставщики третьих сторон (1), физические датчики (2), веб-скреперы данных (3)
   • Хранилище меток (A) и хранилище сырых данных (B)
2. Непрерывное обучение (Continuous Training)
   • Конвейер синтеза данных (I), конвейер увеличения данных (II)
   • Конвейер обучения на основе правил (III), конвейер обучения на основе ML (IV)
   • Хранилище метаданных (F) и реестр моделей (G)
3. Обслуживание (Serving)
   • Конвейер пакетного прогнозирования (VIII) и служба прогнозирования API (8)
   • Хранилище прогнозов (H)
4. Мониторинг (Monitoring)
   • Приложение управления (7) и хранилище телеметрии (I)
5. Непрерывная доставка (Continuous Delivery)
   • Конвейер CI (V), конвейер CD (VI), конвейер CD4ML (VII)
   • Реестр артефактов (D)

Проектирование архитектуры API

Использование шестиугольной архитектуры (Hexagonal Architecture):

1. Ядро (Core): Реализация бизнес-логики в соответствии с паттерном DDD
   • Сущности (Entities), объекты-значения (Value Objects)
   • Агрегаты (Aggregates), сервисы (Services)
2. Порты (Ports): Установление контрактов между ядром и адаптерами
   • Репозитории баз данных, внедрение зависимостей, механизмы безопасности, маршрутизаторы веб-приложений
3. Адаптеры (Adapters): Коммуникация с внешними зависимостями
   • Входные адаптеры: модели, API третьих сторон, хранилища, базы данных, конфигурация
   • Выходные адаптеры: веб-приложения, кэширование

Конфигурация команд и рабочие процессы

Технические инновации

Проектирование на основе контрактов (Contract-Based Development)

1. Контракты кода (Code Contracts)

• Определение: Документирование поведения синхронного/асинхронного взаимодействия между двумя сервисами через протокол HTTP
• Сценарии применения:
  • Контракты между веб-скреперами данных и внешними источниками данных
  • Контракты между службой прогнозирования API и веб-приложением

2. Контракты данных (Data Contracts)

• Определение: Документирование ожидаемого формата в хранилищах данных, включая типы, форматы, распределение и протоколы чтения-записи
• Сценарии применения:
  • Контракты между производителем и потребителем хранилища меток
  • Многосторонние контракты хранилища сырых данных
  • Контракты между конвейерами обработанных данных

3. Контракты модели (Model Contracts)

• Определение: Документирование ожидаемых входных/выходных данных модели и формата хранения
• Сценарии применения: Контракты между конвейерами обучения и службами прогнозирования в реестре моделей

Единый язык (Ubiquitous Language)

Создание общего словаря между командами через DDD, улучшающее:

• Понимание между заинтересованными сторонами и разработчиками
• Согласованность между командами
• Объяснение концепций данных и моделей

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

Среда разработки

• Репозиторий кода: Централизованное управление исходным кодом
• Инструменты разработки: IDE (4) для структурированной разработки программного обеспечения, Notebooks (5) для интерактивного прототипирования и анализа
• CI/CD: Конвейер непрерывной интеграции, конвейер непрерывной доставки, конвейер ML непрерывной доставки

Архитектура развертывания

• Контейнеризация: Использование реестра артефактов для управления версионированными компонентами программного обеспечения
• Служба планирования: Координация выполнения компонентов
• Система мониторинга: Приложение управления для мониторинга использования моделей и системы

Вызовы и решения

Три основных вызова

1. Связанность (Coupling)
   • Проблема: Сложность системы приводит к каскадному влиянию изменений компонентов
   • Решение: Снижение проблем интеграции через проектирование на основе контрактов
2. Согласованность (Alignment)
   • Проблема: Проблемы координации при параллельной работе четырех профессиональных команд
   • Решение: Четкое определение границ, интеграция конвейеров CI/CD
3. Коммуникация (Communication)
   • Проблема: Объяснение эволюции системы заинтересованным сторонам с различным техническим опытом
   • Решение: Установление единого языка через DDD

Эффективность решений

Связанные работы

Развитие области MLOps

• С 2022 года: Предложены несколько эталонных архитектур MLES
• SE4AI: Новая область адаптации методов программной инженерии для создания систем с ИИ
• Компонентизация систем: MLES описываются как содержащие несколько компонентов, распределяемых между сервисами

Архитектура микросервисов

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

Заключение и обсуждение

Основные выводы

1. Эффективность архитектуры: Архитектура микросервисов успешно поддержала параллельную разработку MLES многопрофильными командами
2. Расширение контрактов: Концепция контрактов кода из микросервисов успешно расширена на измерения данных и моделей
3. Применимость DDD: Проектирование, управляемое доменом, эффективно улучшило коммуникацию и координацию между многопрофильными командами
4. Решение вызовов: Проектирование на основе контрактов и единый язык эффективно решили вызовы связанности, согласованности и коммуникации

Ограничения

1. Ограничения конфиденциальности: Из-за конфиденциальности проекта статья не охватывает конкретные модели данных и методы обнаружения аномалий
2. Академические ограничения: Исследовательская и инновационная команды состоят из студентов, ограниченных академическими сроками
3. Этап реализации: Система все еще находится в разработке, отсутствует долгосрочная проверка в производственной среде

Будущие направления

1. Функциональное совершенствование: Продолжение разработки для удовлетворения всех функциональных и нефункциональных требований
2. Технологическое исследование: Продолжение изучения передовых и практических технологий с исследовательской и инновационной командами
3. Эволюция архитектуры: Направление процесса разработки на основе установленных методов контрактов и единого языка

Глубокая оценка

Преимущества

1. Высокая практическая ценность: Предоставляет полное тематическое исследование объединения MLOps и микросервисов
2. Методологическая инновация: Расширение проектирования на основе контрактов на измерения данных и моделей обладает оригинальностью
3. Полнота архитектуры: Проектирование архитектуры системы всеобъемлюще охватывает все аспекты MLES
4. Командное сотрудничество: Успешное решение проблем параллельной разработки многопрофильными командами
5. Практическое руководство: Предоставляет опыт и уроки, применимые к аналогичным проектам

Недостатки

1. Ограниченная техническая глубина: Из-за ограничений конфиденциальности отсутствуют конкретные детали алгоритмов ML и обработки данных
2. Недостаточная оценка: Отсутствуют количественные оценки производительности системы, масштабируемости и т.д.
3. Отсутствие долгосрочной проверки: Система еще не прошла долгосрочную проверку в производственной среде
4. Недостаточный сравнительный анализ: Отсутствует сравнение с другими решениями архитектуры MLES

Влияние

1. Вклад в область: Предоставляет важный практический справочник для объединения MLOps и микросервисов
2. Методологическая ценность: Расширение проектирования на основе контрактов имеет широкую применимость
3. Инженерная практика: Предоставляет эффективные модели командного сотрудничества для сложных MLES
4. Воспроизводимость: Проектирование архитектуры и методология обладают хорошей воспроизводимостью

Применимые сценарии

1. Разработка многокомандных MLES: Системы машинного обучения, требующие параллельной разработки несколькими профессиональными командами
2. Сложная обработка данных: Архитектура систем, включающих многоисточные разнородные данные
3. Высокие требования соответствия: Приложения в отраслях с жесткими нормативными требованиями
4. Масштабируемые системы: Архитектура ML систем, требующих высокой модульности и масштабируемости

Библиография

Статья цитирует 17 важных работ, охватывающих:

• Исследования цифровой трансформации в морской области
• Лучшие практики архитектуры микросервисов и MLOps
• Методологию программной инженерии (DDD, шестиугольная архитектура)
• Инженерия систем машинного обучения (SE4AI)

Резюме: Данная статья посредством тематического исследования Ocean Guard успешно демонстрирует применение архитектуры микросервисов в MLOps, особенно ценность проектирования на основе контрактов в многокомандном сотрудничестве. Хотя ограничения конфиденциальности препятствуют углубленному рассмотрению технических деталей, методологический вклад и практическая ценность статьи значительны, предоставляя ценный опыт архитектурного проектирования и командного сотрудничества для аналогичных сложных проектов MLES.