Arquitetura do agente MQTT independente no Google Cloud

Last reviewed 2024-08-09 UTC

O MQTT é um protocolo padrão OASIS para aplicativos de dispositivos conectados que fornece mensagens bidirecionais usando uma arquitetura de agente de publicação e assinatura. O protocolo MQTT é leve para reduzir a sobrecarga da rede, e os clientes do MQTT são muito pequenos para minimizar o uso de recursos em dispositivos restritos. Uma solução para organizações que querem oferecer suporte a aplicativos de dispositivos conectados no Google Cloud é executar um agente MQTT independente no Compute Engine ou GKE. Para implantar um agente MQTT na sua organização, você precisa tomar várias decisões importantes que afetam a arquitetura geral, principalmente no balanceamento de carga e no ambiente de implantação. Este documento descreve uma arquitetura para implantar um agente MQTT, o aplicativo principal em uma implantação MQTT, no Google Cloud. Também descreve as decisões que você precisa tomar ao implantar este agente e como elas afetam a arquitetura.

Este documento faz parte de uma série de documentos que apresentam informações sobre Arquiteturas de IoT no Google Cloud. Os outros documentos desta série incluem:

No diagrama a seguir, mostramos uma arquitetura de agente MQTT em execução no Google Cloud.

Diagrama da arquitetura do agente MQTT (explicado a seguir).

A arquitetura na imagem anterior é composta da seguinte maneira:

  • O agente MQTT é implantado como um cluster de três instâncias conectadas ao serviço do Cloud Load Balancing. Para o balanceador de carga da nuvem, é possível escolher um dos vários produtos de balanceamento de carga, descritos mais adiante neste documento.
  • O cluster do agente inclui um armazenamento de credenciais e um serviço de autenticação e autorização de dispositivos. O cluster se conecta às cargas de trabalho de back-end pelo Dataflow ou Pub/Sub.
  • No lado do cliente, os gateways de borda fornecem comunicação bidirecional entre dispositivos de borda e o cluster de agente MQTT pelo MQTT via TLS.

Geralmente, recomendamos implantar o aplicativo do agente MQTT para essa arquitetura em um cluster para escalonabilidade. Fatores como a funcionalidade de clustering, o gerenciamento de cluster de escalonamento vertical, a sincronização de dados e o processamento de partição de rede são abordados pelas implementações específicas do agente (como HiveMQ, EMQX, VerneMQ, mosquito e outros).

Considerações e escolhas sobre arquitetura

As seções a seguir descrevem as diferentes escolhas e considerações de arquitetura que você precisa fazer para uma arquitetura de agente MQTT independente e o impacto que essas escolhas têm na arquitetura.

Dispositivos conectados

Dispositivos de borda conectados à Internet publicam os eventos de telemetria e outras informações no agente MQTT. Para implementar a arquitetura de agente MQTT independente descrita neste documento, o dispositivo precisa ter um cliente MQTT, a chave pública do certificado do servidor para autenticação TLS e as credenciais necessárias para autenticar com o agente MQTT.

Além disso, os dispositivos de borda geralmente têm conectores para sensores locais, sistemas de dados no local e outros dispositivos que não têm acesso à Internet ou conectividade IP. Por exemplo, o dispositivo de borda pode servir como um gateway para outros dispositivos restritos locais conectados ao gateway usando BLE, uma conexão com fio ou outro protocolo de campo próximo. Uma especificação detalhada da arquitetura de dispositivos conectados está fora do escopo deste guia.

Balanceamento de carga

Na arquitetura, um serviço de balanceamento de carga externo é configurado entre a rede pública e o cluster de agente MQTT. Esse serviço oferece várias funções de rede importantes, incluindo a distribuição de conexões de entrada em nós de back-end, criptografia de sessão e autenticação.

O Google Cloud é compatível com vários tipos de balanceadores de carga. Para escolher o melhor balanceador de carga para sua arquitetura, considere o seguinte:

  • mTLS. O mTLS processa os métodos de autenticação de dispositivo e de criptografia, enquanto o TLS padrão lida apenas com criptografia e requer um método de autenticação de dispositivo separado:

  • Endpoints HTTP(S) Se você precisar expor endpoints HTTP(S), configure um balanceador de carga de aplicativo externo para esses endpoints.

Para mais informações sobre os tipos de balanceadores de carga compatíveis com o Cloud Load Balancing, consulte Resumo dos balanceadores de carga do Google Cloud.

Estratégia de balanceamento de carga

Qualquer serviço de balanceamento de carga distribui conexões de dispositivos de borda nos nós do cluster de acordo com um dos vários algoritmos ou modos de balanceamento. Para o MQTT, uma estratégia de balanceamento de carga de afinidade da sessão é melhor do que o balanceamento aleatório. Como as conexões cliente-servidor MQTT são sessões bidirecionais permanentes, o estado é mantido no nó do agente que interrompe a conexão. Em uma configuração em cluster, se um cliente se desconecta e se reconecta a um nó diferente, o estado da sessão é movido para o novo nó, o que adiciona carga ao cluster. Esse problema pode ser amplamente evitado usando o balanceamento de carga de afinidade da sessão. Se os clientes mudam os endereços IP com frequência, a conexão pode ser interrompida, mas na maioria dos casos a afinidade da sessão é melhor para o MQTT. A afinidade da sessão está disponível em todos os produtos do Cloud Load Balancing.

Autenticação de dispositivos e gerenciamento de credenciais

