Архітектура черги повідомлень для високопропускних конвеєрів оборонних даних

Сучасний тактичний командний пункт ЗСУ отримує дані з десятків потоків датчиків одночасно: оновлення радарних треків кожну секунду, позиції суден AIS кожні 30 секунд, метадані відео дрона зі швидкістю 30 кадрів на секунду, повідомлення мережі Link 16 з нерегулярними інтервалами, виявлення емітерів SIGINT при їх виникненні, та розвідувальні звіти за непередбачуваним розкладом. Синхронна архітектура запит-відповідь, де кожен компонент чекає завершення попереднього перед продовженням, не може витримати це навантаження. Результатом є втрачені дані, затори обробки під час пікової активності та нестабільність системи саме в моменти, коли надійність найважливіша. Архітектура черги повідомлень розв'язує виробників від споживачів, поглинає пікові навантаження у постійні буфери та дозволяє кожному компоненту обробки працювати у власному темпі без блокування інших.

Модель виробник-споживач для прийому даних датчиків

В архітектурі черги повідомлень кожне джерело даних є виробником, що публікує повідомлення до іменованої черги або теми без очікування підтвердження від споживачів нижче за течією. Кожен компонент обробки є споживачем, що читає з черг з будь-якою швидкістю, яку він може витримати. Брокер повідомлень — Apache Kafka, RabbitMQ або хмарний еквівалент — зберігає повідомлення стійко до тих пір, поки споживачі не підтвердять їх, забезпечуючи буфер, що поглинає невідповідність між швидкостями виробництва та споживання.

Для системи злиття датчиків ЗСУ це безпосередньо означає: приймач радарних треків публікує повідомлення TrackUpdated до теми треків кожного разу, коли надходить новий радарний звіт. Процесор злиття треків підписується на тему треків та обробляє повідомлення так швидко, як може — якщо за одну секунду надходить сплеск 500 треків, повідомлення накопичуються в темі, і процесор злиття обробляє їх без жодних втрат. Відображення оперативної картини підписується на тему злитих треків та оновлюється з будь-якою швидкістю, з якою може рендерити інтерфейс, незалежно від швидкості роботи рушія злиття.

Ключові властивості, що роблять це придатним для систем ЗСУ: стійкість (повідомлення зберігаються на диску та виживають після перезапуску брокера), доставка принаймні один раз (кожне повідомлення доставляється кожному споживачу принаймні один раз, де дедуплікація на стороні споживача обробляє будь-які повторні доставки), та ізоляція груп споживачів (кілька незалежних груп споживачів можуть читати одну тему незалежно, тому процес архівування треків і процес відображення треків бачать кожне повідомлення без взаємних перешкод).

Apache Kafka для конвеєрів оборонних даних ЗСУ

Apache Kafka став домінуючою платформою потокової передачі повідомлень для високопропускних конвеєрів даних, і його архітектура добре відповідає оборонним вимогам. Кластер Kafka складається з кількох вузлів-брокерів, кожен з яких зберігає частину секцій теми. Секції теми є одиницею паралелізму: тема з 12 секціями може споживатися до 12 паралельними екземплярами споживача в межах групи споживачів, кожен з яких обробляє підмножину секцій. Збільшення кількості секцій масштабує пропускну здатність лінійно до точки, де вводів-виводів диска брокера стає вузьким місцем.

Для прийому датчиків ЗСУ рекомендований дизайн теми використовує тип даних як основний вимір секціонування: тема радарних треків, тема позицій AIS, тема треків ADS-B, тема виявлень SIGINT, тема розвідувальних звітів. У межах кожної теми ключем секції повинен бути ідентифікатор треку або сутності, що забезпечує обробку всіх повідомлень для даного треку одним і тим же екземпляром споживача — це критично для стану-збереженої потокової обробки, що підтримує стан для кожного треку (поточна позиція, історія класифікації, оцінка достовірності).

Функція ущільнення журналу Kafka є цінною для треків: коли ущільнення журналу увімкнено в темі, Kafka зберігає лише найновіше повідомлення для кожного ключа секції, відкидаючи проміжні оновлення. Для споживача, що запускається та потребує ініціалізації стану в пам'яті, ущільнення журналу означає, що він може читати ущільнену тему та отримати поточний стан кожного треку без відтворення всієї історії оновлень.

RabbitMQ для маршрутизації повідомлень C2

Kafka відмінно справляється з потоковою передачею з великою пропускною здатністю, але не оптимізований для складної логіки маршрутизації. RabbitMQ забезпечує інший компроміс: нижча пропускна здатність, але складна маршрутизація обміном. Обміни RabbitMQ реалізують чотири режими маршрутизації — прямий (повідомлення надходить до черг, що точно відповідають ключу маршрутизації), розширення (повідомлення надходить до всіх прив'язаних черг), тема (повідомлення надходить до черг, що відповідають шаблону ключа маршрутизації) та заголовки (повідомлення надходить до черг, що відповідають значенням заголовків).

Для маршрутизації повідомлень C2 ЗСУ обміни тем є особливо корисними. Повідомлення з ключем маршрутизації «alert.track.hostile» доставляється до черг, прив'язаних з шаблонами «alert.#» (всі сповіщення), «alert.track.#» (всі сповіщення треку) та «alert.track.hostile» (лише сповіщення про ворожий трек). Це дозволяє системі злиття спостереження публікувати одне повідомлення сповіщення та автоматично доставляти його до відображення операційного центру, термінала командного поста командира та системи журналу сповіщень, без того щоб видавець знав що-небудь про споживачів.

Потокова обробка: Apache Kafka Streams та Flink

Публікація даних датчиків до тем та їх споживання для відображення — це базовий випадок. Більш потужна можливість — стан-збережена потокова обробка: перетворення сирих даних датчиків на отримані розвідувальні продукти в реальному часі. Apache Kafka Streams — це клієнтська бібліотека (не окремий кластер), що дозволяє Java/Kotlin застосункам визначати топології обробки над темами Kafka. Застосунок Kafka Streams може з'єднати тему радарних треків з темою класифікаційної бази даних для отримання теми збагачених треків, що містить останню позицію треку плюс його поточну класифікацію загрози, все в межах екосистеми Kafka.

Apache Flink — це фреймворк розподіленої потокової обробки, придатний для більш складних стан-збережених обчислень. Оператори стану Flink підтримують стан для кожного ключа між повідомленнями. Механізм контрольних точок Flink periodically зберігає стан оператора до стійкого сховища, уможливлюючи відновлення після збою без відтворення всього вхідного потоку.

Міркування безпеки для оборонної інфраструктури повідомлень

Розгортання брокерів повідомлень для ЗСУ вимагає взаємної автентифікації TLS (і брокер, і кожен клієнт автентифікуються за допомогою сертифікатів), авторизації на рівні теми (процес прийому радара повинен мати можливість публікувати до теми радарних треків, але не читати з теми розвідувальних звітів) та шифрування у стані спокою (дані теми Kafka, що зберігаються на дисках брокера, повинні бути зашифровані). Kafka підтримує всі три через нативні механізми: TLS для транспорту, авторизація на основі ACL та шифрування на рівні файлової системи для даних у стані спокою.