Arhitectura cozilor de mesaje pentru pipeline-uri de date de apărare de mare capacitate

Un centru de operații tactice modern primește date de la zeci de fluxuri de senzori simultan: urme radar actualizate în fiecare secundă, poziții de nave AIS la fiecare 30 de secunde, metadate video drone la 30 de cadre pe secundă, mesaje din rețeaua Link 16 la intervale neregulate, detecții ale emițătoarelor SIGINT atunci când apar și rapoarte de informații conform unui program imprevizibil. O arhitectură sincronă, cerere-răspuns, în care fiecare componentă așteaptă ca cea anterioară să termine înainte de a continua, nu poate absorbi această sarcină. Rezultatul este pierderea de date, blocaje de procesare în perioadele de vârf și instabilitate a sistemului exact când fiabilitatea contează cel mai mult. Arhitectura cozilor de mesaje decuplează producătorii de consumatori, absoarbe sarcina de vârf în buffere persistente și permite fiecărei componente de procesare să opereze în propriul ritm fără a bloca altele.

Modelul producător-consumator pentru ingestia senzorilor

Într-o arhitectură cu cozi de mesaje, fiecare sursă de date este un producător care publică mesaje într-o coadă sau subiect denumit fără a aștepta confirmarea de la consumatorii din aval. Fiecare componentă de procesare este un consumator care citește din cozi la orice rată poate susține. Broker-ul de mesaje — Apache Kafka, RabbitMQ sau un echivalent cloud nativ — stochează mesajele durabil până când consumatorii le confirmă, oferind un buffer care absoarbe nepotrivirea dintre ratele de producție și de consum.

Pentru un sistem de fuziune a senzorilor de apărare, aceasta se traduce direct: ingester-ul urmelor radar publică un mesaj TrackUpdated în subiectul urmăririlor de fiecare dată când sosește un nou raport radar. Procesorul de fuziune a urmăririlor se abonează la subiectul urmăririlor și procesează mesajele cât de rapid poate — dacă sosesc 500 de urmăriri într-o secundă, mesajele se acumulează în subiect și procesorul de fuziune le prelucrează fără a le pierde. Afișajul imaginii operaționale se abonează la subiectul urmăririlor fuzionate și se reîmprospătează la orice rată poate reda interfața utilizatorului, independent de viteza motorului de fuziune.

Proprietățile cheie care fac acest lucru viabil pentru sistemele de apărare sunt durabilitatea (mesajele sunt persistate pe disc și supraviețuiesc repornirii broker-ului), livrarea cel puțin o dată (fiecare mesaj este livrat fiecărui consumator cel puțin o dată, cu deduplicarea de pe partea consumatorului gestionând orice relivri) și izolarea grupului de consumatori (mai multe grupuri independente de consumatori pot citi același subiect independent, astfel încât atât procesul de arhivare a urmăririlor cât și procesul de afișare a urmăririlor văd fiecare mesaj fără a interfera unul cu altul).

Apache Kafka pentru pipeline-uri de date de apărare

Apache Kafka a devenit platforma dominantă de streaming de mesaje pentru pipeline-uri de date de mare capacitate, iar arhitectura sa se potrivește bine cerințelor de apărare. Un cluster Kafka constă din mai multe noduri broker, fiecare stocând o parte din partițiile subiectelor. Partițiile subiectelor sunt unitatea de paralelism: un subiect cu 12 partiții poate fi consumat de până la 12 instanțe de consumator paralele într-un grup de consumatori, fiecare procesând un subset de partiții. Creșterea numărului de partiții scalează capacitatea liniar până la punctul în care I/O-ul discului broker-ului devine blocajul.

Pentru ingestia senzorilor de apărare, designul recomandat al subiectelor folosește tipul de date ca dimensiune principală de partiționare: un subiect radar-tracks, un subiect ais-positions, un subiect adsb-tracks, un subiect sigint-detections, un subiect intelligence-reports. În cadrul fiecărui subiect, cheia de partiție ar trebui să fie identificatorul urmăririi sau entității, asigurând că toate mesajele pentru o urmărire dată sunt procesate de aceeași instanță de consumator — aceasta este critică pentru procesarea fluxului cu stare care menține starea per urmărire (poziția curentă, istoricul clasificărilor, scorul de încredere).

Funcția de compactare a jurnalelor Kafka este valoroasă pentru urmăriri: când compactarea jurnalelor este activată pe un subiect, Kafka păstrează doar cel mai recent mesaj pentru fiecare cheie de partiție, eliminând actualizările intermediare. Pentru un consumator care pornește și trebuie să-și inițializeze starea în memorie, compactarea jurnalelor înseamnă că poate citi subiectul compactat și obține starea curentă a fiecărei urmăriri fără a redifuza întregul istoric de actualizări. Acesta este echivalentul Kafka al mecanismului de snapshot în sistemele de event sourcing.

RabbitMQ pentru rutarea mesajelor de comandă și control

Kafka excelează la streaming de mare capacitate, dar nu este optimizat pentru logică complexă de rutare. RabbitMQ oferă un compromis diferit: capacitate mai mică dar rutare sofisticată prin schimburi. Schimburile RabbitMQ implementează patru moduri de rutare — direct (mesajul merge în cozile care se potrivesc exact cu cheia de rutare), fanout (mesajul merge în toate cozile legate), topic (mesajul merge în cozile care se potrivesc cu un tipar al cheii de rutare) și headers (mesajul merge în cozile care se potrivesc cu valorile antetului).