Os aplicativos do agente MQTT processam a autenticação de dispositivos e o controle de acesso separadamente do Google Cloud. Um aplicativo do agente também fornece sua própria interface de armazenamento e gerenciamento de credenciais. O protocolo MQTT é compatível com a autenticação básica de nome de usuário e senha no pacote inicial do Connect, e esses campos também são usados com frequência por implementações de agente para aceitar outras formas de autenticação, como certificado X.509 ou autenticação JWT. O MQTT 5.0 também adiciona compatibilidade com métodos de autenticação aprimorados que usam autenticação de desafio e de estilo de resposta. O método de autenticação usado depende da escolha do aplicativo de agente MQTT e do caso de uso do seu dispositivo conectado.

Seja qual for o método de autenticação usado pelo agente, o agente mantém um armazenamento de credenciais do dispositivo. Esse armazenamento pode estar em um banco de dados SQL local ou em um arquivo simples. Alguns agentes, incluindo HiveMQ e VerneMQ, também aceitam o uso de um serviço de banco de dados gerenciado, como o Cloud SQL. Você precisa de um serviço separado para gerenciar o armazenamento de credenciais do dispositivo e processar quaisquer integrações com outros serviços de autenticação, como o IAM. O desenvolvimento deste serviço está fora do escopo deste guia.

Para mais informações sobre autenticação e gerenciamento de credenciais, consulte Práticas recomendadas para executar um back-end de IoT no Google Cloud.

Cargas de trabalho de back-end

Qualquer caso de uso de dispositivos conectados inclui um ou mais aplicativos de back-end que usam os dados ingeridos dos dispositivos conectados. Às vezes, esses aplicativos também precisam enviar comandos e atualizações de configuração aos dispositivos. Na arquitetura do agente MQTT autônomo neste documento, os dados de entrada e os comandos de saída são roteados por meio do agente MQTT. Há diferentes tópicos na hierarquia de tópicos do agente para diferenciar os dados e os comandos.

Os dados e os comandos podem ser enviados entre o agente e os aplicativos de back-end de várias maneiras. Se o próprio aplicativo for compatível com MQTT ou se puder ser modificado para ser compatível, o aplicativo poderá assinar diretamente no agente como um cliente. Essa abordagem permite usar o recurso de mensagens bidirecionais do Pub/Sub do MQTT diretamente com o aplicativo para receber dados e enviar comandos aos dispositivos conectados.

Se o aplicativo não for compatível com MQTT, há várias outras opções. Na arquitetura descrita neste documento, o Apache Beam fornece um driver MQTT, que permite a integração bidirecional com o Dataflow e outras implantações do Beam. Muitos agentes também têm recursos de plug-in compatíveis com a integração com serviços como o Google Pub/Sub. Normalmente, essas são integrações de mão única para integração de dados, embora alguns agentes sejam compatíveis com integração bidirecional.

Casos de uso

Uma arquitetura de agente MQTT é particularmente adequada para os casos de uso de dispositivos descritos nas seções a seguir.

Ingestão de dados com base em padrões de dispositivos heterogêneos

Quando você quer coletar e analisar dados de uma grande frota de dispositivos heterogêneos, um agente MQTT geralmente é uma boa solução. Como o MQTT é um padrão amplamente adotado e implementado, muitos dispositivos de borda têm compatibilidade integrada com ele, e clientes MQTT leves estão disponíveis para adicionar compatibilidade ao MQTT para dispositivos que não são compatíveis. O paradigma de publicação e assinatura também faz parte do padrão MQTT, para que dispositivos habilitados para MQTT possam aproveitar essa arquitetura sem trabalho de implementação adicional. Por outro lado, os dispositivos que se conectam ao Pub/Sub precisam implementar a API Pub/Sub ou usar o SDK do Pub/Sub. Portanto, executar um agente MQTT em conformidade com os padrões no Google Cloud oferece uma solução simples para coletar dados de uma ampla variedade de dispositivos.

Quando os dispositivos conectados não são controlados pelo aplicativo, mas por terceiros, você não tem acesso ao software do sistema, e o gerenciamento do dispositivo é de responsabilidade da outra parte. Nessa circunstância, recomendamos que você execute um agente MQTT e forneça credenciais de autenticação à outra parte para configurar o canal de comunicação do dispositivo para a nuvem.

Comunicação bidirecional para integração de aplicativos de várias partes

O recurso de mensagens bidirecionais do MQTT o torna muito adequado para casos de uso de aplicativo para dispositivos móveis de várias partes, como entrega de comida sob demanda ou um aplicativo de chat da Web em grande escala. O MQTT tem uma baixa sobrecarga de protocolo, e os clientes do MQTT têm baixa demanda de recursos. O MQTT também conta com roteamento de publicação e assinatura, vários níveis de Qualidade de Serviço (QoS), retenção de mensagens integrada e ampla compatibilidade com protocolos. Um agente MQTT pode ser o componente principal de uma plataforma de mensagens escalonável para aplicativos de serviços sob demanda e casos de uso semelhantes.

Mensagens integradas da nuvem para a nuvem

Devido à padronização e à baixa sobrecarga oferecidas pelo MQTT, ele também pode ser uma boa solução para integrar aplicativos de mensagens locais e baseados na nuvem. Por exemplo, um operador de fábrica pode implantar vários agentes MQTT no ambiente local para se conectar a sensores, máquinas, gateways e outros dispositivos que estão protegidos pelo firewall. O agente MQTT local pode processar todas as mensagens de comando bidirecional e controle e telemetria para a infraestrutura local. O agente local também pode ser conectado por assinatura bidirecional a um cluster paralelo de agente MQTT na nuvem, permitindo a comunicação entre a nuvem e o ambiente de borda sem expor os dispositivos e sistemas locais à Internet pública.

A seguir