Architektura kolejki komunikatów dla wysokoprzepustowych potoków danych obronnych

Nowoczesne taktyczne centrum operacyjne MON odbiera dane z dziesiątek strumieni sensorów jednocześnie: aktualizacje torów radarowych co sekundę, pozycje statków AIS co 30 sekund, metadane wideo drona z prędkością 30 klatek na sekundę, komunikaty sieci Link 16 w nieregularnych odstępach czasu, wykrycia emiterów SIGINT gdy one nastąpią, oraz raporty wywiadowcze według nieprzewidywalnego harmonogramu. Synchroniczna architektura żądanie-odpowiedź, w której każdy komponent czeka na zakończenie poprzedniego przed kontynuowaniem, nie może wytrzymać tego obciążenia. Rezultatem są utracone dane, zatory przetwarzania podczas szczytowej aktywności oraz niestabilność systemu dokładnie w momentach, gdy niezawodność jest najważniejsza. Architektura kolejki komunikatów oddziela producentów od konsumentów, pochłania obciążenia szczytowe do trwałych buforów i pozwala każdemu komponentowi przetwarzania działać we własnym tempie bez blokowania innych.

Model producent-konsument dla pozyskiwania danych sensorów

W architekturze kolejki komunikatów każde źródło danych jest producentem, który publikuje komunikaty do nazwanej kolejki lub tematu bez oczekiwania na potwierdzenie od konsumentów poniżej. Każdy komponent przetwarzania jest konsumentem, który czyta z kolejek z jakąkolwiek szybkością, jaką może utrzymać. Broker komunikatów — Apache Kafka, RabbitMQ lub chmurowy odpowiednik — przechowuje komunikaty trwale do momentu ich potwierdzenia przez konsumentów, zapewniając bufor pochłaniający niedopasowanie między szybkościami produkcji i konsumpcji.

Dla systemu fuzji sensorów SZ RP oznacza to bezpośrednio: ingestor torów radarowych publikuje komunikat TrackUpdated do tematu torów za każdym razem, gdy napływa nowy raport radarowy. Procesor fuzji torów subskrybuje temat torów i przetwarza komunikaty tak szybko, jak może — jeśli w ciągu jednej sekundy napłynie seria 500 torów, komunikaty gromadzą się w temacie i procesor fuzji przetwarza je bez upuszczania żadnego. Wyświetlacz obrazu operacyjnego subskrybuje temat scalonych torów i odświeża się z jakąkolwiek szybkością, z jaką interfejs może renderować, niezależnie od tego, jak szybko działa silnik fuzji.

Apache Kafka dla potoków danych obronnych MON

Apache Kafka stał się dominującą platformą strumieniową komunikatów dla potoków danych o wysokiej przepustowości, a jego architektura dobrze odpowiada wymaganiom obronnym. Klaster Kafka składa się z wielu węzłów brokerów, z których każdy przechowuje część partycji tematów. Partycje tematów są jednostką równoległości: temat z 12 partycjami może być konsumowany przez do 12 równoległych instancji konsumenta w grupie konsumentów, z których każda przetwarza podzbiór partycji.

Dla pozyskiwania sensorów MON zalecany projekt tematu używa typu danych jako głównego wymiaru partycjonowania: temat torów radarowych, temat pozycji AIS, temat torów ADS-B, temat wykryć SIGINT, temat raportów wywiadowczych. W ramach każdego tematu kluczem partycji powinien być identyfikator toru lub encji, zapewniając, że wszystkie komunikaty dla danego toru są przetwarzane przez tę samą instancję konsumenta — jest to krytyczne dla stanowego przetwarzania strumieniowego, które utrzymuje stan dla każdego toru.

RabbitMQ dla routingu komunikatów C2

Kafka doskonale sprawdza się przy wysokoprzepustowym przesyłaniu strumieniowym, ale nie jest zoptymalizowana pod kątem złożonej logiki routingu. RabbitMQ zapewnia inny kompromis: niższa przepustowość, ale zaawansowany routing wymiany. Wymiany RabbitMQ implementują cztery tryby routingu — bezpośredni, fanout, temat i nagłówki. Dla routingu komunikatów C2 MON/SZ RP wymiany tematów są szczególnie przydatne, umożliwiając systemowi fuzji nadzoru publikowanie jednego komunikatu alertu i automatyczne dostarczanie go do centrum operacyjnego, terminala punktu dowodzenia dowódcy i systemu dziennika alertów — bez wiedzy wydawcy o konsumentach.

Przetwarzanie strumieniowe: Apache Kafka Streams i Flink

Publikowanie danych sensorów do tematów i ich konsumowanie do wyświetlania to podstawowy przypadek. Bardziej zaawansowaną możliwością jest stanowe przetwarzanie strumieniowe: przekształcanie surowych danych sensorów w pochodne produkty wywiadowcze w czasie rzeczywistym. Apache Kafka Streams to biblioteka kliencka, która pozwala aplikacjom Java/Kotlin definiować topologie przetwarzania nad tematami Kafka. Apache Flink to rozproszony framework przetwarzania strumieniowego odpowiedni do bardziej złożonych obliczeń stanowych. Mechanizm punktów kontrolnych Flink periodycznie utrwala stan operatora do trwałego magazynu, umożliwiając odzyskiwanie po awarii bez odtwarzania całego strumienia wejściowego.

Zagadnienia bezpieczeństwa dla obronnej infrastruktury komunikatów

Wdrożenia brokerów komunikatów MON wymagają wzajemnego uwierzytelniania TLS (zarówno broker, jak i każdy klient uwierzytelniają się za pomocą certyfikatów), autoryzacji na poziomie tematu (proces ingestora radarowego powinien móc produkować do tematu torów radarowych, ale nie czytać z tematu raportów wywiadowczych) oraz szyfrowania danych w spoczynku. Segmentacja sieci jest równie ważna: klaster brokerów komunikatów powinien znajdować się w segmencie sieci dostępnym zarówno dla komponentów producenta, jak i konsumenta, ale nie bezpośrednio dostępnym z sieci zewnętrznych.