Arquitetura de agente MQTT autónomo em Google Cloud

Last reviewed 2024-08-09 UTC

O MQTT é um protocolo padrão da OASIS para aplicações de dispositivos ligados que fornece mensagens bidirecionais através de uma arquitetura de agente de publicação e subscrição. O protocolo MQTT é leve para reduzir a sobrecarga da rede e os clientes MQTT são muito pequenos para minimizar a utilização de recursos em dispositivos com restrições. Uma solução para as organizações que querem suportar aplicações de dispositivos ligados noGoogle Cloud é executar um agente MQTT autónomo no Compute Engine ou no GKE. Para implementar um agente MQTT na sua organização, tem de tomar várias decisões importantes que afetam a arquitetura geral, em particular, o equilíbrio de carga e o ambiente de implementação. Este documento descreve uma arquitetura para implementar um agente MQTT, a aplicação principal numa implementação MQTT, no Google Cloud. Também descreve as decisões que tem de tomar quando implementa este agente e como afetam a arquitetura.

Este documento faz parte de uma série de documentos que fornecem informações sobre as arquiteturas de IoT no Google Cloud. Os outros documentos desta série incluem o seguinte:

O diagrama seguinte mostra uma arquitetura de agente MQTT em execução no Google Cloud.

Diagrama da arquitetura do agente MQTT (explicado no texto seguinte).

A arquitetura na imagem anterior é composta da seguinte forma:

  • O agente MQTT é implementado como um cluster de três instâncias que estão ligadas ao serviço Cloud Load Balancing. Para o equilibrador de carga na nuvem, pode escolher um dos vários produtos de equilíbrio de carga, que são descritos mais adiante neste documento.
  • O cluster do agente inclui um arquivo de credenciais do dispositivo e um serviço de autenticação e autorização do dispositivo. O cluster estabelece ligação com as cargas de trabalho de back-end através do Dataflow ou do Pub/Sub.
  • Do lado do cliente, os gateways de limite oferecem comunicação bidirecional entre os dispositivos de limite e o cluster de agente MQTT através de MQTT sobre TLS.

Geralmente, recomendamos que implemente a aplicação de agente MQTT para esta arquitetura num cluster para escalabilidade. Fatores como a funcionalidade de agrupamento, a gestão de clusters de expansão e redução, a sincronização de dados e o processamento de partições de rede são abordados pelas implementações específicas do agente.

Considerações e escolhas arquitetónicas

As secções seguintes descrevem as diferentes escolhas arquitetónicas e considerações que tem de fazer para uma arquitetura de agente MQTT autónoma, e o impacto que estas escolhas têm na arquitetura.

Dispositivos ligados

Os dispositivos periféricos ligados à Internet publicam os respetivos eventos de telemetria e outras informações no agente MQTT. Para implementar a arquitetura de agente MQTT autónomo descrita neste documento, o dispositivo tem de 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 periféricos têm geralmente conetores para sensores locais, para sistemas de dados no local e para outros dispositivos que não têm acesso à Internet nem conetividade IP. Por exemplo, o dispositivo periférico pode servir como uma porta de entrada para outros dispositivos restritos locais ligados à porta de entrada através de BLE, a uma ligação com fios ou a outro protocolo de campo próximo. Uma especificação detalhada da arquitetura do dispositivo ligado está fora do âmbito deste guia.

Balanceamento de carga

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

