Nykyaikainen taktinen operaatiokeskus vastaanottaa dataa kymmenistä sensorivirroista samanaikaisesti: tutkamaaleja päivitetään sekunnin välein, AIS-alusten sijainteja 30 sekunnin välein, lennokkivideon metadataa 30 ruutua sekunnissa, Link 16 -verkkosanomia epäsäännöllisin väliajoin, SIGINT-lähetinhavaintoja niiden esiintyessä ja tiedusteluraportteja ennakoimattomalla aikataululla. Synkroninen pyyntö–vastaus-arkkitehtuuri, jossa kukin komponentti odottaa edellisen valmistumista ennen jatkamista, ei pysty ottamaan vastaan tätä kuormaa. Seurauksena on hävinnyttä dataa, käsittelyruuhkia huippuaktiivisuuden aikana ja järjestelmän epävakautta juuri niinä hetkinä, joina luotettavuudella on eniten merkitystä. Sanomajono-arkkitehtuuri erottaa tuottajat kuluttajista, ottaa purskekuorman vastaan pysyviin puskureihin ja antaa jokaisen käsittelykomponentin toimia omalla tahdillaan estämättä muita.

Tuottaja–kuluttaja-malli sensoridatan vastaanottoon

Sanomajono-arkkitehtuurissa jokainen tietolähde on tuottaja, joka julkaisee sanomia nimettyyn jonoon tai aiheeseen odottamatta kuittausta alavirran kuluttajilta. Jokainen käsittelykomponentti on kuluttaja, joka lukee jonoista sillä nopeudella, jonka se pystyy ylläpitämään. Sanomavälittäjä — Apache Kafka, RabbitMQ tai pilvinatiivi vastine — tallentaa sanomat pysyvästi, kunnes kuluttajat kuittaavat ne, tarjoten puskurin, joka tasaa tuotanto- ja kulutusnopeuksien välisen eron.

Puolustuksen sensorifuusiojärjestelmässä tämä konkretisoituu suoraan: tutkamaalin vastaanottokomponentti julkaisee TrackUpdated-sanoman tracks-aiheeseen aina, kun uusi tutkaraportti saapuu. Maalifuusio-prosessori tilaa tracks-aiheen ja käsittelee sanomat niin nopeasti kuin pystyy — jos 500 maalin purske saapuu yhdessä sekunnissa, sanomat kertyvät aiheeseen ja fuusioprosessori käy ne läpi pudottamatta yhtäkään. Operatiivinen tilannekuvanäyttö tilaa fused-tracks-aiheen ja päivittyy sillä nopeudella, jolla käyttöliittymä pystyy renderöimään, riippumatta siitä, kuinka nopeasti fuusiomoottori toimii.

Keskeiset ominaisuudet, jotka tekevät tästä toimivan puolustusjärjestelmissä, ovat pysyvyys (sanomat tallennetaan levylle ja ne selviävät välittäjän uudelleenkäynnistyksistä), vähintään-kerran-toimitus (kukin sanoma toimitetaan jokaiselle kuluttajalle vähintään kerran, ja kuluttajapuolen duplikaattien poisto hoitaa mahdolliset uudelleentoimitukset) sekä kuluttajaryhmien eristys (useat itsenäiset kuluttajaryhmät voivat lukea samaa aihetta toisistaan riippumatta, joten maalien arkistointiprosessi ja maalien näyttöprosessi näkevät molemmat jokaisen sanoman häiritsemättä toisiaan).

Apache Kafka puolustuksen dataputkille

Apache Kafkasta on tullut hallitseva sanomien suoratoistoalusta suuren läpimenon dataputkille, ja sen arkkitehtuuri sopii hyvin puolustuksen vaatimuksiin. Kafka-klusteri koostuu useista välittäjäsolmuista, joista kukin tallentaa osan aihepartitioista. Aihepartitiot ovat rinnakkaisuuden yksikkö: 12 partition aihetta voi kuluttaa enintään 12 rinnakkaista kuluttajainstanssia yhden kuluttajaryhmän sisällä, joista kukin käsittelee osajoukon partitioista. Partitioiden määrän kasvattaminen skaalaa läpimenoa lineaarisesti siihen pisteeseen asti, jossa välittäjän levyn I/O muodostuu pullonkaulaksi.

