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 de borde. 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 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:
- Descripción Google Cloud general de las arquitecturas de dispositivos conectados en Google Cloud
- Arquitectura del agente de MQTT independiente en Google Cloud
- Arquitectura de productos de la plataforma de IoT en Google Cloud
- Prácticas recomendadas para ejecutar un backend de IoT en Google Cloud
- Arquitectura de dispositivo en Pub/Sub a Google Cloud (este documento)
- Prácticas recomendadas para aprovisionar y configurar de forma automática sistemas y servidores perimetrales y bare metal
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.
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 la puerta de enlace para que se pueda usar en 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 cualquier 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 almacena 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 tener en cuenta cuando implementas un dispositivo en la arquitectura de 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 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 de dispositivos y administració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 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 roles 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. Las claves de cuenta de servicio pueden convertirse en un riesgo de seguridad si no se administran de forma correcta, 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 se deben conectar.
Aplicaciones de backend
Después de que los datos se transfieren a 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, además de la API de Pub/Sub, en tu aplicación. Los mensajes se pueden poner a disposición de varias aplicaciones en tu infraestructura de backend para el procesamiento en paralelo o las alertas, así como el almacenamiento de archivos y otras estadísticas.
Casos de uso
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 los casos de uso de dispositivos conectados.
Transferencia 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 muchos datos que se deben transmitir aGoogle Cloud. Para este caso de uso, se debe autenticar una pequeña cantidad de extremos, por lo general, uno o varios dispositivos conectados, que se encuentra dentro de los parámetros típicos de la autenticación de cuentas de servicio. Por lo general, estos sistemas también tienen arquitecturas modulares, lo que te permite 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 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 de agregación y administración de datos local 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, a menudo, 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 el software de ese dispositivo los administra, por lo que no es necesario contar con 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 rol 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 procesamiento adicional. Por lo general, la cantidad de puertas de enlace conectadas también está en el rango de decenas a cientos de dispositivos, que está dentro del rango típico de la autenticación de cuentas de servicio.
¿Qué sigue?
- Descubre las prácticas recomendadas para administrar claves de cuenta de servicio
- Lee una descripción general de la federación de identidades para cargas de trabajo externas.
- Más información sobre Pub/Sub
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas para Google Cloud. Consulta nuestro Cloud Architecture Center.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.