MLOps mit Microservices: Eine Fallstudie im maritimen Bereich

Grundinformationen

• Paper-ID: 2506.06202
• Titel: MLOps with Microservices: A Case Study on the Maritime Domain
• Autoren: Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
• Institutionen: Jheronimus Academy of Data Science (JADS), Technische Universität Eindhoven (TUe), Universität Tilburg (TiU)
• Klassifizierung: cs.SE cs.AI cs.LG
• Veröffentlichungsdatum: arXiv:2506.06202v2 cs.SE 11. August 2025
• Paper-Link: https://arxiv.org/abs/2506.06202

Zusammenfassung

Diese Fallstudie beschreibt die Herausforderungen und Erkenntnisse beim Aufbau des Ocean Guard-Systems: ein maschinenlernengestütztes System (MLES) zur Anomalieerkennung im maritimen Bereich. Das Paper stellt zunächst die Systemspezifikation und Architektur vor. Ocean Guard nutzt eine Microservice-Architektur, die es mehreren Teams ermöglicht, parallel zu arbeiten. Anschließend wird erörtert, wie Entwickler vertragsbasiertes Design für MLOps adaptiert haben, um dies zu erreichen. Als MLES nutzt Ocean Guard Code-, Modell- und Datenverträge, um Richtlinien zwischen Services zu etablieren.

Forschungshintergrund und Motivation

Problemhintergrund

1. Beschleunigte digitale Transformation in der Schifffahrt: Nach der Internationalen Seeschifffahrtsorganisation (IMO) sind moderne Schiffe zu „schwimmenden Datenzentren" geworden, ausgestattet mit Hunderten von Sensoren, die große Mengen heterogener Daten erzeugen
2. Komplexe Betriebsumgebung: Der maritime Bereich ist durch kontinuierliche grenzüberschreitende Bewegung, vielfältige Regelungsrahmen und Anfälligkeit für Wetterbedingungen gekennzeichnet
3. Herausforderungen bei der Datenverarbeitung: Systeme müssen in der Lage sein, verschiedene Datenströme in großem Maßstab aufzunehmen, zu verarbeiten und zu analysieren, während sie in Umgebungen mit schnell wechselnder Konnektivität und Bedingungen betriebsfähig bleiben

Forschungsmotivation

1. Technologische Konvergenzanforderung: Kombination von MLOps-Best-Practices mit Microservice-Architektur zur Bewältigung von Anforderungen in den Bereichen Vorhersageanalyse, Anomalieerkennung und Routenoptimierung im maritimen Bereich
2. Zusammenarbeit mehrerer Teams: Unterstützung paralleler Entwicklung durch multidisziplinäre Teams aus Softwareingenieuren, Datenwissenschaftlern und Machine-Learning-Ingenieuren
3. Systemskalierbarkeit: Microservice-Architektur ist besonders geeignet für Modularität, Skalierbarkeit und Resilienz im maritimen Bereich

Kernbeiträge

1. Vorschlag einer vertragsgesteuerten Designmethode für MLES: Erweiterung des Konzepts der Codekontrakte aus Microservices auf Datenkontrakte und Modellkontrakte
2. Aufbau einer vollständigen Architektur für maritime Anomalieerkennung: Ocean Guard-System basierend auf Microservices mit Unterstützung für parallele Entwicklung mehrerer Teams
3. Validierung der Anwendung von DDD in MLOps: Schaffung einer gemeinsamen Sprache durch Domain-Driven Design zur Verbesserung der Kommunikation zwischen multidisziplinären Teams
4. Bereitstellung praktischer Erfahrungen bei der MLES-Entwicklung: Identifikation und Bewältigung von drei Hauptherausforderungen: Kopplung, Ausrichtung und Kommunikation

Methodische Details

Systemspezifikation

Funktionale Anforderungen

Investigator-Funktionalität:

• I1-I6: Geografische Standortanzeige, Filterung, Objekttypidentifikation, Multi-Datenquellen-Abruf, Metadaten-Anzeige, Trajektorienverfolgung
• I7-I9: Anomaliehighlighting, Anomaliefilterung, Anomalieerklärungsanzeige

Anomalieerkenner-Funktionalität:

• A1-A3: Anomalieerkennung, Anomalieaufzählung, Anomalieerklärung

Nicht-funktionale Anforderungen

1. Interpretierbarkeit: Verwendung interpretierbarer Modelle oder Black-Box-Erklärungstechniken (SHAP, LIME)
2. Kompatibilität: Einhaltung von EU-Standards, Unterstützung schneller Integration mit anderen Systemen
3. Resilienz: Verarbeitung hochvolumiger, hochfrequenter Datenquellen
4. Compliance: Einhaltung europäischer Vorschriften wie GDPR und AI Act

Systemarchitektur

Design von fünf Subsystemen

1. Datenerfassung (Data Acquisition)
   • Drittanbieter (1), physische Sensoren (2), Daten-Crawler (3)
   • Beschriftungsspeicher (A) und Rohdatenspeicher (B)