Puolustuksen sensoridatan vastaanotossa suositeltu aihesuunnittelu käyttää datatyyppiä ensisijaisena partitiointiulottuvuutena: radar-tracks-aihe, ais-positions-aihe, adsb-tracks-aihe, sigint-detections-aihe ja intelligence-reports-aihe. Kunkin aiheen sisällä partitioavaimen tulisi olla maalin tai entiteetin tunniste, mikä varmistaa, että kaikki tietyn maalin sanomat käsittelee sama kuluttajainstanssi — tämä on ratkaisevaa tilalliselle virtakäsittelylle, joka ylläpitää maalikohtaista tilaa (nykyinen sijainti, luokitushistoria, luottamuspistemäärä).

Kafkan log compaction -ominaisuus on arvokas maalien kannalta: kun log compaction on käytössä aiheessa, Kafka säilyttää vain viimeisimmän sanoman kullekin partitioavaimelle ja hylkää välipäivitykset. Kuluttajalle, joka käynnistyy ja jonka on alustettava muistinvarainen tilansa, log compaction tarkoittaa, että se voi lukea tiivistetyn aiheen ja saada jokaisen maalin nykyisen tilan toistamatta koko päivityshistoriaa. Tämä vastaa Kafkassa event sourcing -järjestelmien tilannevedosmekanismia.

RabbitMQ johtamisen ja valvonnan sanomien reitityksessä

Kafka on erinomainen suuren läpimenon suoratoistossa, mutta sitä ei ole optimoitu monimutkaiselle reitityslogiikalle. RabbitMQ tarjoaa toisenlaisen kompromissin: pienemmän läpimenon mutta kehittyneen vaihdereitityksen. RabbitMQ:n vaihteet (exchange) toteuttavat neljä reititystapaa — direct (sanoma menee jonoihin, jotka vastaavat reititysavainta tarkasti), fanout (sanoma menee kaikkiin sidottuihin jonoihin), topic (sanoma menee jonoihin, jotka vastaavat reititysavainmallia) ja headers (sanoma menee jonoihin, jotka vastaavat otsikkoarvoja).

Puolustuksen johtamisen ja valvonnan sanomien reitityksessä topic-vaihteet ovat erityisen hyödyllisiä. Sanoma, jonka reititysavain on "alert.track.hostile", toimitetaan jonoihin, jotka on sidottu malleihin "alert.#" (kaikki hälytykset), "alert.track.#" (kaikki maalihälytykset) ja "alert.track.hostile" (vain vihamielisten maalien hälytykset). Tämä mahdollistaa sen, että valvontafuusiojärjestelmä julkaisee yhden hälytyssanoman ja se toimitetaan automaattisesti operaatiokeskuksen näytölle (sidottu malliin "alert.#"), komentajan komentopaikan päätteelle (sidottu malliin "alert.track.hostile") ja hälytyslokijärjestelmälle (sidottu malliin "#"), ilman että julkaisija tietää mitään kuluttajista.

Virtakäsittely: Apache Kafka Streams ja Flink

Sensoridatan julkaiseminen aiheisiin ja sen kuluttaminen näyttöä varten on perustapaus. Tehokkaampi kyvykkyys on tilallinen virtakäsittely: raakasensoridatan muuntaminen johdetuiksi tiedustelutuotteiksi reaaliajassa. Apache Kafka Streams on asiakaskirjasto (ei erillinen klusteri), jonka avulla Java-/Kotlin-sovellukset voivat määritellä käsittelytopologioita Kafka-aiheiden yli. Kafka Streams -sovellus voi liittää radar-tracks-aiheen luokitustietokanta-aiheeseen tuottaakseen enriched-tracks-aiheen, joka sisältää maalin viimeisimmän sijainnin sekä sen nykyisen uhkaluokituksen, kaiken Kafka-ekosysteemin sisällä.

Apache Flink on hajautettu virtakäsittelykehys, joka soveltuu monimutkaisempiin tilallisiin laskelmiin. Flinkin tilalliset operaattorit ylläpitävät avainkohtaista tilaa sanomien välillä — esimerkiksi Flink-operaattori, joka laskee maalin nopeuden peräkkäisistä sijaintipäivityksistä, ylläpitää edellistä sijaintia avainnetussa tilassa, lukee uuden sijainnin seuraavasta sanomasta, laskee nopeusvektorin ja tuottaa tuloksen. Flinkin tarkistuspistemekanismi tallentaa operaattorin tilan ajoittain pysyvään tallennustilaan, mikä mahdollistaa toipumisen vikatilanteesta toistamatta koko syötevirtaa.

