Arquitectura del agente de MQTT independiente en Google Cloud

Last reviewed 2024-08-09 UTC

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 red, y los clientes 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 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 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 la 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 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 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 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 de agentes 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 del backend a través de Dataflow o Pub/Sub.
  • En el 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.

Por lo general, te recomendamos que implementes la aplicación de agente de MQTT para esta arquitectura en un clúster para lograr escalabilidad. Las implementaciones específicas del agente (como HiveMQ, EMQX, VerneMQ, mosquito y otras) abordan factores como la funcionalidad de agrupamiento, la administración de clústeres de escalamiento y reducción, la sincronización de datos y el control de particiones de red.

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, 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. Para 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 del servidor para la autenticación de TLS y las credenciales necesarias para autenticarse con el agente de MQTT.

Además, los dispositivos de perímetro suelen tener conectores a sensores locales, a sistemas de datos locales y a otros dispositivos que no tienen acceso a Internet ni conectividad de IP. Por ejemplo, el dispositivo perimetral puede servir como puerta de enlace para otros dispositivos locales con restricciones conectados a la puerta de enlace a través de BLE, una conexión con cable o a 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 agentes de MQTT. Este servicio proporciona varias funciones de red importantes, como la distribución de conexiones entrantes entre 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, 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 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 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 las conexiones de los dispositivos de perímetro 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 de clúster, si un cliente se desconecta y luego se vuelve a conectar a un nodo diferente, el estado de la sesión se traslada al nodo nuevo, lo que agrega carga al clúster. Este problema se puede evitar en gran medida con el uso del 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 de dispositivos y administración de credenciales

Las aplicaciones de agentes de MQTT controlan la autenticación de dispositivos y el control de acceso de forma independiente de Google Cloud. Una aplicación de 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 de conexión inicial, 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 desafío y respuesta. El método de autenticación que se usa depende de la elección de la aplicación del agente de MQTT y del caso de uso del dispositivo conectado.

Independientemente del método de autenticación que use el agente, este mantiene un almacén de credenciales del dispositivo. Esta tienda puede estar en una base de datos SQL local o en un archivo plano. Algunos agentes, como 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.

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

Cualquier caso de uso 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 deben enviar comandos y actualizaciones de configuración a los dispositivos. En la arquitectura del agente de MQTT independiente de este documento, los datos entrantes y los comandos salientes se enrutan a través del agente de MQTT. Hay temas diferentes 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 varias maneras. Si la aplicación admite MQTT o si se puede modificar para admitir MQTT, la aplicación puede suscribirse directamente al agente como cliente. Este enfoque te permite usar la función 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, hay varias otras opciones. En la arquitectura que se describe 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, estas 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 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 hetergéneos, un agente de MQTT suele ser una buena solución. Debido a que MQTT es un estándar ampliamente implementado y adoptado, muchos dispositivos de borde tienen compatibilidad integrada con él, y hay clientes MQTT ligeros 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 MQTT, por lo que los dispositivos compatibles con 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 cumpla con los estándares en Google Cloud proporciona una solución simple para recopilar datos de una amplia variedad de dispositivos.

Cuando tu aplicación no controla los dispositivos conectados, sino 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 esa circunstancia, 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 enrutamiento de publicación y suscripción, varios niveles de calidad de servicio (QoS), retención de mensajes integrada y compatibilidad con protocolos amplios. Un agente de MQTT puede ser el componente principal de una plataforma de mensajería escalable para aplicaciones de servicios on demand 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 agentes 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 de comando y control y telemetría bidireccionales de la infraestructura local. El agente local también se puede conectar mediante una suscripción bidireccional a un clúster de agentes MQTT paralelo en la nube, lo que permite la comunicación entre la nube y el entorno de perímetro sin exponer los dispositivos y sistemas locales a la Internet pública.

¿Qué sigue?