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 mediante una arquitectura de agente de publicación y suscripción. El protocolo MQTT es ligero para reducir la sobrecarga de red y los clientes MQTT son muy pequeños a fin de minimizar el uso de recursos en dispositivos restringidos. Una solución para las organizaciones que desean admitir aplicaciones de dispositivos conectados en Google 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 afecten 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 y la migración desde IoT Core. Los otros documentos de esta serie incluyen lo siguiente:

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

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

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

  • El agente de MQTT se implementa como un clúster de tres instancias que están conectadas al servicio de Cloud Load Balancing. Para el balanceador de cargas en la nube, puedes elegir entre uno de los varios productos de balanceo de cargas, que se describen más adelante en este documento.
  • El clúster del agente 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.
  • En el lado del cliente, las puertas de enlace perimetral proporcionan comunicación bidireccional entre los dispositivos perimetrales y el clúster del agente de MQTT a través de MQTT mediante TLS.

En general, te recomendamos que implementes la aplicación del agente de MQTT para esta arquitectura en un clúster a fin de obtener escalabilidad. 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 manejo de particiones de red se abordan mediante las implementaciones específicas del agente (como HiveMQ, EMQX, VerneMQ), mosquito, and others).

Consideraciones y elecciones de arquitectura

En las siguientes secciones, se describen las diferentes opciones de arquitectura y consideraciones que debes tener en cuenta para una arquitectura de agente de MQTT independiente y 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. A fin de implementar la arquitectura del agente de MQTT independiente que se describe en este documento, el dispositivo debe tener un cliente MQTT, la clave pública del certificado de 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, sistemas de datos locales y otros dispositivos que no tienen acceso a Internet o conectividad IP. Por ejemplo, el dispositivo perimetral puede funcionar como una puerta de enlace para otros dispositivos con restricciones locales conectados a la puerta de enlace mediante BLE, a una conexión con cable o a otro protocolo de campo cercano. Una especificación detallada de la arquitectura de 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 del agente de MQTT. Este servicio proporciona varias funciones importantes de herramientas de redes, incluida la distribución de las conexiones entrantes entre nodos de backend, encriptación de sesiones y autenticación.

Google Cloud admite varios tipos de balanceadores de cargas. A fin de elegir el mejor balanceador de cargas para tu arquitectura, ten en cuenta 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 los extremos HTTP(S), te recomendamos que configures un balanceador de cargas de aplicaciones externo para estos extremos.

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

Estrategia de balanceo de cargas

Cualquier servicio de balanceo de cargas distribuye conexiones desde dispositivos perimetrales en los nodos del clúster de acuerdo con uno de varios algoritmos o modos de balanceo. Para MQTT, una estrategia de balanceo de cargas de afinidad de sesión es mejor que el balanceo 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 agrupada en clústeres, 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 mediante el balanceo de cargas de afinidad de sesión. Si los clientes cambian sus direcciones IP con frecuencia, 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.

Autenticación del dispositivo y administración de credenciales

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

Sin importar el método de autenticación que use el agente, el agente mantiene un almacén de credenciales de dispositivos. Este almacén puede estar en una base de datos SQL local o en un archivo plano. Algunos agentes, incluidos HiveMQ y VerneMQ, 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 cualquier integración con otros servicios de autenticación, como IAM. El desarrollo de este servicio está fuera del alcance de esta guía.

Si quieres 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 del backend

Cualquier caso práctico de dispositivo conectado incluye una o más aplicaciones de backend que usan los datos transferidos desde los dispositivos conectados. A veces, estas aplicaciones también necesitan enviar comandos y actualizaciones de configuración a los dispositivos. En la arquitectura independiente del agente de MQTT 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 entre los datos y los comandos.

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

Si tu aplicación no es compatible con MQTT, hay otras opciones. En la arquitectura descrita en este documento, Apache Beam proporciona un controlador 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, son integraciones unidireccionales para la integración de datos, aunque algunos agentes admiten la integración bidireccional.

Casos de uso

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

Transferencia de datos basada en estándares de 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. Debido a que MQTT es un estándar implementado y adoptado de forma amplia, muchos dispositivos perimetrales tienen compatibilidad integrada y los clientes MQTT ligeros están disponibles para agregar compatibilidad con MQTT a dispositivos que no lo tienen. El paradigma de publicación y suscripción también forma parte del estándar 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. Por lo tanto, ejecutar un agente de MQTT que cumple con los estándares en Google Cloud proporciona una solución simple para recopilar datos de una amplia variedad de dispositivos.

Cuando la aplicación no controla tus dispositivos conectados, sino que lo hace un tercero, es posible que no tengas acceso al software del sistema del dispositivo y la administración del dispositivo 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 de dispositivo a 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 pocas demandas de recursos. MQTT también cuenta con enrutamiento de publicación y suscripción, 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 central de una plataforma de mensajería escalable para aplicaciones de servicios a pedido y casos de uso similares.

Mensajería integrada de perímetro 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 agentes de MQTT en el entorno local para conectarse a sensores, máquinas, puertas de enlace y otros dispositivos que están detrás del firewall. El agente de MQTT local puede controlar todos los comandos bidireccionales y el control y la mensajería 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 agente 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 la Internet pública.

¿Qué sigue?