Diagrama de arquitetura IoT: dispositivos, MQTT, processamento de streams e armazenamento

A maioria dos diagramas de IoT tem três caixas: dispositivos, um ícone de nuvem e um painel. As perguntas que importam ficam entre elas. Como o broker sabe qual dispositivo está falando? O que acontece quando um local perde a conexão por uma hora? Quais mensagens podem se perder ou chegar duas vezes? Como um comando chega a um sensor entre milhares?

Um diagrama de arquitetura IoT deve responder a essas perguntas na página. Este artigo monta um para um caso concreto, o monitoramento de temperatura em armazéns refrigerados, e percorre as decisões por trás de cada etapa: o MQTT e seus níveis de qualidade de serviço, o design de tópicos, a identidade dos dispositivos, locais offline e tempo do evento, e onde os dados vão parar.

As camadas de um sistema IoT

Nem todo sistema precisa de todas as camadas. Dispositivos com módulos celulares ou Wi-Fi costumam publicar direto no broker, sem gateway. Desenhe as camadas que você realmente opera.

Por que MQTT

MQTT é um protocolo de publicação/assinatura em que os clientes se conectam a um broker e trocam mensagens por tópico. A especificação MQTT 5.0, padrão OASIS desde março de 2019, o descreve como leve, aberto e simples de implementar. A porta 1883 é registrada na IANA para MQTT sem TLS e a 8883 para MQTT sobre TLS. Tudo o que sai do local deve usar a 8883.

Cada mensagem é publicada com um nível de qualidade de serviço (QoS):

A QoS vale para cada salto, não de ponta a ponta: um assinante recebe uma mensagem com a menor entre a QoS com que ela foi publicada e a QoS concedida à sua assinatura. Com QoS 1, o broker pode entregar duplicatas, então todo consumidor precisa lidar com a mesma leitura duas vezes. Um ID de mensagem gerado pelo dispositivo ou um timestamp por sensor facilita isso.

O MQTT 5 acrescenta alguns recursos que valem um lugar no diagrama:

• Mensagens retidas (retained). O broker guarda a última mensagem de um tópico e a envia a novos assinantes, o que combina com o status atual de um dispositivo.
• Mensagens de testamento (will). O broker publica a mensagem de testamento de um cliente quando a conexão dele cai sem uma desconexão limpa, para que um gateway possa avisar que ficou offline.
• Expiração de mensagens. Se uma mensagem expira antes de a entrega começar, o broker a apaga. Use isso para comandos que só valem por um tempo.
• Assinaturas compartilhadas. Vários consumidores compartilham uma assinatura e cada mensagem vai para só um deles, para que a ponte até a plataforma de streaming possa escalar horizontalmente.

Design de tópicos

Os tópicos são hierárquicos, e os assinantes usam + para um nível e # para o resto. Uma estrutura como site/{site}/device/{id}/telemetry permite assinar um local, um dispositivo ou tudo, e permite que o broker restrinja cada dispositivo aos próprios tópicos. Tópicos que começam com $ são reservados ao broker, e filtros que começam com um curinga não os alcançam.

Use os tópicos para roteamento e permissões. Coloque a versão do esquema e o horário da medição no payload, onde eles podem mudar sem quebrar todas as assinaturas.

Identidade dos dispositivos

Dê a cada dispositivo ou gateway o próprio certificado X.509, assinado pela sua CA de dispositivos, e faça o broker exigir certificados de cliente. O subject do certificado vira o ID do cliente, e o broker concede tópicos com base nele. Assim, um dispositivo roubado pode ser revogado sozinho, e nenhuma senha compartilhada fica no firmware de milhares de unidades. Decida como os certificados são emitidos, na fabricação ou no primeiro boot, e como são renovados antes de expirar, e desenhe a CA no diagrama.

Locais offline e tempo do evento

Locais perdem a conexão. Um gateway que guarda leituras em buffer localmente envia uma hora de dados de uma vez quando o link volta, então os dados chegam atrasados e fora de ordem. Marque cada leitura com o horário em que foi medida, mantenha os relógios dos gateways sincronizados e processe no tempo do evento com uma tolerância para atrasos. Um alerta como "freezer acima de -18 °C por dez minutos" precisa ser calculado pelo momento em que as leituras foram feitas, não pelo momento em que chegaram. O mesmo raciocínio vale para qualquer arquitetura orientada a eventos.

O exemplo: monitoramento de armazéns refrigerados

Cada armazém tem cerca de quarenta sensores de freezer que reportam a cada 30 segundos e uma dúzia de sensores de porta que reportam quando algo muda. Um gateway do local coleta as leituras pelo rádio local, guarda em buffer quando está offline e as publica no broker MQTT com QoS 1 sobre TLS mútuo. O broker valida cada certificado de cliente contra a CA de dispositivos. Uma ponte com uma assinatura compartilhada copia a telemetria para o Kafka. Um consumidor arquiva as mensagens brutas em armazenamento de objetos; um processador de streams calcula agregados de um minuto no tempo do evento, grava-os em um banco de séries temporais para os painéis e dispara alertas de temperatura. A gestão de dispositivos envia comandos e configuração de volta pelo broker.

