Arquitectura del agente de MQTT independiente en Google Cloud

MQTT es un protocolo estándar de OASIS para aplicaciones de dispositivos conectados que proporciona mensajería bidireccional con una arquitectura de agente de publicación y suscripción. El protocolo MQTT es ligero para reducir la sobrecarga de la red, y los clientes de MQTT son muy pequeños para minimizar el uso de recursos en dispositivos con limitaciones. Una solución para las organizaciones que desean admitir aplicaciones de dispositivos conectados enGoogle Cloud es ejecutar un agente de MQTT independiente en Compute Engine o GKE. Para implementar un agente de MQTT en tu organización, debes tomar varias decisiones clave que afectan la arquitectura general, en particular, el balanceo de cargas y el entorno de implementación. En este documento, se describe una arquitectura para implementar un agente de MQTT, la aplicación principal en una implementación de MQTT, en Google Cloud. También se describen las decisiones que debes tomar cuando implementas este agente y cómo afectan la arquitectura.

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:

En el siguiente diagrama, se muestra una arquitectura de agente de MQTT que se ejecuta enGoogle Cloud.

Diagrama de arquitectura del agente de MQTT (se explica en el siguiente texto).

La arquitectura de la imagen anterior se compone de la siguiente manera:

  • El agente de MQTT se implementa como un clúster de tres instancias que están conectadas al servicio de Cloud Load Balancing. En el caso del balanceador de cargas de Cloud, puedes elegir uno de los varios productos de balanceo de cargas, que se describen más adelante en este documento.
  • El clúster de intermediarios incluye un almacén de credenciales de dispositivos y un servicio de autenticación y autorización de dispositivos. El clúster se conecta con las cargas de trabajo de backend a través de Dataflow o Pub/Sub.
  • Del lado del cliente, las puertas de enlace perimetrales proporcionan comunicación bidireccional entre los dispositivos perimetrales y el clúster de agentes de MQTT a través de MQTT sobre TLS.

En general, recomendamos que implementes la aplicación del agente de MQTT para esta arquitectura en un clúster para lograr escalabilidad. Los factores como la funcionalidad de agrupamiento en clústeres, la administración de clústeres de escalamiento vertical y horizontal, la sincronización de datos y el control de particiones de red se abordan en las implementaciones específicas del agente.

Consideraciones y elecciones de arquitectura

En las siguientes secciones, se describen las diferentes opciones y consideraciones de arquitectura que debes tener en cuenta para una arquitectura de agente de MQTT independiente, así como el impacto que estas opciones tienen en la arquitectura.

Dispositivos conectados

Los dispositivos perimetrales conectados a Internet publican sus eventos de telemetría y otra información en el agente de MQTT. Para implementar la arquitectura de agente de MQTT independiente que se describe en este documento, el dispositivo debe tener un cliente de MQTT, la clave pública del certificado del servidor para la autenticación de TLS y las credenciales necesarias para autenticarse con el agente de MQTT.

Además, los dispositivos perimetrales suelen tener conectores a sensores locales, a sistemas de datos locales y a otros dispositivos que no tienen acceso a Internet ni conectividad IP. Por ejemplo, el dispositivo perimetral puede servir como puerta de enlace para otros dispositivos locales restringidos conectados a la puerta de enlace a través de BLE, una conexión con cable o algún otro protocolo de campo cercano. Una especificación detallada de la arquitectura del dispositivo conectado está fuera del alcance de esta guía.

Balanceo de cargas

En la arquitectura, se configura un servicio de balanceo de cargas externo entre la red pública y el clúster de intermediarios de MQTT. Este servicio proporciona varias funciones de redes importantes, como la distribución de conexiones entrantes entre los nodos de backend, la encriptación de sesiones y la autenticación.

Google Cloud admite varios tipos de balanceador de cargas. Para elegir el mejor balanceador de cargas para tu arquitectura, considera lo siguiente:

  • mTLS. mTLS controla los métodos de encriptación y autenticación del dispositivo, mientras que TLS estándar solo controla la encriptación y requiere un método de autenticación del dispositivo independiente:

  • Extremos HTTP(S). Si necesitas exponer extremos HTTP(S), te recomendamos que configures un balanceador de cargas de aplicaciones externo independiente para estos extremos.

Para obtener más información sobre los tipos de balanceador de cargas compatibles con Cloud Load Balancing, consulta Resumen de los balanceadores de cargas. Google Cloud

Estrategia de balanceo de cargas

Cualquier servicio de balanceo de cargas distribuye las conexiones de los dispositivos perimetrales entre los nodos del clúster según uno de varios algoritmos o modos de balanceo. Para MQTT, una estrategia de balanceo de cargas con afinidad de sesión es mejor que el balanceo de cargas aleatorio. Debido a que las conexiones cliente-servidor de MQTT son sesiones bidireccionales persistentes, el estado se mantiene en el nodo del agente que detiene la conexión. En una configuración en clúster, si un cliente se desconecta y, luego, se vuelve a conectar a un nodo diferente, el estado de la sesión se mueve al nodo nuevo, lo que agrega carga al clúster. Este problema se puede evitar en gran medida si se usa el balanceo de cargas con afinidad de sesión. Si los clientes cambian con frecuencia sus direcciones IP, la conexión puede interrumpirse, pero, en la mayoría de los casos, la afinidad de sesión es mejor para MQTT. La afinidad de sesión está disponible en todos los productos de Cloud Load Balancing.

Administración de credenciales y autenticación de dispositivos

