Architecture d'agent MQTT autonome sur Google Cloud

MQTT (Message Queuing Telemetry Transport) est un protocole OASIS standard pour les applications d'appareils connectés qui fournit une messagerie bidirectionnelle à l'aide d'une architecture d'agent de publication et d'abonnement. Le protocole MQTT est léger afin de réduire la surcharge réseau, et les clients MQTT sont très petits pour minimiser l'utilisation de ressources sur des appareils limités. Pour les entreprises qui souhaitent prendre en charge des applications d'appareils connectés sur Google Cloud, la solution consiste à exécuter un agent MQTT autonome sur Compute Engine ou GKE. Pour déployer un agent MQTT dans votre organisation, vous devez prendre plusieurs décisions clés qui affectent l'architecture globale, en particulier l'équilibrage de charge et l'environnement de déploiement. Ce document décrit une architecture de déploiement d'un agent MQTT, l'application principale d'un déploiement MQTT, sur Google Cloud. Il décrit également les décisions que vous devez prendre lorsque vous déployez cet agent et leur impact sur l'architecture.

Ce document fait partie d'une série de documents qui fournissent des informations sur les architectures IoT sur Google Cloud et la migration depuis IoT Core. Cette série comprend également les documents suivants :

Le schéma suivant montre une architecture d'agent MQTT s'exécutant sur Google Cloud.

Schéma de l'architecture d'agent MQTT (expliqué dans le texte suivant)

L'architecture dans l'image précédente se compose des éléments suivants :

  • L'agent MQTT est déployé en tant que cluster de trois instances connectées au service Cloud Load Balancing. Pour l'équilibreur de charge cloud, vous pouvez choisir l'un des différents produits d'équilibrage de charge décrits plus loin dans ce document.
  • Le cluster d'agent inclut un stockage d'identifiants d'appareil et un service d'authentification et d'autorisation de l'appareil. Le cluster se connecte aux charges de travail de backend via Dataflow ou Pub/Sub.
  • Du côté client, les passerelles de périphérie fournissent une communication bidirectionnelle entre les appareils de périphérie et le cluster d'agent MQTT via MQTT sur TLS.

En règle générale, pour cette architecture, nous vous recommandons de déployer l'application d''agent MQTT dans un cluster à des fins d'évolutivité. Des facteurs comme la fonctionnalité de clustering, la gestion du scaling du cluster à la hausse et à la baisse, la synchronisation des données et la gestion des partitions réseau sont traités par les implémentations d'agent spécifiques (telles que HiveMQ, EMQX, VerneMQ et autres).

Considérations et choix architecturaux

Les sections suivantes décrivent les différents choix architecturaux et considérations à prendre en compte pour une architecture MQTT autonome, ainsi que leur impact sur l'architecture.

Appareils connectés

Les appareils de périphérie connectés à Internet publient leurs événements de télémétrie et d'autres informations sur l'agent MQTT. Pour implémenter l'architecture d'agent MQTT autonome décrite dans ce document, l'appareil doit disposer d'un client MQTT, de la clé publique de certificat de serveur pour l'authentification TLS et des identifiants nécessaires à l'authentification auprès de l'agent MQTT.

En outre, les appareils de périphérie disposent généralement de connecteurs vers des capteurs locaux, vers des systèmes de données sur site et vers d'autres appareils qui ne disposent pas d'un accès Internet ou d'une connectivité IP. Par exemple, l'appareil de périphérie peut servir de passerelle pour d'autres appareils locaux limités connectés à la passerelle à l'aide de BLE (Bluetooth Low Energy), à une connexion filaire ou à un autre protocole NFC (communication en champ proche). La présentation détaillée de l'architecture d'appareils connectés n'entre pas dans le cadre de ce guide.

Équilibrage de charge

Dans l'architecture, un service d'équilibrage de charge externe est configuré entre le réseau public et le cluster d'agent MQTT. Ce service fournit plusieurs fonctions importantes de mise en réseau, dont la distribution des connexions entrantes sur les nœuds de backend, le chiffrement de session et l'authentification.