Como ler:

• À esquerda, o local. Os sensores falam só com o gateway do local; o gateway é o único cliente que o broker vê desse local.
• No meio, o broker. A telemetria sobe com QoS 1. As conexões tracejadas são os comandos que descem para o local e a verificação de certificados contra a CA de dispositivos.
• À direita, o caminho dos dados. O Kafka alimenta o arquivo bruto e o processador de streams, que grava agregados no banco de séries temporais e dispara alertas.
• O bloco Markdown traz a estrutura de tópicos, a QoS por tópico e a regra de identidade.

O que rotular

• O protocolo, a porta e a QoS no link do local até o broker.
• A taxa de mensagens por classe de dispositivo. Quarenta sensores a cada 30 segundos são 80 mensagens por minuto por local; multiplique pelo número de locais antes de dimensionar o broker.
• A identidade: qual certificado, qual CA e como os certificados são renovados e revogados.
• O buffer: por quanto tempo o gateway consegue guardar dados offline.
• A retenção de cada armazenamento, de horas no stream a anos no arquivo.
• O caminho dos comandos, incluindo a expiração de mensagens e o que um dispositivo faz com um comando desconhecido.

Erros comuns

• Credenciais compartilhadas entre dispositivos. Uma única senha vazada abre todos os dispositivos. Use um certificado por dispositivo.
• A porta 1883 na internet. Sem TLS, leituras e credenciais trafegam em texto puro.
• Supor entrega exatamente uma vez. A QoS 1 pode entregar duplicatas; torne os consumidores idempotentes em vez de recorrer à QoS 2 em todo lugar.
• Processar pelo horário de chegada. Dados em buffer passam a disparar alertas falsos ou a esconder os verdadeiros.
• Dispositivos gravando direto no banco de dados. Você perde a autenticação, o buffer e a distribuição do broker.
• Nenhum caminho de atualização. Atualizações de firmware e mudanças de configuração fazem parte da arquitetura; desenhe-as.
• Permissões com curingas para dispositivos. Um dispositivo que pode assinar # consegue ler os dados de todos os outros.

O diagrama de topologia de rede cobre a rede do próprio local, que um diagrama de IoT costuma deixar de fora.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Moldura do pack Básico para o local. Dentro dela, do pack Rede, adicione um Dispositivo para cada grupo de sensores com o tipo IoT / casa inteligente, e outro Dispositivo com o tipo Modem / gateway para o gateway do local.
3. Do pack Modelo C4, adicione nós Contêiner para o broker MQTT, a gestão de dispositivos e o processador de streams, e um Banco de dados para o banco de séries temporais.
4. Do pack Segurança, adicione um Certificado para a CA de dispositivos.
5. Do pack Dados, adicione Kafka e um Repositório de objetos para o arquivo bruto. Do pack DevOps, adicione Métricas para os painéis e um nó Alerta.
6. Conecte-os da esquerda para a direita, rotule o uplink com sua QoS, deixe tracejados os comandos e a verificação de certificados e adicione um bloco Markdown do pack Básico com o design de tópicos.

O exemplo usa 14 nós de diagrama e fica dentro do plano Free. A página de diagramas de rede mostra o restante do pack Rede.

Perguntas frequentes

Dispositivos IoT devem usar MQTT ou HTTP? O MQTT mantém uma conexão aberta, então a nuvem pode enviar comandos, e o overhead por mensagem é pequeno. O HTTP é mais simples para dispositivos que reportam raramente e nunca recebem comandos.

Qual nível de QoS devo usar? QoS 1 para a maior parte da telemetria e dos comandos, com consumidores que toleram duplicatas. QoS 0 para leituras de alta frequência que você pode se dar ao luxo de perder. QoS 2 só onde duplicatas não podem ser tratadas mais adiante.

Preciso de Kafka se já tenho um broker MQTT? Nem sempre. O broker roteia mensagens para assinantes conectados; ele não é um log de longo prazo que você pode reprocessar. Adicione uma plataforma de streaming quando vários consumidores precisarem dos mesmos dados ou quando você precisar reprocessar o histórico.

Como os dispositivos recebem seus certificados? Na fabricação ou no primeiro boot, por meio de um serviço de provisionamento, cada um com o próprio par de chaves. Guarde a chave privada em hardware seguro quando o dispositivo tiver um.

As regras devem rodar na borda ou na nuvem? Regras que precisam funcionar durante uma queda, como um alarme local para uma porta deixada aberta, rodam no gateway. Regras que precisam de dados de muitos locais rodam na nuvem.

Comece grátis — um assento, sem cartão de crédito.