Arquitectura de agente 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 mediante una arquitectura de broker de publicación y suscripción. El protocolo MQTT es ligero para reducir la sobrecarga de la 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 quieran admitir aplicaciones de dispositivos conectados enGoogle Cloud es ejecutar un broker de MQTT independiente en Compute Engine o GKE. Para implementar un broker MQTT en tu organización, debes tomar varias decisiones clave que afecten a la arquitectura general, en concreto, al equilibrio de carga y al entorno de implementación. En este documento se describe una arquitectura para implementar un broker de MQTT, la aplicación principal de una implementación de MQTT, en Google Cloud. También se describen las decisiones que debes tomar al implementar este broker y cómo afectan a la arquitectura.

Este documento forma 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 broker MQTT que se ejecuta enGoogle Cloud.

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

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

  • El broker MQTT se implementa como un clúster de tres instancias conectadas al servicio Cloud Load Balancing. En el caso del balanceador de carga de Cloud, puede elegir uno de los varios productos de balanceo de carga, que se describen más adelante en este documento.
  • El clúster de intermediario incluye un almacén de credenciales de dispositivo 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 pasarelas perimetrales proporcionan comunicación bidireccional entre los dispositivos perimetrales y el clúster de brokers MQTT a través de MQTT sobre TLS.

Por lo general, recomendamos que despliegue la aplicación del broker MQTT para esta arquitectura en un clúster para mejorar la escalabilidad. Las implementaciones específicas de los brokers se encargan de factores como la función de clustering, la gestión de clusters de escalado vertical y horizontal, la sincronización de datos y la gestión de particiones de red.

Consideraciones y opciones de arquitectura

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

Dispositivos conectados

Los dispositivos perimetrales conectados a Internet publican sus eventos de telemetría y otra información en el broker MQTT. Para implementar la arquitectura de broker 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 TLS y las credenciales necesarias para autenticarse con el broker 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 de pasarela para otros dispositivos locales con limitaciones conectados a la pasarela mediante BLE, una conexión por cable u otro protocolo de campo cercano. En esta guía no se incluye una especificación detallada de la arquitectura del dispositivo conectado.

Balanceo de carga

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

Google Cloud admite varios tipos de balanceadores de carga. Para elegir el mejor balanceador de carga para tu arquitectura, ten en cuenta lo siguiente:

  • mTLS mTLS gestiona tanto el cifrado como los métodos de autenticación de dispositivos, mientras que TLS estándar solo gestiona el cifrado y requiere un método de autenticación de dispositivos independiente:

  • Endpoints HTTP(S). Si necesitas exponer endpoints HTTP(S), te recomendamos que configures un balanceador de carga de aplicaciones externo independiente para estos endpoints.

Para obtener más información sobre los tipos de balanceadores de carga que admite Cloud Load Balancing, consulta el resumen de los balanceadores de carga Google Cloud .

Estrategia de balanceo de carga

Cualquier servicio de balanceo de carga distribuye las conexiones de los dispositivos perimetrales entre los nodos del clúster según uno de los varios algoritmos o modos de balanceo. En el caso de MQTT, una estrategia de balanceo de carga con afinidad de sesión es mejor que el balanceo de carga aleatorio. Como las conexiones cliente-servidor MQTT son sesiones bidireccionales persistentes, el estado se mantiene en el nodo del broker que detiene la conexión. En una configuración en clúster, si un cliente se desconecta y, a continuación, se vuelve a conectar a otro nodo, el estado de la sesión se traslada al nuevo nodo, lo que añade carga al clúster. Este problema se puede evitar en gran medida usando el balanceo de carga 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.

Autenticación de dispositivos y gestión de credenciales