Puolustuksen fuusioputkille Flink soveltuu toimintoihin, jotka edellyttävät liittämistä useiden aiheiden yli aikaikkunoituine koosteineen: "laske kullekin maalille keskimääräinen suunta ja nopeus viimeisten 60 sekunnin ajalta käyttäen kaikkia tutka- ja AIS-raportteja" on Flink-tehtävä. Ikkunafunktio käsittelee myöhässä saapuvan datan (sensoriraportti, joka saapuu 10 sekuntia aikaleimansa jälkeen) Flinkin vesileimamekanismin avulla, joka sallii suurimman siedetyn viiveen määrittämisen ennen ikkunan sulkeutumista.

Jonojen mitoitus ja vastapaineen hallinta

Sanomajonot tarjoavat vastapaineen hallinnan: kun kuluttajat eivät pysy tuottajien tahdissa, sanomat kertyvät jonoon sen sijaan, että ne pudotettaisiin. Tämä on oikea toimintatapa useimmalle puolustusdatalle — on parempi käsitellä maalipäivitys 5 sekuntia myöhässä kuin hylätä se. Rajaton jonon kasvu on kuitenkin myös vikatila: jos maalifuusioprosessori jää 30 minuuttia jälkeen ylikuormituksen vuoksi, komentajille näytettävä tilannekuva esittää 30 minuuttia vanhaa tietoa.

Oikea lähestymistapa on mitoittaa jonot purskeen vastaanottoon, ei rajattomaan ruuhkaan. Tutkamaaliaihe, jossa on 24 tunnin säilytys ja 10 GB partitiota kohti, soveltuu intensiivisen taisteluvaiheen purskeliikenteen vastaanottamiseen varmistaen samalla, että kuluttajan uudelleenkäynnistys ehtii nopeasti kiinni. Kuluttajan viiveen (consumer lag) — eron viimeisimmän sanoman siirtymän ja kuluttajan nykyisen sijainnin välillä — seuranta on keskeinen operatiivinen mittari. Ajan myötä kasvava kuluttajan viive osoittaa, että kuluttaja on alimitoitettu ja lisää kuluttajainstansseja tulisi lisätä.

Tietoturvanäkökohdat puolustuksen sanomainfrastruktuurissa

Puolustuksen sanomavälittäjäkäyttöönotot edellyttävät keskinäistä TLS-todennusta (sekä välittäjä että kukin asiakas todentavat itsensä varmenteilla), aihetason valtuutusta (tutkadatan vastaanottoprosessin tulisi pystyä tuottamaan radar-tracks-aiheeseen mutta ei lukemaan intelligence-reports-aiheesta) sekä levossa olevan datan salausta (välittäjän levyille tallennettu Kafka-aihedata tulisi salata). Kafka tukee kaikkia kolmea natiivimekanismein: TLS:n siirrolle, ACL-pohjaisen valtuutuksen ja tiedostojärjestelmätason salauksen levossa olevalle datalle.

Verkon segmentointi on yhtä tärkeää: sanomavälittäjäklusterin tulisi sijaita verkkosegmentissä, joka on sekä tuottaja- että kuluttajakomponenttien saavutettavissa, mutta ei suoraan saavutettavissa ulkoisista verkoista tai loppukäyttäjien työasemista. Tuottajat ja kuluttajat todentavat itsensä välittäjälle palvelutilien varmenteilla, ei käyttäjätunnuksilla. Itse välittäjäklusteria tulisi hallita infrastruktuuri-koodina-työkaluilla manuaalisen konfiguroinnin sijaan, jotta käyttöönotto on toistettavissa ja auditoitavissa.

Keskeinen oivallus: Sanomajono ei ole pisteestä pisteeseen -viestintäkanava — se on puolustuksen dataputken keskushermosto. Jokainen sensorivirta, jokainen käsittelyvaihe ja jokainen kuluttajasovellus kytkeytyy samaan välittäjäinfrastruktuuriin. Tämä tarkoittaa, että välittäjän saatavuus on kriittinen operatiivinen riippuvuus. Puolustuksen käyttöönotoissa tulisi käyttää vähintään kolmea välittäjäsolmua Kafka-klusterissa kvorumin ylläpitämiseksi minkä tahansa yksittäisen solmun vikaantuessa, ja replikointikertoimena 3 kaikille tehtäväkriittisille aiheille.