Google Cloud suporta vários tipos de balanceadores de carga. Para escolher o equilibrador de carga mais adequado para a sua arquitetura, considere o seguinte:

  • mTLS. O mTLS processa os métodos de encriptação e autenticação de dispositivos, enquanto o TLS padrão processa apenas a encriptação e requer um método de autenticação de dispositivos separado:

    • Se a sua aplicação usar mTLS para autenticação de dispositivos e precisar de terminar o túnel TLS, recomendamos que use um Network Load Balancer de encaminhamento externo ou um Network Load Balancer de proxy externo com um proxy TCP de destino. Os equilibradores de carga de rede de proxy externos terminam a sessão TLS e fazem o proxy da ligação ao nó do agente, juntamente com quaisquer credenciais de autenticação contidas na mensagem. Se precisar das informações de ligação do cliente como parte do esquema de autenticação, pode preservá-las na ligação de back-end ativando o protocolo PROXY.
    • Se a sua aplicação não usar mTLS, recomendamos que use um proxy externo Network Load Balancer com um proxy SSL de destino para descarregar o processamento de TLS e SSL externo para o equilibrador de carga. Os equilibradores de carga de rede de proxy externos terminam a sessão TLS e fazem o proxy da ligação ao nó do agente, juntamente com quaisquer credenciais de autenticação contidas na mensagem. Se precisar das informações de ligação do cliente como parte do esquema de autenticação, pode preservá-las na ligação de back-end ativando o protocolo PROXY.

  • Pontos finais HTTP(S). Se precisar de expor pontos finais HTTP(S), recomendamos que configure um balanceador de carga de aplicações externo separado para estes pontos finais.

Para mais informações sobre os tipos de balanceadores de carga suportados pelo Cloud Load Balancing, consulte o Resumo dos Google Cloud balanceadores de carga.

Estratégia de balanceamento de carga

Qualquer serviço de equilíbrio de carga distribui as ligações dos dispositivos periféricos pelos nós no cluster de acordo com um de vários algoritmos ou modos de equilíbrio. Para o MQTT, uma estratégia de equilíbrio de carga de afinidade de sessão é melhor do que o equilíbrio de carga aleatório. Uma vez que as ligações cliente-servidor MQTT são sessões bidirecionais persistentes, o estado é mantido no nó do agente que para a ligação. Numa configuração agrupada, se um cliente se desligar e, em seguida, voltar a ligar-se a um nó diferente, o estado da sessão é movido para o novo nó, o que adiciona carga ao cluster. Este problema pode ser evitado em grande medida através do balanceamento de carga com afinidade de sessão. Se os clientes alterarem frequentemente os respetivos endereços IP, a ligação pode ser interrompida, mas, na maioria dos casos, a afinidade de sessão é melhor para o MQTT. A afinidade de sessão está disponível em todos os produtos do Cloud Load Balancing.

Autenticação de dispositivos e gestão de credenciais

As aplicações de agente MQTT processam a autenticação de dispositivos e o controlo de acesso separadamente de Google Cloud. Uma aplicação de agente também fornece a sua própria loja de credenciais e interface de gestão. O protocolo MQTT suporta a autenticação básica de nome de utilizador e palavra-passe no pacote Connect inicial, e estes campos também são usados frequentemente pelas implementações de agente para suportar outras formas de autenticação, como o certificado X.509 ou a autenticação JWT. O MQTT 5.0 também adiciona suporte para métodos de autenticação melhorados que usam a autenticação no estilo de desafio e resposta. O método de autenticação usado depende da escolha da aplicação de agente MQTT e do exemplo de utilização do seu dispositivo ligado.

Independentemente do método de autenticação usado pelo agente, o agente mantém um arquivo de credenciais do dispositivo. Este armazenamento pode estar numa base de dados SQL local ou num ficheiro simples. Alguns agentes também suportam a utilização de um serviço de base de dados gerido, como o Cloud SQL. Precisa de um serviço separado para gerir o repositório 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 âmbito deste guia.

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

Cargas de trabalho de back-end

