Dispositivo en conexión de Pub/Sub a Google Cloud

Last reviewed 2024-08-09 UTC

En lugar de implementar una arquitectura específica para conectar dispositivos a aplicaciones de análisis, algunas organizaciones podrían beneficiarse de la conexión directa 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 en las instalaciones. También se recomienda este enfoque cuando tu organización tiene dispositivos conectados que se encuentran 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 para conectar dispositivos a Google Cloud productos.

Este documento es parte de una serie de documentos que proporcionan información sobre las arquitecturas de IoT en Google Cloud. 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 dispositivo de agregación o puerta de enlace 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 se pueda usar para la autenticación.
  • El dispositivo de agregación recopila datos de varios otros dispositivos y sensores remotos 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 con la clave privada de la cuenta de servicio que se encuentra 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 que se componen de productores y consumidores de eventos (conocidos como publicadores y suscriptores). En algunas situaciones de dispositivos conectados, solo necesitas un servicio de publicación y suscripción escalable para crear una arquitectura de datos eficaz. En las siguientes secciones, se describen las consideraciones y las opciones que debes tomar cuando implementas una arquitectura de dispositivo a Pub/Sub en Google Cloud.

Extremos de transferencia

Pub/Sub proporciona bibliotecas cliente precompiladas en varios lenguajes que implementan las APIs de REST y 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 APIs de REST, por lo que la conexión con la API de REST de Pub/Sub suele ser la solución más sencilla. 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 de dispositivos y administración de credenciales

Pub/Sub admite varios métodos de autenticación para el acceso desde el exterior 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 de usar claves de cuenta de servicio.

En los casos en que no hay un proveedor de identidad externo disponible, las claves de cuenta de servicio son la única opción para la autenticación. Si no se administran correctamente, las claves de cuenta de servicio pueden convertirse en un riesgo para la seguridad, por lo que te recomendamos que sigas las prácticas recomendadas de seguridad para implementar claves de cuenta 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 nube tiene una cuota limitada de cuentas de servicio administradas por el usuario. Por lo tanto, este enfoque solo es una opción para las implementaciones que tienen una pequeña cantidad de dispositivos que deben conectarse.

Aplicaciones de backend

Después de que se transfieren los datos a un tema de Pub/Sub, los datos están disponibles para cualquier aplicación que se ejecute en Google Cloud que tenga las credenciales y los privilegios de acceso adecuados. No se necesitan conectores adicionales más allá de la API de Pub/Sub en tu aplicación. Los mensajes pueden estar disponibles para varias aplicaciones en tu infraestructura de backend para el procesamiento o las alertas en paralelo, así como el almacenamiento de archivos y otros análisis.

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 de uso de dispositivos conectados.

Ingesta masiva de datos desde un historiador de datos local

Una conexión de dispositivo a Pub/Sub es más adecuada para aplicaciones que tienen una pequeña cantidad de extremos que transmiten grandes volúmenes de datos. Un historiador de datos operativos es un buen ejemplo de un sistema local que almacena una gran cantidad de datos que deben transmitirse a Google Cloud. Para este caso de uso, se debe autenticar una pequeña cantidad de extremos, por lo general, uno a unos pocos dispositivos conectados, que se encuentra dentro de los parámetros típicos para la autenticación de cuentas de servicio. Estos sistemas también suelen tener arquitecturas modulares, lo que te permite implementar la conexión de la API de Pub/Sub con la que necesitas comunicarte Google Cloud.

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

La agregación de datos de sensores de fábrica en una puerta de enlace local es otro caso de uso adecuado para una conexión directa de Pub/Sub. En este caso, se implementa un sistema local de administración y agregación de datos 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.

Se pueden conectar muchos dispositivos en esta situación. Sin embargo, esos dispositivos suelen estar conectados solo a la puerta de enlace local y se administran con el software de ese dispositivo, por lo que no es necesaria una aplicación de administración basada en la nube. A diferencia de una arquitectura de agente de MQTT, en este caso de uso, la puerta de enlace desempeña un papel activo en la agregación y transformación de 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 puerta de enlace envía los datos agregados y transformados a la aplicación en la nube para su posterior procesamiento. 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 cuentas de servicio.

¿Qué sigue?