Message-Queue-Architektur für hochdurchsatzfähige Verteidigungsdaten-Pipelines

Ein modernes taktisches Operationszentrum der Bundeswehr empfängt Daten von Dutzenden von Sensor-Feeds gleichzeitig: Radar-Spuraktualisierungen jede Sekunde, AIS-Schiffspositionen alle 30 Sekunden, Drohnen-Video-Metadaten mit 30 Bildern pro Sekunde, Link-16-Netzwerknachrichten in unregelmäßigen Abständen, SIGINT-Emitter-Erkennungen wenn sie auftreten, und Geheimdienstberichte nach einem unvorhersehbaren Zeitplan. Eine synchrone Anfrage-Antwort-Architektur, bei der jede Komponente auf den Abschluss der vorherigen wartet, bevor sie fortfährt, kann diese Last nicht bewältigen. Das Ergebnis sind verlorene Daten, Verarbeitungsstaus während Spitzenaktivitäten und Systeminstabilität in den Momenten, in denen Zuverlässigkeit am wichtigsten ist. Message-Queue-Architektur entkoppelt Produzenten von Konsumenten, absorbiert Spitzenlast in persistente Puffer und erlaubt jeder Verarbeitungskomponente, in ihrem eigenen Tempo zu arbeiten, ohne andere zu blockieren.

Das Produzenten-Konsumenten-Modell für die Sensoraufnahme

In einer Message-Queue-Architektur ist jede Datenquelle ein Produzent, der Nachrichten an eine benannte Warteschlange oder ein Topic veröffentlicht, ohne auf eine Bestätigung von nachgelagerten Konsumenten zu warten. Jede Verarbeitungskomponente ist ein Konsument, der aus Warteschlangen mit der Rate liest, die er aufrechterhalten kann. Der Nachrichtenbroker — Apache Kafka, RabbitMQ oder ein cloud-natives Äquivalent — speichert Nachrichten dauerhaft, bis Konsumenten sie bestätigen, und bietet so einen Puffer, der das Missverhältnis zwischen Produktions- und Konsumraten absorbiert.

Für ein Bundeswehr-Sensor-Fusionssystem bedeutet dies direkt: Der Radar-Track-Ingestor veröffentlicht eine TrackUpdated-Nachricht an das Tracks-Topic jedes Mal, wenn ein neuer Radarbericht eintrifft. Der Track-Fusionsprozessor abonniert das Tracks-Topic und verarbeitet Nachrichten so schnell wie möglich — wenn ein Burst von 500 Tracks in einer Sekunde eintrifft, sammeln sich die Nachrichten im Topic an und der Fusionsprozessor arbeitet sie durch, ohne eine davon zu verwerfen. Die Operationsbild-Anzeige abonniert das Fused-Tracks-Topic und aktualisiert sich mit der Rate, mit der die Benutzeroberfläche rendern kann, unabhängig davon, wie schnell die Fusionsmaschine arbeitet.

Apache Kafka für Bundeswehr-Datenpipelines

Apache Kafka ist zur dominanten Nachrichten-Streaming-Plattform für hochdurchsatzfähige Datenpipelines geworden, und seine Architektur entspricht gut den Verteidigungsanforderungen. Ein Kafka-Cluster besteht aus mehreren Broker-Knoten, von denen jeder einen Teil der Topic-Partitionen speichert. Topic-Partitionen sind die Einheit der Parallelität. Für die Sensoraufnahme der Bundeswehr empfiehlt der Design-Ansatz die Verwendung des Datentyps als primäre Partitionierungsdimension: ein Radar-Tracks-Topic, ein AIS-Positions-Topic, ein ADS-B-Tracks-Topic, ein SIGINT-Detections-Topic, ein Intelligence-Reports-Topic.

Das Log-Compaction-Feature von Kafka ist für Tracks wertvoll: wenn Log Compaction für ein Topic aktiviert ist, behält Kafka nur die neueste Nachricht für jeden Partition-Key und verwirft Zwischenaktualisierungen. Für einen Konsumenten, der startet und seinen In-Memory-Zustand initialisieren muss, bedeutet Log Compaction, dass er das verdichtete Topic lesen und den aktuellen Zustand jedes Tracks erhalten kann, ohne die gesamte Aktualisierungshistorie wiedergeben zu müssen.

RabbitMQ für C2-Nachrichtenrouting

Kafka glänzt bei hochdurchsatzfähigem Streaming, ist jedoch nicht für komplexe Routing-Logik optimiert. RabbitMQ bietet einen anderen Trade-off: niedrigerer Durchsatz, aber anspruchsvolles Exchange-Routing. Für das C2-Nachrichtenrouting der Bundeswehr sind Topic-Exchanges besonders nützlich. Eine Nachricht mit dem Routing-Key «alert.track.hostile» wird an Warteschlangen mit den Mustern «alert.#» (alle Warnungen), «alert.track.#» (alle Spurwarnungen) und «alert.track.hostile» (nur feindliche Spurwarnungen) zugestellt, ohne dass der Publisher die Konsumenten kennt.

Stream Processing: Apache Kafka Streams und Flink

Das Veröffentlichen von Sensordaten in Topics und deren Konsumierung zur Anzeige ist der Grundfall. Die leistungsfähigere Fähigkeit ist stateful Stream Processing: Transformation von Rohsensordaten in abgeleitete Geheimdienstprodukte in Echtzeit. Apache Kafka Streams ist eine Client-Bibliothek, die Java/Kotlin-Anwendungen ermöglicht, Verarbeitungstopologien über Kafka-Topics zu definieren. Apache Flink ist ein verteiltes Stream-Processing-Framework, das für komplexere stateful Berechnungen geeignet ist. Flinks Checkpoint-Mechanismus persistiert den Operator-Zustand periodisch in dauerhaftem Speicher und ermöglicht so die Wiederherstellung nach einem Ausfall ohne Wiedergabe des gesamten Eingabestroms.

Sicherheitsüberlegungen für die Bundeswehr-Nachrichteninfrastruktur

Bundeswehr-Nachrichtenbroker-Bereitstellungen erfordern gegenseitige TLS-Authentifizierung (sowohl der Broker als auch jeder Client authentifizieren sich mit Zertifikaten), Topic-Level-Autorisierung (ein Radar-Ingestor-Prozess sollte in der Lage sein, an das Radar-Tracks-Topic zu produzieren, aber nicht aus dem Intelligence-Reports-Topic zu lesen) sowie Verschlüsselung im Ruhezustand. Netzwerksegmentierung ist ebenso wichtig: Der Nachrichtenbroker-Cluster sollte sich in einem Netzwerksegment befinden, das sowohl für Produzenten- als auch für Konsumenten-Komponenten zugänglich ist, aber nicht direkt von externen Netzwerken oder Benutzerarbeitsstationen.