Architecture des produits de plate-forme IoT sur Google Cloud

Last reviewed 2024-08-09 UTC

Les produits de plate-forme IoT fournissent généralement une connectivité de données MQTT et HTTPS de base. Ils vous permettent également de provisionner des appareils et fournissent des fonctionnalités d'authentification et de gestion, de stockage et de visualisation de télémétrie, de traitement de données et d'alerte. Les entreprises utilisent souvent des plates-formes IoT lorsqu'un agent MQTT autonome n'est pas suffisant pour un cas d'utilisation et qu'un produit de plate-forme IoT plus complet est nécessaire. Une plate-forme IoT fournit une interface unifiée pour gérer une collection d'appareils hétérogène. Cette interface est importante pour de nombreuses applications d'appareils connectés, et il s'agit d'une différence essentielle entre une plate-forme IoT et un agent MQTT autonome. Ce document décrit les exigences et les recommandations architecturales de base avant de déployer une architecture de produits de plate-forme IoT sur Google Cloud.

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

Le schéma suivant montre un exemple d'architecture avec un produit de plate-forme IoT générique s'exécutant sur Google Cloud.

Architecture générique de plate-forme IoT (flux d'événements expliqué dans le texte suivant)

Comme le montre le schéma précédent, la plate-forme IoT déploie un agent MQTT ou un point de terminaison pour la connectivité de l'appareil. La plate-forme IoT est connectée à un équilibreur de charge réseau proxy externe pour distribuer le trafic depuis les appareils de périphérie. Des applications IoT supplémentaires peuvent se connecter à la plate-forme IoT via Pub/Sub ou à l'aide du connecteur MQTT Dataflow.

La plate-forme IoT fournit un ensemble de services de gestion des appareils. Comme le montre le schéma, ces services sont les suivants :

  • Stockage des identifiants de l'appareil
  • Moteur de règles
  • Authentification et autorisation des appareils
  • Gestion de la configuration des appareils
  • Registre d'appareils
  • Gestion des mises à jour des appareils

Les produits de plate-forme IoT incluent généralement des services tels que les doubles numériques, les interfaces de développement nécessitant peu de programmation, les fonctionnalités d'alerte et de notification, ainsi que d'autres fonctionnalités d'analyse.

Considérations et choix architecturaux

Les sections suivantes décrivent les choix architecturaux que vous pouvez faire pour une architecture de plate-forme IoT et leur impact.

Points de terminaison d'ingestion

La plupart des applications de plate-forme IoT commerciales incluent un point de terminaison MQTT et généralement un point de terminaison HTTPS pour l'ingestion de données à partir d'appareils connectés.

MQTT

Une plate-forme IoT implémente un point de terminaison MQTT de l'une des manières suivantes :

  • Un connecteur entre MQTT et un autre service de messagerie
  • Un agent MQTT qui implémente la spécification MQTT complète

Lorsque vous évaluez des plates-formes IoT professionnelles, il est important de savoir laquelle des approches précédentes le fournisseur a choisie pour le produit afin de pouvoir déterminer les implications pour votre cas d'utilisation.

Dans certains cas, le point de terminaison MQTT connecte uniquement les clients MQTT à un service de messagerie de backend, tel que Kafka ou Pub/Sub. Ce type de point de terminaison n'implémente généralement pas la spécification complète du protocole MQTT et n'inclut généralement pas de fonctionnalités telles que les niveaux de qualité QoS 1 et 2, ni les abonnements partagés. L'avantage de cette approche est qu'elle réduit la complexité de la plate-forme IoT, car il n'existe pas d'application d'agent MQTT distincte. Les coûts opérationnels sont réduits et la maintenance est plus simple que si la plate-forme utilisait un agent MQTT distinct. Cependant, en raison de la compatibilité réduite avec les fonctionnalités de protocole MQTT plus avancées, cette approche offre moins de flexibilité et de fonctionnalités pour le transport de messages MQTT qu'un agent MQTT autonome qui implémente la spécification MQTT complète.

D'autres plates-formes IoT fournissent un agent MQTT complet intégré, comme indiqué dans l'exemple d'architecture de ce document. Cet agent peut être l'un des agents Open Source existants ou une implémentation propriétaire. Un agent MQTT complet fournit la fonctionnalité MQTT bidirectionnelle complète décrite précédemment. Cependant, un agent complet peut ajouter de la complexité et des coûts opérationnels à la gestion de la plate-forme IoT.

HTTPS et autres protocoles complémentaires

Outre MQTT, de nombreuses plates-formes IoT fournissent davantage de points de terminaison d'ingestion de données que ceux présentés dans l'architecture principale décrite dans ce document.

HTTPS est une alternative courante au protocole MQTT pour les cas d'utilisation d'appareils connectés. Le coût de la solution est plus élevé que MQTT, mais celui-ci est davantage compatible avec les appareils mobiles (tels que les téléphones), les navigateurs Web et autres applications. Il est souvent utilisé dans certaines applications d'appareils connectés et compatible avec les plates-formes Open Source comme Eclipse Hono et de nombreux produits commerciaux.

De nombreuses applications d'appareils contraints utilisent le protocole CoAP (Contrained Application Protocol), défini dans le document RFC 7252, comme alternative à MQTT. Le CoAP cible des clients à faible consommation et peu gourmands en ressources pour les appareils et les capteurs intégrés. De nombreuses applications de plate-forme IoT commerciales fournissent également un point de terminaison CoAP.

Équilibrage de charge

Pour plus d'informations sur le choix du meilleur équilibreur de charge pour votre architecture, consultez la section d'équilibrage de charge de l'architecture d'agent MQTT autonome sur Google Cloud, car ces considérations s'appliquent également dans le cas présent.

Authentification des appareils et gestion des identifiants

La gestion des identifiants et de l'authentification des appareils est un élément clé du fonctionnement d'une plate-forme IoT. Les méthodes d'authentification compatibles avec les appareils connectés varient considérablement selon les applications et les facteurs de forme des appareils. Il est important de sélectionner la méthode d'authentification appropriée pour le cas d'utilisation cible et d'implémenter correctement le schéma d'authentification choisi.

Contrairement à un agent MQTT autonome, une plate-forme IoT fournit des services intégrés pour gérer l'identité et les identifiants de l'appareil. La plupart des plates-formes IoT utilisent l'authentification par certificat client X.509 pour l'authentification, l'authentification basée sur un jeton JWT (souvent combinée avec OAuth 2.0) et l'authentification par nom d'utilisateur et mot de passe. Certaines plates-formes sont également compatibles avec l'intégration à un fournisseur d'authentification LDAP externe.

Pour certains appareils contraints, l'authentification par JWT ou par nom d'utilisateur et mot de passe peut être plus appropriée, car ces schémas nécessitent moins de ressources sur un appareil connecté. Lorsque vous utilisez l'authentification JWT ou le nom d'utilisateur et le mot de passe, il est important de chiffrer la connexion réseau séparément de l'authentification mTLS, car aucune connexion chiffrée n'est requise par ces méthodes d'authentification. En revanche, l'authentification par certificat X.509 consomme plus de ressources sur l'appareil connecté. Elle est généralement utilisée dans une connexion chiffrée par mTLS et fournit donc un niveau élevé de sécurité.

Le provisionnement des identifiants d'authentification sur l'appareil de périphérie lors de la fabrication est également important dans le cadre du schéma d'authentification de l'appareil connecté. Cependant, ce sujet n'entre pas dans le cadre de ce document.

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.

Gérer les appareils connectés

En règle générale, les appareils connectés publient des événements de télémétrie et des informations d'état sur la plate-forme via l'un des points de terminaison d'ingestion, tels que MQTT. Si vous utilisez une plate-forme IoT multiprotocole, les appareils peuvent communiquer à l'aide de l'un des protocoles compatibles.

Nous recommandons que votre organisation utilise une plate-forme IoT dotée des fonctionnalités suivantes :

  • Mises à jour logicielles et système : livraison et rollback des mises à jour du micrologiciel, des logiciels et des applications sur les appareils connectés. En règle générale, ces mises à jour impliquent également le stockage et la gestion des mises à jour elles-mêmes.
  • Mises à jour de la configuration : livraison, stockage et rollback des mises à jour dans la configuration des applications déployées sur les appareils connectés
  • Création et gestion des identifiants : création de nouveaux identifiants d'appareils, transmission de ces identifiants aux appareils connectés, audit des tentatives et activités d'accès aux appareils, révocation des identifiants expirés ou compromis au moment approprié.
  • Moteur de règles et traitement des données : définition et exécution des règles basées sur les données et des autres étapes de traitement des données. Cette fonctionnalité inclut souvent un type d'interface nécessitant peu de programmation pour définir des règles et des pipelines de traitement de données.

Charges de travail de backend

La plupart des plates-formes IoT fournissent leurs propres fonctionnalités de stockage et de transport de données internes qui vous permettent de vous connecter à vos charges de travail et applications de backend. AMQP, RabbitMQ et Kafka sont couramment utilisés pour fournir le transport de données interne. Ces plates-formes peuvent toutes être connectées à Pub/Sub à l'aide du SDK Pub/Sub. Vous pouvez également utiliser un système de base de données intégré, tel que PostgreSQL, pour stocker les données sur la plate-forme. Dans de nombreux cas, la plate-forme IoT peut être configurée pour utiliser directement l'un des produits Cloud Storage, tels que Cloud SQL, Firebase ou BigQuery.

Si la plate-forme IoT dispose d'un agent MQTT complet, les applications backend peuvent également communiquer avec les appareils à l'aide de la fonctionnalité MQTT de la plate-forme. Si l'application est compatible avec MQTT, elle peut se connecter à l'agent en tant qu'abonné. En l'absence de compatibilité MQTT, Apache Beam fournit un pilote MQTT qui permet une intégration bidirectionnelle avec Dataflow ainsi que d'autres déploiements Beam.

Cas d'utilisation

Les sections suivantes décrivent des exemples de scénarios dans lesquels une plate-forme IoT est un meilleur choix architectural qu'un agent MQTT autonome ou une connexion directe à Pub/Sub.

Gestion des appareils intelligents

Les applications qui gèrent plusieurs appareils intelligents sont parfaitement adaptées à une plate-forme IoT. Une application de ce type est une plate-forme permettant de gérer les équipements de cuisine, tels qu'un lave-vaisselle et une cafetière. Ces appareils se connectent généralement à une application basée sur le cloud, directement via Wi-Fi ou une passerelle locale utilisant une connectivité Bluetooth à faible consommation (BLE) ou un autre protocole local. Les fonctionnalités de gestion d'une plate-forme IoT sont importantes ici, pour surveiller l'état de chaque appareil, gérer les mises à jour logicielles et les correctifs de sécurité, et capturer l'activité des appareils pour fournir des informations critiques au fabricant et au client. Ces fonctionnalités n'entrent pas dans le champ d'application d'un agent MQTT de base. Pour créer une plate-forme de gestion d'appareils intelligents réussie, vous devez au minimum disposer d'un dépôt d'informations provenant des appareils, d'une base de données d'état des appareils, d'un datastore de télémétrie et d'une interface d'analyse.

Logistique et suivi des ressources

Pour une application logistique et de suivi des ressources, un produit de plate-forme IoT offre des fonctionnalités plus complètes qu'un agent MQTT de base. Il constitue donc un meilleur choix pour ce cas d'utilisation. La surveillance de l'état et de l'emplacement actuels et passés d'un grand parc de ressources dépend d'une base de données d'état des appareils et d'un système de gestion des identités robustes. À mesure que de nouvelles ressources sont déployées, elles doivent être connectées à la plate-forme avec le moins de frictions possible, puis surveillées tout au long de leur cycle de vie. Dans de nombreux cas, l'application collecte également d'autres informations sur les capteurs, telles que la température locale, l'humidité et la pression atmosphérique, ou les données de positionnement et d'accélération 3D pour détecter les mouvements ou les baisses inattendus. Toutes ces données doivent être ingérées et associées à la ressource appropriée pour l'analyse dans une application backend. C'est pourquoi la gestion complète des appareils fournie par la plate-forme IoT est une fonctionnalité importante.

Étapes suivantes