Architecture de file de messages pour les pipelines de données de défense à haut débit

Un centre d'opérations tactiques moderne DGA/EMA reçoit des données de dizaines de flux de capteurs simultanément : mises à jour de pistes radar chaque seconde, positions de navires AIS toutes les 30 secondes, métadonnées vidéo de drone à 30 images par seconde, messages réseau Link 16 à des intervalles irréguliers, détections d'émetteurs SIGINT lorsqu'elles se produisent, et rapports de renseignement selon un calendrier imprévisible. Une architecture synchrone de type requête-réponse, où chaque composant attend que le précédent se termine avant de continuer, ne peut pas absorber cette charge. Le résultat est des données perdues, des goulots d'étranglement de traitement pendant les périodes d'activité de pointe et une instabilité système aux moments où la fiabilité est la plus importante. L'architecture de file de messages découple les producteurs des consommateurs, absorbe les charges de pointe dans des tampons persistants et permet à chaque composant de traitement de fonctionner à son propre rythme sans bloquer les autres.

Le modèle producteur-consommateur pour l'ingestion de capteurs

Dans une architecture de file de messages, chaque source de données est un producteur qui publie des messages dans une file ou un topic nommé sans attendre d'accusé de réception de la part des consommateurs en aval. Chaque composant de traitement est un consommateur qui lit les files au rythme qu'il peut soutenir. Le courtier de messages — Apache Kafka, RabbitMQ ou un équivalent cloud-natif — stocke les messages de façon durable jusqu'à leur acquittement par les consommateurs, fournissant un tampon qui absorbe le décalage entre les taux de production et de consommation.

Pour un système de fusion de capteurs DGA/EMA, cela signifie concrètement : l'ingesteur de pistes radar publie un message TrackUpdated dans le topic des pistes à chaque fois qu'un nouveau rapport radar arrive. Le processeur de fusion de pistes s'abonne au topic des pistes et traite les messages aussi vite que possible — si une rafale de 500 pistes arrive en une seconde, les messages s'accumulent dans le topic et le processeur de fusion les traite sans en perdre aucun. L'affichage du tableau de situation s'abonne au topic des pistes fusionnées et se rafraîchit à la vitesse à laquelle l'interface peut rendre, indépendamment de la vitesse à laquelle le moteur de fusion travaille.

Apache Kafka pour les pipelines de données DGA/EMA

Apache Kafka est devenu la plateforme de streaming de messages dominante pour les pipelines de données à haut débit, et son architecture correspond bien aux exigences de défense. Un cluster Kafka est composé de plusieurs nœuds broker, chacun stockant une partie des partitions de topics. Les partitions de topics sont l'unité de parallélisme : un topic avec 12 partitions peut être consommé par jusqu'à 12 instances consommateurs parallèles au sein d'un groupe de consommateurs.

Pour l'ingestion de capteurs DGA/EMA, la conception recommandée utilise le type de données comme dimension de partitionnement principale : un topic de pistes radar, un topic de positions AIS, un topic de pistes ADS-B, un topic de détections SIGINT, un topic de rapports de renseignement. La fonctionnalité de compaction de log de Kafka est précieuse pour les pistes : lorsque la compaction de log est activée sur un topic, Kafka ne conserve que le message le plus récent pour chaque clé de partition, supprimant les mises à jour intermédiaires.

RabbitMQ pour le routage de messages C2

Kafka excelle dans le streaming à haut débit mais n'est pas optimisé pour la logique de routage complexe. RabbitMQ offre un compromis différent : débit plus faible mais routage d'échange sophistiqué. Pour le routage de messages C2 DGA/EMA, les échanges de type topic sont particulièrement utiles. Un message avec la clé de routage «alert.track.hostile» est délivré aux files liées avec les motifs «alert.#» (toutes les alertes), «alert.track.#» (toutes les alertes de pistes) et «alert.track.hostile» (seulement les alertes de pistes hostiles), sans que le producteur connaisse les consommateurs.

Traitement de flux : Apache Kafka Streams et Flink

La publication de données de capteurs dans des topics et leur consommation pour l'affichage est le cas de base. La capacité plus puissante est le traitement de flux avec état : transformer les données brutes des capteurs en produits de renseignement dérivés en temps réel. Apache Kafka Streams est une bibliothèque cliente qui permet aux applications Java/Kotlin de définir des topologies de traitement sur des topics Kafka. Apache Flink est un framework de traitement de flux distribué adapté aux calculs avec état plus complexes. Le mécanisme de points de contrôle de Flink persiste périodiquement l'état des opérateurs vers un stockage durable, permettant la récupération après un échec sans rejouer l'intégralité du flux d'entrée.

Considérations de sécurité pour l'infrastructure de messagerie de défense

Les déploiements de courtiers de messages DGA nécessitent une authentification TLS mutuelle (le courtier et chaque client s'authentifient avec des certificats), une autorisation au niveau des topics (un processus d'ingesteur radar doit pouvoir produire dans le topic de pistes radar mais pas lire dans le topic de rapports de renseignement) et un chiffrement au repos. La segmentation réseau est tout aussi importante : le cluster de courtiers de messages doit résider dans un segment réseau accessible aux composants producteurs et consommateurs, mais pas directement accessible depuis des réseaux externes ou des postes de travail utilisateurs.