Appareils sur une connexion Pub/Sub vers Google Cloud

Last reviewed 2024-08-09 UTC

Plutôt que d'implémenter une architecture spécifique pour connecter des appareils aux applications d'analyse, la connexion directe à Pub/Sub depuis les appareils de périphérie peut présenter des avantages pour certaines entreprises. Nous recommandons cette approche si vous disposez d'un petit nombre d'appareils connectés qui agrègent les données d'un plus grand nombre d'appareils et de capteurs dans un réseau local ou sur site. Cette approche est également recommandée si vous disposez d'appareils connectés situés dans un environnement plus sécurisé, tel qu'une usine. Ce document décrit les considérations architecturales générales à prendre en compte pour connecter ces appareils aux produits 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 :

Architecture

Le schéma suivant montre un appareil d'agrégation connecté ou une passerelle qui se connecte directement à Pub/Sub.

Architecture d'appareil d'agrégation ou de passerelle connectés à Pub/Sub (flux d'événements expliqué dans le texte suivant)

Le flux d'événements du schéma précédent se présente comme suit :

  • Vous utilisez l'API Identity and Access Management pour créer une paire de clés pour un compte de service. La clé publique est stockée dans IAM. Cependant, vous devez télécharger la clé privée de manière sécurisée et la stocker sur la passerelle afin qu'elle puisse être utilisée pour l'authentification.
  • L'appareil d'agrégation collecte des données à partir de plusieurs autres appareils et capteurs distants situés au sein d'un réseau local sécurisé. Les appareils distants communiquent avec la passerelle à l'aide d'un protocole périphérique local, tel que MODBUS, BACNET, OPC-UA ou autre protocole local.
  • L'appareil d'agrégation envoie des données à Pub/Sub via HTTPS ou gRPC. Ces appels d'API sont signés à l'aide de la clé privée du compte de service détenue sur l'appareil d'agrégation.

Considérations et choix architecturaux

Comme Pub/Sub est un service de streaming de données sans serveur, vous pouvez l'utiliser pour créer des systèmes bidirectionnels composés de producteurs et de consommateurs (appelés éditeurs et abonnés). Dans certains scénarios d'appareils connectés, vous n'avez besoin que d'un service d'abonnement et de publication évolutif pour créer une architecture de données efficace. Les sections suivantes décrivent les considérations à prendre en compte et les choix à faire lorsque vous implémentez un appareil sur une architecture Pub/Sub sur Google Cloud.

Points de terminaison d'ingestion

Pub/Sub fournit des bibliothèques clientes prédéfinies dans plusieurs langages qui implémentent les API REST et gRPC. Il est compatible avec deux protocoles d'ingestion de messages : REST (HTTP) et gRPC. Pour qu'un appareil connecté puisse envoyer et recevoir des données via Pub/Sub, il doit pouvoir interagir avec l'un de ces points de terminaison.

De nombreuses applications logicielles intègrent la compatibilité avec les API REST. La connexion à l'aide de l'API REST Pub/Sub est donc souvent la solution la plus simple. Toutefois, dans certains cas, gRPC peut être une alternative plus efficace et plus rapide. Étant donné qu'il utilise des tampons de protocole sérialisés pour la charge utile des messages au lieu de JSON, XML ou d'un autre format textuel, gRPC est mieux adapté aux applications à faible bande passante couramment utilisées pour les appareils connectés. Les connexions de l'API gRPC sont également plus rapides que REST pour la transmission de données, et gRPC prend en charge les communications bidirectionnelles simultanées. Une étude montre que gRPC est jusqu'à sept fois plus rapide que REST. Par conséquent, dans de nombreux scénarios d'appareils connectés, gRPC constitue une meilleure option si un connecteur gRPC est disponible ou peut être implémenté pour l'application d'appareils connectés.

Authentification des appareils et gestion des identifiants

Pub/Sub accepte un certain nombre de méthodes d'authentification pour l'accès en dehors de Google Cloud.

Si votre architecture inclut un fournisseur d'identité externe tel qu'Active Directory ou un cluster Kubernetes local, vous pouvez utiliser la fédération d'identité de charge de travail pour gérer l'accès à Pub/Sub. Cette approche vous permet de créer des jetons d'accès éphémères pour les appareils connectés. Vous pouvez également attribuer des rôles IAM à vos appareils connectés, sans les frais de gestion et de sécurité liés à l'utilisation de clés de compte de service.

Si aucun fournisseur d'identité externe n'est disponible, les clés de compte de service sont la seule option d'authentification. Les clés de compte de service peuvent présenter un risque pour la sécurité si elles ne sont pas gérées correctement. Par conséquent, nous vous recommandons de suivre les bonnes pratiques de sécurité pour déployer des clés de compte de service sur des appareils connectés. Pour en savoir plus, consultez la page Bonnes pratiques de gestion des clés de compte de service. Les comptes de service sont également des ressources limitées, et tout projet cloud dispose d'un quota limité de comptes de service gérés par l'utilisateur. Par conséquent, cette approche ne doit être envisagée que pour les déploiements comportant un petit nombre d'appareils à connecter.

Applications backend

Une fois les données ingérées dans un sujet Pub/Sub, elles sont disponibles pour toute application s'exécutant sur Google Cloud disposant des identifiants appropriés et des droits d'accès. Aucun connecteur supplémentaire n'est nécessaire en dehors de l'API Pub/Sub dans votre application. Les messages peuvent être mis à la disposition de plusieurs applications sur votre infrastructure backend pour un traitement ou des alertes en parallèle, ainsi que pour le stockage d'archives et d'autres analyses.

Cas d'utilisation

Les sections suivantes décrivent des exemples de scénarios dans lesquels une connexion directe des appareils à Pub/Sub convient parfaitement aux appareils connectés.

Ingestion groupée de données à partir d'un historique de données sur site

La connexion d'appareils à Pub/Sub est particulièrement adaptée aux applications comportant un petit nombre de points de terminaison qui transmettent de grands volumes de données. Un historique des données opérationnelles est un bon exemple de système sur site qui stocke de nombreuses données devant être transmises à Google Cloud. Pour ce cas d'utilisation, un petit nombre de points de terminaison doit être authentifié, généralement un à quelques appareils connectés, ce qui correspond aux paramètres types de l'authentification de compte de service. Ces systèmes possèdent également des architectures modulaires, ce qui vous permet d'implémenter la connexion de l'API Pub/Sub nécessaire pour communiquer avec Google Cloud.

Agrégation de données de passerelle locale pour une usine

L'agrégation des données de capteurs d'usine dans une passerelle locale est un autre cas d'utilisation bien adapté à une connexion Pub/Sub directe. Dans ce cas, un système local de gestion et d'agrégation des données est déployé sur un dispositif de passerelle dans l'usine. Ce système est généralement un produit logiciel qui se connecte à un large éventail de capteurs et de machines locaux. Le produit collecte les données et les transforme fréquemment en une représentation standardisée avant de les transmettre à l'application cloud.

Dans ce scénario, de nombreux appareils peuvent être connectés. Cependant, ces appareils ne sont généralement connectés qu'à la passerelle locale et sont gérés par le logiciel sur cet appareil. Vous n'avez donc pas besoin d'une application de gestion dans le cloud. Contrairement à une architecture d'agent MQTT, dans ce cas d'utilisation, la passerelle joue un rôle actif dans l'agrégation et la transformation des données.

Lorsque la passerelle se connecte à Google Cloud, elle s'authentifie auprès de Pub/Sub via une clé de compte de service. La clé envoie les données agrégées et transformées à l'application cloud pour un traitement ultérieur. Le nombre de passerelles connectées est généralement compris entre 10 et 100 appareils, ce qui se situe dans la plage typique d'authentification de compte de service.

Étapes suivantes