2. Kontinuierliches Training (Continuous Training)
   • Pipeline zur Synthese-Datengenerierung (I), Datenerweiterungs-Pipeline (II)
   • Regelbasierte Trainings-Pipeline (III), ML-basierte Trainings-Pipeline (IV)
   • Metadatenspeicher (F) und Modellregister (G)
3. Serving
   • Batch-Vorhersage-Pipeline (VIII) und API-Vorhersage-Service (8)
   • Vorhersagespeicher (H)
4. Überwachung (Monitoring)
   • Governance-Anwendung (7) und Telemetrie-Speicher (I)
5. Kontinuierliche Bereitstellung (Continuous Delivery)
   • CI-Pipeline (V), CD-Pipeline (VI), CD4ML-Pipeline (VII)
   • Artefakt-Register (D)

API-Architektur-Design

Verwendung der Hexagonalen Architektur (Hexagonal Architecture):

1. Kern (Core): Implementierung der Geschäftslogik nach DDD-Muster
   • Entitäten (Entities), Wertobjekte (Value Objects)
   • Aggregate, Services
2. Ports: Etablierung von Verträgen zwischen Kern und Adaptern
   • Datenbank-Repositories, Dependency Injection, Sicherheitsmechanismen, Web-Router
3. Adapter: Kommunikation mit externen Abhängigkeiten
   • Eingabe-Adapter: Modelle, Drittanbieter-APIs, Speicher, Datenbanken, Konfiguration
   • Ausgabe-Adapter: Web, Cache

Team-Konfiguration und Arbeitsablauf

Technische Innovationen

Vertragsgesteuerte Entwicklung (Contract-Based Development)

1. Codekontrakte (Code Contracts)

• Definition: Dokumentation des synchronen/asynchronen Interaktionsverhaltens zwischen zwei Services über HTTP-Protokoll
• Anwendungsszenarien:
  • Vertrag zwischen Daten-Crawler und externen Datenquellen
  • Vertrag zwischen API-Vorhersage-Service und Web-Anwendung

2. Datenkontrakte (Data Contracts)

• Definition: Dokumentation des erwarteten Formats in Datenspeichern, einschließlich Typ, Format, Verteilung und Lese-/Schreibprotokollen
• Anwendungsszenarien:
  • Vertrag zwischen Produzent und Konsument des Beschriftungsspeichers
  • Multi-Party-Verträge des Rohdatenspeichers
  • Verträge zwischen Pipelines verarbeiteter Daten

3. Modellkontrakte (Model Contracts)

• Definition: Dokumentation der erwarteten Ein- und Ausgaben sowie des Speicherformats von Modellen
• Anwendungsszenarien: Verträge zwischen Trainings-Pipelines und Vorhersage-Services im Modellregister

Ubiquitäre Sprache (Ubiquitous Language)

Schaffung gemeinsamer Vokabeln über Teams hinweg durch DDD zur Verbesserung von:

• Verständnis zwischen Stakeholdern und Entwicklern
• Ausrichtung zwischen Teams
• Erklärung von Daten- und Modellkonzepten

Experimentelle Einrichtung

Entwicklungsumgebung

• Code-Repository: Zentralisierte Quellcodeverwaltung
• Entwicklungswerkzeuge: IDE (4) für strukturierte Softwareentwicklung, Notebooks (5) für interaktive Prototypisierung und Analyse
• CI/CD: Continuous-Integration-Pipeline, Continuous-Delivery-Pipeline, ML-Continuous-Delivery-Pipeline

Deployment-Architektur

• Containerisierung: Verwendung von Artefakt-Registern zur Verwaltung versionierter Softwarekomponenten
• Scheduling-Service: Koordination der Komponentenausführung
• Überwachungssystem: Governance-Anwendung überwacht Modell- und Systemnutzung

Herausforderungen und Lösungen

Drei Hauptherausforderungen

1. Kopplung (Coupling)
   • Problem: Systemkomplexität führt dazu, dass Änderungen an Komponenten leicht kaskadierende Auswirkungen haben
   • Lösung: Reduzierung von Integrationsproblemen durch vertragsgesteuerte Designmethode
2. Ausrichtung (Alignment)
   • Problem: Koordinierungsherausforderungen bei paralleler Arbeit von vier Fachteams
   • Lösung: Klare Grenzendefinition, CI/CD-Pipeline-Integration
3. Kommunikation (Communication)
   • Problem: Erklärung der Systemevolution gegenüber Stakeholdern mit unterschiedlichem technischem Hintergrund
   • Lösung: Etablierung einer gemeinsamen Sprache durch DDD

Lösungseffektivität

Verwandte Arbeiten

MLOps-Feldentwicklung

• Ab 2022: Mehrere MLES-Referenzarchitekturen wurden vorgeschlagen
• SE4AI: Aufstrebendes Feld der Anpassung von Softwareengineering-Techniken für KI-Systeme
• Systemkomponentisierung: MLES werden als Systeme mit mehreren Komponenten beschrieben, die über Services verteilt werden können

Microservice-Architektur