Pentru rutarea mesajelor de comandă și control de apărare, schimburile de subiecte sunt deosebit de utile. Un mesaj cu cheia de rutare "alert.track.hostile" este livrat în cozile legate cu tiparele "alert.#" (toate alertele), "alert.track.#" (toate alertele de urmărire) și "alert.track.hostile" (numai alertele de urmărire ostilă). Aceasta permite unui sistem de fuziune de supraveghere să publice un singur mesaj de alertă și să fie livrat automat afișajului centrului de operații (legat la "alert.#"), terminalului postului de comandă al comandantului (legat la "alert.track.hostile") și sistemului de jurnal de alerte (legat la "#"), fără ca editorul să știe nimic despre consumatori.

Procesarea fluxurilor: Apache Kafka Streams și Flink

Publicarea datelor senzorilor în subiecte și consumarea lor pentru afișare este cazul de bază. Capacitatea mai puternică este procesarea fluxurilor cu stare: transformarea datelor brute ale senzorilor în produse de informații derivate în timp real. Apache Kafka Streams este o bibliotecă client (nu un cluster separat) care permite aplicațiilor Java/Kotlin să definească topologii de procesare peste subiectele Kafka. O aplicație Kafka Streams poate uni un subiect de radar-tracks cu un subiect de classification-database pentru a produce un subiect de enriched-tracks care conține cea mai recentă poziție a urmăririi plus clasificarea actuală a amenințărilor, toate în ecosistemul Kafka.

Apache Flink este un framework de procesare a fluxurilor distribuit, potrivit pentru calcule cu stare mai complexe. Operatorii cu stare ai Flink mențin starea per cheie la nivelul mesajelor — de exemplu, un operator Flink care calculează viteza urmăririi din actualizările succesive de poziție menține poziția anterioară în starea cu cheie, citește noua poziție din mesajul următor, calculează vectorul de viteză și emite rezultatul. Mecanismul de checkpoint al Flink persistă periodic starea operatorului în stocare durabilă, permițând recuperarea din erori fără a redifuza întregul flux de intrare.

Pentru pipeline-uri de fuziune de apărare, Flink este adecvat pentru operații care necesită unirea mai multor subiecte cu agregări cu fereastră temporală: "pentru fiecare urmărire, calculați viteza medie și direcția pe ultimele 60 de secunde folosind toate rapoartele radar și AIS" este un job Flink. Funcția de fereastră gestionează datele cu întârziere (un raport senzor care ajunge cu 10 secunde după marca sa de timp) folosind mecanismul de watermark al Flink, care permite specificarea unei întârzieri maxime tolerate înainte ca o fereastră să se închidă.

Dimensionarea cozilor și gestionarea contrapresiunii

Cozile de mesaje oferă gestionarea contrapresiunii: când consumatorii nu pot ține pasul cu producătorii, mesajele se acumulează în coadă în loc să fie eliminate. Acesta este comportamentul corect pentru majoritatea datelor de apărare — este mai bine să procesezi o actualizare de urmărire cu 5 secunde întârziere decât să o elimini. Cu toate acestea, creșterea nelimitată a cozii este și ea un mod de eșec: dacă procesorul de fuziune al urmăririlor rămâne cu 30 de minute în urmă pentru că este supraîncărcat, imaginea operațională afișată comandanților arată informații vechi de 30 de minute.

Abordarea corectă este dimensionarea cozilor pentru absorbția vârfurilor, nu pentru backlog indefinit. Un subiect de urmăriri radar cu 24 de ore de retenție și 10 GB per partiție este adecvat pentru absorbția traficului de vârf dintr-o perioadă de angajament intens, asigurând în același timp că o repornire a consumatorului poate recupera rapid. Monitorizarea lag-ului consumatorului — diferența dintre cel mai recent offset al mesajului și poziția curentă a consumatorului — este metrica operațională cheie. Un lag al consumatorului care crește în timp indică faptul că consumatorul este sub-aprovizionat și ar trebui adăugate instanțe suplimentare de consumator.

Considerații de securitate pentru infrastructura de mesagerie de apărare

Implementările de broker de mesaje de apărare necesită autentificare TLS mutuală (atât broker-ul cât și fiecare client se autentifică cu certificate), autorizare la nivel de subiect (un proces de ingester radar ar trebui să poată produce în subiectul radar-tracks dar nu să citească din subiectul intelligence-reports) și criptare în repaus (datele subiectelor Kafka stocate pe discurile broker-ului ar trebui criptate). Kafka suportă toate trei prin mecanisme native: TLS pentru transport, autorizare bazată pe ACL și criptare la nivel de sistem de fișiere pentru datele în repaus.

Segmentarea rețelei este la fel de importantă: clusterul de broker de mesaje ar trebui să rezide într-un segment de rețea accesibil atât pentru componentele producătoare cât și pentru cele consumatoare, dar nu direct accesibil din rețele externe sau de la stațiile de lucru ale utilizatorilor finali. Producătorii și consumatorii se autentifică la broker folosind certificate de cont de serviciu, nu acreditări de utilizator. Clusterul broker în sine ar trebui gestionat cu instrumente infrastructure-as-code mai degrabă decât prin configurare manuală pentru a menține o implementare reproductibilă și auditabilă.