Conexión de dispositivo en 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 analíticas, algunas organizaciones pueden beneficiarse de la conexión directa a Pub/Sub desde dispositivos periféricos. Recomendamos este enfoque a las organizaciones que tienen un número reducido de dispositivos conectados que agregan datos de un número mayor de dispositivos y sensores en una red local o en las instalaciones. También se recomienda este método 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 de arquitectura de alto nivel que debe tener en cuenta para usar este enfoque y conectar dispositivos a productos de Google Cloud .

Este documento forma 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 o una pasarela de agregación conectados que se conectan directamente a Pub/Sub.

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

El flujo de eventos del diagrama anterior es el siguiente:

  • Utiliza la API Identity and Access Management para crear un nuevo par de claves 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 la pasarela para que se pueda usar en la autenticación.
  • El dispositivo de agregación recoge datos de varios dispositivos remotos y sensores ubicados en una red local segura. Los dispositivos remotos se comunican con la pasarela mediante un protocolo de periferia local, como MODBUS, BACNET, OPC-UA u 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 opciones de arquitectura

Como Pub/Sub es un servicio de streaming de datos sin servidor, puedes usarlo para crear sistemas bidireccionales compuestos por productores y consumidores de eventos (conocidos como editores y suscriptores). En algunos casos 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 los aspectos que debe tener en cuenta y las decisiones que debe tomar al implementar una arquitectura de publicación/suscripción en Google Cloud.

Endpoints de ingestión

Pub/Sub proporciona bibliotecas de cliente prediseñadas en varios idiomas que implementan las APIs REST y gRPC. Admite dos protocolos para la ingestión de mensajes: REST (HTTP) y gRPC. Para que un dispositivo conectado pueda enviar y recibir datos a través de Pub/Sub, debe poder interactuar con uno de estos endpoints.

Muchas aplicaciones de software tienen compatibilidad integrada con las APIs REST, por lo que conectarse con la API REST de Pub/Sub suele ser la solución más sencilla. Sin embargo, en algunos casos prácticos, gRPC puede ser una alternativa más eficiente y rápida. Como utiliza búferes de protocolo serializados para la carga útil de los mensajes en lugar de JSON, XML u otro formato basado en texto, gRPC es más adecuado para las aplicaciones con poco ancho de banda que se suelen encontrar en los casos prácticos de dispositivos conectados. Las conexiones de la API gRPC también son más rápidas que las de REST para la transmisión de datos, y gRPC admite la comunicación bidireccional simultánea. Un estudio reveló que gRPC es hasta siete veces más rápido que REST. Por lo tanto, en muchos casos de dispositivos conectados, gRPC es una mejor opción si hay un conector gRPC disponible o si se puede implementar para la aplicación del dispositivo conectado.

Autenticación de dispositivos y gestión de credenciales

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

Si tu arquitectura incluye un proveedor de identidades externo, como Active Directory o un clúster de Kubernetes local, puedes usar la federación de identidades de carga de trabajo para gestionar el acceso a Pub/Sub. Este método te permite crear tokens de acceso de corta duración para los dispositivos conectados. También puedes conceder roles de gestión de identidades y accesos a tus dispositivos conectados sin la sobrecarga de gestión y seguridad que supone usar claves de cuentas de servicio.

En los casos en los que no haya disponible un proveedor de identidades externo, las claves de cuenta de servicio serán la única opción de autenticación. Las claves de las cuentas de servicio pueden suponer un riesgo para la seguridad si no se gestionan correctamente, por lo que te recomendamos que sigas las prácticas recomendadas de seguridad para desplegar las claves de las cuentas de servicio en los dispositivos conectados. Para obtener más información, consulta las prácticas recomendadas para gestionar las 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 gestionadas por el usuario. Por lo tanto, este enfoque solo es una opción para las implementaciones que tienen un número reducido de dispositivos que deben conectarse.

Aplicaciones de backend

Una vez que los datos se han ingerido en un tema de Pub/Sub, 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, solo la API Pub/Sub en tu aplicación. Los mensajes se pueden poner a disposición de varias aplicaciones de tu infraestructura backend para que se procesen o se envíen alertas en paralelo, así como para el almacenamiento de archivos y otras analíticas.

Casos prácticos

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

Ingestión de datos en bloque desde un historial de datos local

Una conexión de dispositivo a Pub/Sub es más adecuada para aplicaciones que tienen un número reducido de endpoints que transmiten grandes volúmenes de datos. Un historial de datos operativos es un buen ejemplo de un sistema local que almacena una gran cantidad de datos que deben transmitirse aGoogle Cloud. En este caso práctico, se debe autenticar un número reducido de endpoints, normalmente de uno a unos pocos dispositivos conectados, lo que se encuentra dentro de los parámetros típicos de 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 Pub/Sub que necesitas para comunicarte con Google Cloud.

Agregación de datos de pasarela local de una fábrica

La agregación de datos de sensores de fábrica en una pasarela local es otro caso de uso adecuado para una conexión directa de Pub/Sub. En este caso, se implementan un sistema de gestión y agregación de datos locales en un dispositivo de pasarela de la fábrica. Este sistema suele ser un producto de software que se conecta a una amplia variedad de sensores y máquinas locales. El producto recoge los datos y los transforma con frecuencia en una representación estandarizada antes de enviarlos a la aplicación en la nube.

En este caso, se pueden conectar muchos dispositivos. Sin embargo, estos dispositivos suelen conectarse únicamente a la pasarela local y se gestionan mediante el software del dispositivo, por lo que no es necesario usar una aplicación de gestión basada en la nube. A diferencia de la arquitectura de un broker MQTT, en este caso de uso, la pasarela desempeña un papel activo en la agregación y transformación de los datos.

Cuando la pasarela se conecta a Google Cloud, se autentica con Pub/Sub mediante una clave de cuenta de servicio. La clave envía los datos agregados y transformados a la aplicación en la nube para que se sigan procesando. El número de pasarelas conectadas también suele oscilar entre decenas y cientos de dispositivos, lo que se encuentra dentro del intervalo habitual para la autenticación de cuentas de servicio.

Siguientes pasos