• Ab 2015: Aufstieg des Microservice-Architekturstils zur Bewältigung von Modularität, Skalierbarkeit und Resilienz
• Maritime Anwendbarkeit: Spezialisierte Komponenten zur Verarbeitung verschiedener maritimer Datenquellen und Analyseanforderungen

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

1. Architektur-Effektivität: Microservice-Architektur unterstützt erfolgreich die parallele Entwicklung von MLES durch multidisziplinäre Teams
2. Vertrag-Erweiterung: Das Konzept der Codekontrakte aus Microservices wurde erfolgreich auf Daten- und Modelldimensionen erweitert
3. DDD-Anwendbarkeit: Domain-Driven Design verbessert effektiv die Kommunikation und Koordination zwischen multidisziplinären Teams
4. Herausforderungsbewältigung: Vertragsgesteuerte Designmethode und ubiquitäre Sprache bewältigen effektiv die Herausforderungen von Kopplung, Ausrichtung und Kommunikation

Einschränkungen

1. Sensibilitätsbeschränkungen: Aufgrund der Projektempfindlichkeit behandelt das Paper keine spezifischen Datenmodelle und Anomalieerkenntechniken
2. Akademische Beschränkungen: Forschungs- und Innovationsteams bestehen aus Studierenden und unterliegen akademischen Fristen
3. Implementierungsphase: Das System befindet sich noch in der Entwicklung und fehlt langfristige Validierung in Produktionsumgebungen

Zukünftige Richtungen

1. Funktionsvervollständigung: Fortgesetzte Entwicklung zur Erfüllung aller funktionalen und nicht-funktionalen Anforderungen
2. Technische Erforschung: Fortgesetzte Erforschung von Spitzen- und praktischen Technologien mit Forschungs- und Innovationsteams
3. Architektur-Evolution: Architektur-Entwicklung unter Anleitung der etablierten Vertragsmethode und ubiquitären Sprache

Tiefgreifende Bewertung

Stärken

1. Hoher praktischer Wert: Bietet eine vollständige Fallstudie zur Kombination von MLOps und Microservices
2. Methodische Innovation: Die Erweiterung der vertragsgesteuerten Designmethode auf Daten- und Modelldimensionen ist originell
3. Vollständige Architektur: Umfassende Systemarchitektur-Design, das alle Aspekte von MLES abdeckt
4. Team-Zusammenarbeit: Erfolgreiche Bewältigung der Herausforderungen paralleler Entwicklung durch multidisziplinäre Teams
5. Praktische Orientierung: Bietet nachahmenswerte Erfahrungen und Erkenntnisse für ähnliche Projekte

Schwächen

1. Begrenzte technische Tiefe: Aufgrund von Sensibilitätsbeschränkungen fehlen spezifische ML-Algorithmen und Datenverarbeitungsdetails
2. Unzureichende Evaluierung: Fehlende quantitative Bewertung von Systemleistung und Skalierbarkeit
3. Fehlende Langzeitvalidierung: System hat noch nicht lange in Produktionsumgebungen gelaufen
4. Unzureichende Vergleichsanalyse: Fehlende Vergleichsanalyse mit anderen MLES-Architekturlösungen

Auswirkungen

1. Feldbeitrag: Bietet wichtige praktische Referenzen für die Kombination von MLOps und Microservices
2. Methodologischer Wert: Die Erweiterung der vertragsgesteuerten Designmethode hat breite Anwendbarkeit
3. Ingenieurpraxis: Bietet effektive Muster für Team-Zusammenarbeit in komplexen MLES
4. Reproduzierbarkeit: Architektur-Design und Methodik haben gute Reproduzierbarkeit

Anwendungsszenarien

1. Multi-Team-MLES-Entwicklung: Maschinenlern-Systeme, die parallele Entwicklung durch mehrere Fachteams erfordern
2. Komplexe Datenverarbeitung: Systemarchitektur-Design mit mehreren heterogenen Datenquellen
3. Hohe Compliance-Anforderungen: Branchenanwendungen mit strengem Regelungsrahmen
4. Skalierbare Systeme: ML-Systemarchitekturen mit hohem Grad an Modularität und Skalierbarkeit

Literaturverzeichnis

Das Paper zitiert 17 wichtige Literaturquellen, die folgende Bereiche abdecken:

• Forschung zur digitalen Transformation in der Schifffahrt
• Best-Practices in Microservice-Architektur und MLOps
• Softwareengineering-Methoden (DDD, Hexagonale Architektur)
• Machine-Learning-Systemtechnik (SE4AI)

Zusammenfassung: Dieses Paper demonstriert durch die Ocean Guard-Fallstudie erfolgreich die Anwendung von Microservice-Architektur in MLOps, insbesondere den Wert der vertragsgesteuerten Designmethode in der Multi-Team-Zusammenarbeit. Obwohl aufgrund von Sensibilitätsbeschränkungen keine tiefgreifenden technischen Details behandelt werden, sind die methodologischen Beiträge und praktischen Orientierungswerte erheblich und bieten wertvolle Architektur-Design- und Team-Zusammenarbeitserfahrungen für ähnliche komplexe MLES-Projekte.