Google Cloud est compatible avec plusieurs types d'équilibreurs de charge. Pour choisir le meilleur équilibreur de charge pour votre architecture, tenez compte des points suivants :

  • mTLS. mTLS gère à la fois le chiffrement et les méthodes d'authentification des appareils, tandis que le protocole TLS standard ne gère que le chiffrement et nécessite une méthode d'authentification des appareils distincte :

    • Si votre application utilise mTLS pour l'authentification des appareils et doit interrompre le tunnel TLS, nous vous recommandons d'utiliser un équilibreur de charge réseau externe à stratégie directe ou un équilibreur de charge réseau proxy externe avec proxy TCP cible. Les équilibreurs de charge réseau proxy externes interrompent la session TLS et transfèrent la connexion au nœud de l'agent, ainsi que les identifiants d'authentification contenus dans le message. Si vous avez besoin des informations de connexion client dans le cadre du schéma d'authentification, vous pouvez les conserver dans la connexion backend en activant le protocole PROXY.
    • Si votre application n'utilise pas le protocole mTLS, nous vous recommandons d'utiliser un équilibreur de charge réseau proxy externe avec un proxy SSL cible pour transférer le traitement TLS et SSL externe vers l'équilibreur de charge. Les équilibreurs de charge réseau proxy externes interrompent la session TLS et transfèrent la connexion au nœud de l'agent, ainsi que les identifiants d'authentification contenus dans le message. Si vous avez besoin des informations de connexion client dans le cadre du schéma d'authentification, vous pouvez les conserver dans la connexion backend en activant le protocole PROXY.

  • Points de terminaison HTTP(S). Si vous devez exposer des points de terminaison HTTP(S), nous vous recommandons de configurer un équilibreur de charge d'application externe distinct pour ces points de terminaison.

Pour en savoir plus sur les types d'équilibreurs de charge compatibles avec Cloud Load Balancing, consultez la page Récapitulatif des équilibreurs de charge Google Cloud.

Stratégie d'équilibrage de charge

Tout service d'équilibrage de charge distribue les connexions depuis les appareils de périphérie entre les nœuds du cluster en fonction de l'un des différents modes d'équilibrage. Pour MQTT, une stratégie d'équilibrage de charge avec affinité de session est préférable à l'équilibrage de charge aléatoire. Les connexions client-serveur MQTT étant des sessions bidirectionnelles persistantes, l'état est conservé sur le nœud d'agent qui arrête la connexion. Dans une configuration en cluster, si un client se déconnecte, puis se reconnecte à un autre nœud, l'état de la session est déplacé vers le nouveau nœud, ce qui ajoute de la charge sur le cluster. Ce problème peut être évité en utilisant l'équilibrage de charge avec affinité de session. Si l'adresse IP des clients change fréquemment, la connexion peut être interrompue. Cependant, pour MQTT, l'affinité de session est préférable dans la plupart des cas. L'affinité de session est disponible dans tous les produits Cloud Load Balancing.

Authentification des appareils et gestion des identifiants

Les applications d'agent MQTT gèrent l'authentification des appareils et le contrôle des accès séparément de Google Cloud. Une application d'agent fournit également son propre espace de stockage et de gestion des identifiants. Le protocole MQTT est compatible avec l'authentification de base des utilisateurs et des mots de passe dans le paquet Connect initial. Ces champs sont également fréquemment utilisés par les implémentations d'agents pour accepter d'autres formes d'authentification, telles que le certificat X.509 ou les jetons JWT. MQTT 5.0 prend également en charge les méthodes d'authentification améliorées qui utilisent l'authentification de type question-réponse. La méthode d'authentification utilisée dépend du choix de l'application d'agent MQTT et du cas d'utilisation de votre appareil connecté.

Quelle que soit la méthode d'authentification utilisée par l'agent, celui-ci gère un stockage d'identifiants d'appareil. Ce stockage peut se trouver dans une base de données SQL locale ou dans un fichier plat. Certains agents, y compris HiveMQ et VerneMQ, acceptent également l'utilisation d'un service de base de données géré comme Cloud SQL. Vous avez besoin d'un service distinct pour gérer le stockage d'identifiants des appareils et toutes les intégrations à d'autres services d'authentification tels que IAM. La présentation du développement de ce service n'entre pas dans le cadre de ce guide.

Pour en savoir plus sur l'authentification et la gestion des identifiants, consultez la page Bonnes pratiques pour exécuter un backend IoT sur Google Cloud.

Charges de travail de backend

