Conexión del dispositivo de Pub/Sub a Google Cloud

Last reviewed 2023-01-26 UTC

En lugar de implementar una arquitectura específica para conectar dispositivos a aplicaciones de estadísticas, algunas organizaciones podrían beneficiarse de conectarse directamente a Pub/Sub desde dispositivos perimetrales. Recomendamos este enfoque para las organizaciones que tienen una pequeña cantidad de dispositivos conectados que agregan datos de una mayor cantidad de dispositivos y sensores en una red local o local. Este enfoque también se recomienda cuando la organización tiene dispositivos conectados que están en un entorno más seguro, como una fábrica. En este documento, se describen las consideraciones arquitectónicas de alto nivel que debes tomar para usar este enfoque a fin de conectar dispositivos a productos de Google Cloud.

Este documento es parte de una serie de documentos que proporcionan información sobre las arquitecturas de IoT en Google Cloud y la migración desde IoT Core. Los otros documentos de esta serie incluyen lo siguiente:

Arquitectura

En el siguiente diagrama, se muestra un dispositivo de agregación conectado o una puerta de enlace que se conecta directamente a Pub/Sub.

Arquitectura de puerta de enlace o dispositivo de agregación conectada a Pub/Sub (flujo de eventos que se explica en el siguiente texto).

El flujo de eventos en el diagrama anterior es el siguiente:

  • Usa la API de Identity and Access Management a fin de crear un par de claves nuevo para una cuenta de servicio. La clave pública se almacena en IAM. Sin embargo, debes descargar la clave privada de forma segura y almacenarla en el dispositivo de puerta de enlace para que pueda usarse en la autenticación.
  • El dispositivo de agregación recopila datos de otros dispositivos remotos y sensores ubicados dentro de una red local segura. Los dispositivos remotos se comunican con la puerta de enlace mediante un protocolo perimetral local, como MODBUS, BACNET, OPC-UA o algún otro protocolo local.
  • El dispositivo de agregación envía datos a Pub/Sub a través de HTTPS o gRPC. Estas llamadas a la API se firman mediante la clave privada de la cuenta de servicio que se guarda en el dispositivo de agregación.

Consideraciones y elecciones de arquitectura

Debido a que Pub/Sub es un servicio de transmisión de datos sin servidores, puedes usarlo para crear sistemas bidireccionales compuestos por consumidores y consumidores de eventos (conocidos como publicadores y suscriptores). En algunos casos de dispositivos conectados, solo necesitas un servicio escalable de publicación y suscripción para crear una arquitectura de datos efectiva. En las siguientes secciones, se describen las consideraciones y decisiones que debes tomar cuando implementas un dispositivo en la arquitectura de Pub/Sub en Google Cloud.

Extremos de transferencia

Pub/Sub proporciona bibliotecas cliente compiladas previamente en varios lenguajes que implementan las API de REST y de gRPC. Admite dos protocolos para la transferencia de mensajes: REST (HTTP) y gRPC. Para que un dispositivo conectado envíe y reciba datos a través de Pub/Sub, el dispositivo debe poder interactuar con uno de estos extremos.

Muchas aplicaciones de software tienen compatibilidad integrada con las API de REST, por lo que conectarse con la API de REST de Pub/Sub suele ser la solución más fácil. Sin embargo, en algunos casos de uso, gRPC puede ser una alternativa más eficiente y rápida. Debido a que usa búferes de protocolo serializados para la carga útil de mensajes en lugar de JSON, XML o algún otro formato basado en texto, gRPC es más adecuado para las aplicaciones de ancho de banda bajo que se encuentran comúnmente en casos de uso de dispositivos conectados. Las conexiones a la API de gRPC también son más rápidas que REST para la transmisión de datos, y gRPC admite la comunicación bidireccional simultánea. En un estudio, se descubrió que gRPC es hasta siete veces más rápido que REST. Como resultado, en muchas situaciones de dispositivos conectados, gRPC es una mejor opción si hay un conector de gRPC disponible o se puede implementar para la aplicación de dispositivo conectado.

Autenticación del dispositivo y administración de credenciales