Las aplicaciones de broker MQTT gestionan la autenticación de dispositivos y el control de acceso por separado de Google Cloud. Una aplicación de intermediario también proporciona su propio almacén de credenciales y su interfaz de gestión. El protocolo MQTT admite la autenticación básica con nombre de usuario y contraseña en el paquete Connect inicial. Las implementaciones de brokers también suelen usar estos campos para admitir otras formas de autenticación, como la autenticación con certificado X.509 o JWT. MQTT 5.0 también admite métodos de autenticación mejorados que usan la autenticación de tipo reto y respuesta. El método de autenticación que se utiliza depende de la aplicación de broker de MQTT que elijas y del caso de uso de tu dispositivo conectado.

Independientemente del método de autenticación que utilice el broker, este mantiene un almacén de credenciales de dispositivo. Esta tienda puede estar en una base de datos SQL local o en un archivo plano. Algunos brokers también admiten el uso de un servicio de base de datos gestionado, como Cloud SQL. Necesitas un servicio independiente para gestionar el almacén de credenciales del dispositivo y gestionar las integraciones con otros servicios de autenticación, como IAM. El desarrollo de este servicio no se incluye en el ámbito de esta guía.

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

Cargas de trabajo de backend

Cualquier caso práctico de dispositivo conectado incluye una o varias aplicaciones backend que usan los datos ingeridos de los dispositivos conectados. A veces, estas aplicaciones también necesitan enviar comandos y actualizaciones de configuración a los dispositivos. En la arquitectura de agente MQTT independiente que se describe en este documento, tanto los datos entrantes como los comandos salientes se enrutan a través del agente MQTT. Hay diferentes temas en la jerarquía de temas del broker para diferenciar entre los datos y los comandos.

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

Si tu aplicación no admite MQTT, tienes varias 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 brokers también tienen funciones 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 prácticos

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

Ingestión de datos basada en estándares de dispositivos heterogéneos

Si quieres recoger y analizar datos de una gran flota de dispositivos heterogéneos, un broker MQTT suele ser una buena solución. Como MQTT es un estándar ampliamente adoptado e implementado, muchos dispositivos perimetrales tienen compatibilidad integrada con él y hay clientes MQTT ligeros disponibles para añadir 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 habilitados para MQTT pueden aprovechar esta arquitectura sin necesidad de realizar trabajo de implementación adicional. Por el contrario, los dispositivos que se conectan a Pub/Sub deben implementar la API Pub/Sub o usar el SDK Pub/Sub. Por lo tanto, ejecutar un broker de MQTT que cumpla los estándares enGoogle Cloud proporciona una solución sencilla para recoger datos de una amplia gama de dispositivos.

Si tu aplicación no controla tus dispositivos conectados, sino un tercero, es posible que no tengas acceso al software del sistema del dispositivo y que la gestión del dispositivo sea responsabilidad de ese tercero. En ese caso, te recomendamos que ejecutes un broker MQTT y proporciones credenciales de autenticación al tercero para configurar el canal de comunicación entre el dispositivo y la nube.

Comunicación bidireccional para la integración de aplicaciones de terceros

La capacidad de mensajería bidireccional de MQTT lo hace muy adecuado para casos prácticos de aplicaciones móviles multiparticipante, como la entrega de comida a domicilio 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 incluye el enrutamiento de publicación y suscripción, varios niveles de calidad del servicio (QoS), retención de mensajes integrada y una amplia compatibilidad con protocolos. Un broker de MQTT puede ser el componente principal de una plataforma de mensajería escalable para aplicaciones de servicios bajo demanda y casos de uso similares.

Mensajería integrada de extremo a extremo

Gracias a la estandarización y a 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 operario de una fábrica puede implementar varios brokers MQTT en el entorno local para conectarse a sensores, máquinas, pasarelas y otros dispositivos que estén detrás del cortafuegos. El broker MQTT local puede gestionar todos los mensajes de telemetría, control y comandos bidireccionales de la infraestructura local. El broker local también se puede conectar mediante una suscripción bidireccional a un clúster de brokers MQTT paralelo en la nube, lo que permite la comunicación entre la nube y el entorno perimetral sin exponer los dispositivos y sistemas on-premise a la red pública de Internet.

Siguientes pasos