Qualquer exemplo de utilização de dispositivos ligados inclui uma ou mais aplicações de back-end que usam os dados carregados a partir dos dispositivos ligados. Por vezes, estas aplicações também têm de enviar comandos e atualizações de configuração para os dispositivos. Na arquitetura de agente MQTT autónomo neste documento, os dados recebidos e os comandos enviados são encaminhados através do agente MQTT. Existem 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 as aplicações de back-end de uma das várias formas. Se a própria aplicação for compatível com MQTT ou puder ser modificada para ser compatível com MQTT, a aplicação pode subscrever diretamente o agente como cliente. Esta abordagem permite-lhe usar a capacidade de mensagens bidirecionais do MQTT Pub/Sub diretamente através da sua aplicação para receber dados e enviar comandos para os dispositivos ligados.

Se a sua aplicação não suportar MQTT, existem várias outras opções. Na arquitetura descrita neste documento, o Apache Beam fornece um controlador MQTT, que permite a integração bidirecional com o Dataflow e outras implementações do Beam. Muitos corretores também têm capacidades de plug-ins que suportam a integração com serviços como o Google Pub/Sub. Normalmente, são integrações unidirecionais para a integração de dados, embora alguns corretores suportem a integração bidirecional.

Exemplos de utilização

Uma arquitetura de agente MQTT é particularmente adequada para os exemplos de utilização de dispositivos descritos nas secções seguintes.

Carregamento de dados baseado em normas a partir de dispositivos heterogéneos

Quando quer recolher e analisar dados de uma grande frota de dispositivos heterogéneos, um agente MQTT é frequentemente uma boa solução. Uma vez que o MQTT é uma norma amplamente adotada e implementada, muitos dispositivos periféricos têm suporte incorporado para o mesmo, e estão disponíveis clientes MQTT leves para adicionar suporte MQTT a dispositivos que não o têm. O paradigma de publicação e subscrição também faz parte da norma MQTT, pelo que os dispositivos compatíveis com MQTT podem tirar partido desta arquitetura sem trabalho de implementação adicional. Por outro lado, os dispositivos que se ligam ao Pub/Sub têm de implementar a API Pub/Sub ou usar o SDK Pub/Sub. A execução de um agente MQTT em conformidade com as normas noGoogle Cloud oferece, assim, uma solução simples para recolher dados de uma vasta gama de dispositivos.

Quando os seus dispositivos ligados não são controlados pela sua aplicação, mas por um terceiro, pode não ter acesso ao software do sistema do dispositivo, e a gestão do próprio dispositivo é da responsabilidade da outra parte. Nessa circunstância, recomendamos que execute um agente MQTT e faculte credenciais de autenticação ao terceiro para configurar o canal de comunicação do dispositivo para a nuvem.

Comunicação bidirecional para integração de aplicações de várias partes

A capacidade de mensagens bidirecionais do MQTT torna-o muito adequado para um exemplo de utilização de uma aplicação para dispositivos móveis com várias partes, como a entrega de comida a pedido ou uma aplicação de chat Web de grande escala. O MQTT tem uma sobrecarga de protocolo baixa e os clientes MQTT têm exigências de recursos baixas. O MQTT também inclui encaminhamento de publicação e subscrição, vários níveis de qualidade de serviço (QoS), retenção de mensagens incorporada e suporte de protocolo amplo. Um agente MQTT pode ser o componente principal de uma plataforma de mensagens escalável para aplicações de serviços a pedido e casos de utilização semelhantes.

Mensagens integradas da periferia para a nuvem

Devido à padronização e à baixa sobrecarga que o MQTT oferece, também pode ser uma boa solução para integrar aplicações de mensagens no local e baseadas na nuvem. Por exemplo, um operador de fábrica pode implementar vários agentes MQTT no ambiente no local para estabelecer ligação a sensores, máquinas, gateways e outros dispositivos que estão atrás da firewall. O agente MQTT local pode processar todas as mensagens de comando e controlo bidirecionais e de telemetria para a infraestrutura no local. O agente local também pode ser ligado por uma subscrição bidirecional a um cluster de agentes MQTT paralelo na nuvem, o que permite a comunicação entre a nuvem e o ambiente periférico sem expor os dispositivos e os sistemas no local à Internet pública.

O que se segue?