Pub/Sub admite varios métodos de autenticación para acceder desde fuera de Google Cloud.

Si la arquitectura incluye un proveedor de identidad externo, como Active Directory o un clúster de Kubernetes local, puedes usar la federación de identidades para cargas de trabajo. para administrar el acceso a Pub/Sub. Este enfoque te permite crear tokens de acceso de corta duración para dispositivos conectados. También puedes otorgar funciones de IAM a tus dispositivos conectados, sin la sobrecarga de administración y seguridad del uso de claves de cuenta de servicio.

En los casos en que un proveedor de identidad externo no esté disponible, las claves de cuenta de servicio son la única opción para la autenticación. Las claves de las cuentas de servicio pueden convertirse en un riesgo de seguridad si no se administran de forma correcta, por lo que te recomendamos seguir las prácticas recomendadas de seguridad para implementar claves de cuentas de servicio en dispositivos conectados. Si quieres obtener más información, consulta Prácticas recomendadas para administrar claves de cuentas de servicio. Las cuentas de servicio también son un recurso limitado y cualquier proyecto de la nube tiene una cuota limitada de cuentas de servicio administradas por el usuario. En consecuencia, este enfoque es solo una opción para las implementaciones que tienen una pequeña cantidad de dispositivos que deben conectarse.

Aplicaciones de backend

Después de transferir los datos a un tema de Pub/Sub, los datos estarán disponibles para cualquier aplicación que se ejecute en Google Cloud y que tenga las credenciales y los privilegios de acceso adecuados. No se necesitan conectores adicionales además de la API de Pub/Sub en la aplicación. Los mensajes pueden estar disponibles para varias aplicaciones en tu infraestructura de backend a fin de realizar el procesamiento o las alertas paralelos, así como el almacenamiento de archivos y otras estadísticas.

Casos de uso

En las siguientes secciones, se describen situaciones de ejemplo en las que una conexión directa de dispositivos a Pub/Sub es adecuada para casos prácticos de dispositivos conectados.

Transferencia masiva de datos de un historiador de datos local

Una conexión de Pub/Sub es más adecuada para aplicaciones con una pequeña cantidad de extremos que transmiten grandes volúmenes de datos. Un historial de datos operativo es un buen ejemplo de un sistema local que almacena muchos datos que se deben transmitir a Google Cloud. Para este caso práctico, se debe autenticar una pequeña cantidad de extremos, por lo general, de uno a unos dispositivos conectados, que se encuentra dentro de los parámetros típicos para la autenticación de la cuenta de servicio. Por lo general, estos sistemas tienen arquitecturas modulares, que te permiten implementar la conexión de la API de Pub/Sub que necesitas para comunicarte con Google Cloud.

Agregación de datos de la puerta de enlace local para una fábrica

La agregación de datos del sensor de fábrica en una puerta de enlace local es otro caso práctico adecuado para una conexión directa de Pub/Sub. En este caso, un sistema de administración y agregación de datos local se implementa en un dispositivo de puerta de enlace en la fábrica. Por lo general, este sistema es un producto de software que se conecta a una amplia variedad de sensores y máquinas locales. El producto recopila los datos y, con frecuencia, los transforma en una representación estandarizada antes de pasarlos a la aplicación en la nube.

En esta situación, se pueden conectar muchos dispositivos. Sin embargo, por lo general, esos dispositivos solo se conectan a la puerta de enlace local y se administran mediante el software en ese dispositivo, por lo que no es necesario usar una aplicación de administración basada en la nube. A diferencia de una arquitectura de agente de MQTT, en este caso práctico, la puerta de enlace cumple una función activa para agregar y transformar los datos.

Cuando la puerta de enlace se conecta a Google Cloud, se autentica con Pub/Sub a través de una clave de cuenta de servicio. La clave envía los datos agregados y transformados a la aplicación en la nube para su procesamiento posterior. La cantidad de puertas de enlace conectadas también suele estar en el rango de decenas a cientos de dispositivos, que se encuentra dentro del rango típico para la autenticación de la cuenta de servicio.

¿Qué sigue?