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

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. Este enfoque también se recomienda 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 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. 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 a través de un protocolo de borde 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

Dado que Pub/Sub es un servicio de transmisión de datos sin servidores, puedes usarlo para crear sistemas bidireccionales compuestos por productores y consumidores de eventos (conocidos como publicadores 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 las consideraciones y las decisiones que debes tomar cuando implementes una arquitectura de dispositivo a Pub/Sub en Google Cloud.

Extremos de transferencia

Pub/Sub proporciona bibliotecas cliente prediseñadas 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, debe poder interactuar con uno de estos extremos.

Muchas aplicaciones de software tienen compatibilidad integrada con las APIs de REST, por lo que conectarse 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.

Administración de credenciales y autenticación de dispositivos

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

Si tu 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 los dispositivos conectados. También puedes otorgar roles de IAM a tus dispositivos conectados, sin la sobrecarga de administración y seguridad que implica el uso de claves de cuentas 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 de forma adecuada, las claves de cuentas 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 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 Cloud 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, estos está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 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 para 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 los dispositivos a Pub/Sub es adecuada para los casos de uso de dispositivos conectados.

Transferencia masiva de datos desde un historial 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 historial de datos operativos es un buen ejemplo de un sistema local que almacena muchos datos que deben transmitirse aGoogle Cloud. En este caso de uso, se debe autenticar una pequeña cantidad de extremos, por lo general, de uno a unos pocos dispositivos conectados, lo 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 a 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 de sensores de fábrica en una puerta de enlace local es otro caso de uso adecuado para una conexión directa a 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 de 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 este caso, se pueden conectar muchos dispositivos. Sin embargo, esos dispositivos suelen conectarse solo a la puerta de enlace local y se administran con el software de ese dispositivo, por lo que no se necesita una aplicación de administración basada en la nube. A diferencia de la arquitectura de un 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 clave 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, lo que se encuentra dentro del rango típico para la autenticación de cuentas de servicio.

¿Qué sigue?