Tous les cas d'utilisation d'appareils connectés incluent une ou plusieurs applications backend utilisant les données ingérées à partir des appareils connectés. Parfois, ces applications doivent également envoyer des commandes et des mises à jour de configuration aux appareils. Dans l'architecture d'agent MQTT autonome de ce document, les données entrantes et les commandes sortantes sont acheminées via l'agent MQTT. La hiérarchie des sujets de l'agent comporte différents sujets pour différencier les données des commandes.

Les données et les commandes peuvent être envoyées entre l'agent et les applications backend de l'une des manières suivantes. Si l'application elle-même est compatible avec MQTT ou si elle peut être modifiée pour assurer la compatibilité avec MQTT, elle peut s'abonner directement à l'agent en tant que client. Cette approche vous permet d'utiliser la fonctionnalité de messagerie bidirectionnelle Pub/Sub MQTT directement à l'aide de votre application pour recevoir des données et envoyer des commandes aux appareils connectés.

Si votre application n'est pas compatible avec MQTT, il existe d'autres options. Dans l'architecture décrite dans ce document, Apache Beam fournit un pilote MQTT qui permet l'intégration bidirectionnelle à Dataflow et d'autres déploiements Beam. De nombreux agents disposent également de fonctionnalités de plug-in compatibles avec l'intégration à des services tels que Google Pub/Sub. Il s'agit généralement d'intégrations unidirectionnelles pour l'intégration des données, même si certains agents permettent l'intégration bidirectionnelle.

Cas d'utilisation

Une architecture d'agent MQTT est particulièrement bien adaptée aux cas d'utilisation des appareils décrits dans les sections suivantes.

Ingestion de données normalisée à partir d'appareils hétérogènes

Lorsque vous souhaitez collecter et analyser des données à partir d'un vaste parc d'appareils hétérogènes, un agent MQTT est souvent une bonne solution. Comme MQTT est une norme couramment adoptée et implémentée, de nombreux appareils de périphérie sont compatibles avec ce service, et des clients MQTT légers sont disponibles pour ajouter la compatibilité MQTT aux appareils qui n'en disposent pas. Le modèle "Publier et s'abonner" fait également partie de la norme MQTT. Les appareils compatibles MQTT peuvent ainsi bénéficier de cette architecture sans effort d'implémentation supplémentaire. En revanche, les appareils qui se connectent à Pub/Sub doivent intégrer l'API Pub/Sub ou utiliser le SDK Pub/Sub. L'exécution d'un agent MQTT conforme sur Google Cloud fournit donc une solution simple pour collecter des données à partir d'un large éventail d'appareils.

Lorsque vos appareils connectés ne sont pas contrôlés par votre application mais par un tiers, il est possible que vous n'ayez pas accès au logiciel du système de l'appareil et que la gestion de l'appareil lui-même incombe à l'autre partie. Dans ce cas, nous vous recommandons d'exécuter un agent MQTT et de fournir des identifiants d'authentification au tiers pour configurer le canal de communication des appareils vers le cloud.

Communication bidirectionnelle pour l'intégration d'applications multiparties

La fonctionnalité de messagerie bidirectionnelle de MQTT le rend particulièrement adapté aux cas d'utilisation d'applications mobiles multiparties, comme la livraison de repas à la demande ou les applications de chat Web à grande échelle. MQTT a une faible surcharge de protocole, et les demandes en ressources des clients MQTT sont peu élevées. MQTT comprend également le routage par publication et abonnement, plusieurs niveaux de qualité de service (QoS), une fonctionnalité intégrée de conservation des messages et la compatibilité avec de nombreux protocoles. Un agent MQTT peut être le composant principal d'une plate-forme de messagerie évolutive pour les applications de services à la demande et les cas d'utilisation similaires.

Messagerie intégrée de la périphérie au cloud

Étant donné la standardisation et la faible surcharge offertes par MQTT, c'est également une bonne solution pour l'intégration d'applications de messagerie sur site et dans le cloud. Par exemple, un opérateur d'usine peut déployer plusieurs agents MQTT dans l'environnement sur site pour se connecter aux capteurs, aux machines, aux passerelles et à d'autres appareils situés derrière le pare-feu. L'agent MQTT local peut gérer toutes les commandes bidirectionnelles, ainsi que les messages de contrôle et de télémétrie de l'infrastructure sur site. L'agent local peut également être connecté par abonnement bidirectionnel à un cluster d'agent MQTT parallèle dans le cloud, ce qui permet une communication entre le cloud et l'environnement périphérique sans exposer les appareils et systèmes sur site à l'Internet public.

Étapes suivantes