Las aplicaciones de agentes de MQTT controlan la autenticación de dispositivos y el control de acceso por separado de Google Cloud. Una aplicación de agente también proporciona su propio almacén de credenciales y su interfaz de administración. El protocolo MQTT admite la autenticación básica con nombre de usuario y contraseña en el paquete Connect inicial, y las implementaciones de los intermediarios también usan con frecuencia estos campos para admitir otras formas de autenticación, como la autenticación con certificado X.509 o JWT. MQTT 5.0 también agrega compatibilidad con métodos de autenticación mejorados que usan autenticación de estilo desafío y respuesta. El método de autenticación que se usa depende de la aplicación del agente de MQTT que elijas y del caso de uso de tu dispositivo conectado.

Independientemente del método de autenticación que use el agente, este mantiene un almacén de credenciales del dispositivo. Este almacén puede estar en una base de datos SQL local o en un archivo plano. Algunos intermediarios también admiten el uso de un servicio de base de datos administrado, como Cloud SQL. Necesitas un servicio independiente para administrar el almacén de credenciales del dispositivo y controlar las integraciones con otros servicios de autenticación, como IAM. El desarrollo de este servicio está fuera del alcance de esta guía.

Para obtener más información sobre la autenticación y la administración de credenciales, consulta Prácticas recomendadas para ejecutar un backend de IoT en Google Cloud.

Cargas de trabajo de backend

Cualquier caso de uso de dispositivos conectados incluye una o más aplicaciones de backend que utilizan los datos transferidos desde los dispositivos conectados. A veces, estas aplicaciones también deben enviar comandos y actualizaciones de configuración a los dispositivos. En la arquitectura del agente de MQTT independiente que se describe en este documento, los datos entrantes y los comandos salientes se enrutan a través del agente de MQTT. Hay diferentes temas dentro de la jerarquía de temas del agente para diferenciar los datos de los comandos.

Los datos y los comandos se pueden enviar entre el agente y las aplicaciones de backend de varias maneras. Si la aplicación admite MQTT o si se puede modificar para que lo admita, la aplicación puede suscribirse directamente al agente como cliente. Este enfoque te permite usar la capacidad de mensajería bidireccional de MQTT Pub/Sub directamente con tu aplicación para recibir datos de los dispositivos conectados y enviarles comandos.

Si tu aplicación no admite MQTT, existen otras opciones. En la arquitectura que se describe en este documento, Apache Beam proporciona un controlador de MQTT, que permite la integración bidireccional con Dataflow y otras implementaciones de Beam. Muchos agentes también tienen capacidades de complementos que admiten la integración con servicios como Google Pub/Sub. Por lo general, se trata de integraciones unidireccionales para la integración de datos, aunque algunos intermediarios admiten la integración bidireccional.

Casos de uso

Una arquitectura de agente de MQTT es particularmente adecuada para los casos de uso de dispositivos que se describen en las siguientes secciones.

Transferencia de datos basada en estándares desde dispositivos heterogéneos

Cuando deseas recopilar y analizar datos de una gran flota de dispositivos heterogéneos, un agente de MQTT suele ser una buena solución. Dado que MQTT es un estándar ampliamente adoptado e implementado, muchos dispositivos perimetrales tienen compatibilidad integrada con él, y hay clientes MQTT livianos disponibles para agregar compatibilidad con MQTT a los dispositivos que no la tienen. El paradigma de publicación y suscripción también forma parte del estándar de MQTT, por lo que los dispositivos habilitados para MQTT pueden aprovechar esta arquitectura sin trabajo de implementación adicional. Por el contrario, los dispositivos que se conectan a Pub/Sub deben implementar la API de Pub/Sub o usar el SDK de Pub/Sub. Ejecutar un agente de MQTT que cumpla con los estándares enGoogle Cloud proporciona una solución simple para recopilar datos de una amplia variedad de dispositivos.

Cuando tus dispositivos conectados no están controlados por tu aplicación, sino por un tercero, es posible que no tengas acceso al software del sistema del dispositivo, y la administración del dispositivo en sí sería responsabilidad de la otra parte. En ese caso, te recomendamos que ejecutes un agente de MQTT y proporciones credenciales de autenticación al tercero para configurar el canal de comunicación del dispositivo a la nube.

Comunicación bidireccional para la integración de aplicaciones de varias partes

La capacidad de mensajería bidireccional de MQTT es que es muy adecuada para un caso de uso de aplicaciones para dispositivos móviles de múltiples partes, como la entrega de comida a pedido o una aplicación de chat web a gran escala. MQTT tiene una sobrecarga de protocolo baja y los clientes de MQTT tienen demandas de recursos bajas. MQTT también incluye el enrutamiento de publicación y suscripción, varios niveles de calidad de servicio (QoS), retención de mensajes integrada y una amplia compatibilidad con protocolos. Un agente de MQTT puede ser el componente principal de una plataforma de mensajería escalable para aplicaciones de servicios a pedido y casos de uso similares.

Mensajería integrada de borde a nube

Debido a la estandarización y la baja sobrecarga que ofrece MQTT, también puede ser una buena solución para integrar aplicaciones de mensajería locales y basadas en la nube. Por ejemplo, un operador de fábrica puede implementar varios intermediarios de MQTT en el entorno local para conectarse a sensores, máquinas, puertas de enlace y otros dispositivos que se encuentran detrás del firewall. El agente de MQTT local puede controlar todos los mensajes bidireccionales de comando y control, y de telemetría para la infraestructura local. El agente local también se puede conectar mediante una suscripción bidireccional a un clúster de agentes de MQTT paralelo en la nube, lo que permite la comunicación entre la nube y el entorno perimetral sin exponer los dispositivos y sistemas locales a Internet pública.

¿Qué sigue?