Arquitetura de referência do Azure IoT

Armazenamento de Blobs
Funções
IoT Hub
Logic Apps
Stream Analytics

Esta arquitetura de referência mostra uma arquitetura recomendada para aplicações IoT no Azure com componentes PaaS (plataforma como serviço).

Diagrama da arquitetura

As aplicações IoT podem ser descritas como coisas (dispositivos) que enviam dados que geram informações. Estas informações geram ações que visam melhorar uma empresa ou um processo. Um exemplo disto é um motor (a coisa) que envia dados de temperatura. Estes dados são utilizados para avaliar se o motor está a funcionar conforme esperado (as informações). As informações são utilizadas para priorizar pró-ativamente a agenda de manutenção do motor (a ação).

Esta arquitetura de referência utiliza componentes PaaS (plataforma como serviço) do Azure. Outra opção recomendada para a construção de soluções IoT no Azure é:

  • Azure IoT Central. O IoT Central é uma solução SaaS (software como serviço) totalmente gerida. Abstrai as opções técnicas e permite-lhe concentrar-se exclusivamente na sua solução. Esta simplicidade vem com a contrapartida de ser menos personalizável do que uma solução baseada em PaaS.

Num nível alto, existem duas formas de processar dados telemétricos: o caminho frequente e o caminho esporádico. A diferença encontra-se nos requisitos de latência e acesso aos dados.

  • O caminho frequente analisa os dados em tempo quase real, à medida que chegam. No caminho frequente, a telemetria tem de ser processada com latência muito baixa. Normalmente, o caminho frequente é implementado através de um motor de processamento de fluxos. A saída pode acionar um alerta ou ser escrita num formato estruturado que possa ser consultado com ferramentas de análise.
  • O caminho esporádico realiza o processamento em lotes em intervalos mais longos (por hora ou diariamente). Normalmente, o caminho esporádico opera grandes volumes de dados, mas os resultados não têm de ser tão atempados como no caminho frequente. No caminho esporádico, a telemetria não processada é capturada e, em seguida, inserida num processo em lotes.

Arquitetura

Esta arquitetura é composta pelos seguintes componentes. Algumas aplicações podem não requerer todos os componentes listados aqui.

Dispositivos IoT. Os dispositivos podem ser registados com segurança na cloud e ligar-se à cloud para enviar e receber dados. Alguns dispositivos podem ser dispositivos edge que realizam algum processamento de dados no próprio dispositivo ou num gateway de campo. Recomendamos o Azure IoT Edge para processamento edge.

Gateway de cloud. Um gateway de cloud fornece um hub a cloud para os dispositivos se ligarem em segurança à cloud e enviarem dados. Fornece também capacidades de gestão de dispositivos, incluindo o comando e o controlo de dispositivos. Para o gateway de cloud, recomendamos o Hub IoT. O Hub IoT é um serviço cloud alojado que ingere eventos a partir de dispositivos e atua como um mediador de mensagens entre dispositivos e serviços de back-end. O Hub IoT fornece conectividade segura, ingestão de eventos, comunicação bidirecional e gestão de dispositivos.

Aprovisionamento de dispositivos. Para registar e ligar grandes conjuntos de dispositivos, recomendamos que utilize o Serviço de Aprovisionamento de Dispositivos no Hub IoT (DPS). O DPS permite-lhe atribuir e registar dispositivos em pontos finais específicos do Hub IoT do Azure à escala.

Processamento de fluxos. O processamento de fluxos analisa grandes fluxos de registos de dados e avalia as regras para esses fluxos. Para o processamento de fluxos, recomendamos o Azure Stream Analytics. O Stream Analytics pode executar análises complexas à escala através de funções de janela de tempo, agregações de fluxos e associações de origens de dados externas. Outra opção é o Apache Spark no Azure Databricks.

A aprendizagem automática permite que algoritmos preditivos sejam executados sobre dados históricos de telemetria, permitindo cenários como a manutenção preditiva. Relativamente ao machine learning, recomendamos o Azure Machine Learning.

O armazenamento de caminho pouco frequente contém dados que têm de estar disponíveis imediatamente a partir do dispositivo para geração de relatórios e visualização. Para o armazenamento de caminho frequente, recomendamos o Cosmos DB. O Cosmos DB é uma base de dados com múltiplos modelos distribuída globalmente.

O armazenamento de caminho esporádico contém dados que são mantidos a longo prazo e utilizados no processamento em lotes. Para o armazenamento de caminho esporádico, recomendamos o Armazenamento de Blobs do Azure. Os dados podem ser arquivados no armazenamento de Blobs indefinidamente a um custo reduzido e são de acesso fácil para o processamento em lotes.

A transformação de dados manipula ou agrega o fluxo de telemetria. Os exemplos incluem a transformação de protocolos, como a conversão de dados binários em formato JSON, ou a combinação de pontos de dados. Se os dados tiverem de ser transformados antes de chegarem ao Hub IoT, recomendamos que utilize um gateway de protocolo (não mostrado). Caso contrário, os dados podem ser transformados depois de chegarem ao Hub IoT. Nesse caso, recomendamos que utilize as Funções do Azure, que têm a integração incorporada no Hub IoT, Cosmos DB e Armazenamento de Blobs.

A integração de processos de negócio realiza ações com base nas informações dos dados do dispositivo. Pode incluir o armazenamento de mensagens informativas, a geração de alarmes, o envio de e-mails ou mensagens SMS ou a integração no CRM. Recomendamos que utilize o Azure Logic Apps para a integração de processos de negócio.

A gestão de utilizadores restringe os utilizadores ou grupos que podem realizar ações nos dispositivos, como atualizar o firmware. Define também as capacidades dos utilizadores nas aplicações. Recomendamos que utilize o Azure Active Directory para autenticar e autorizar utilizadores.

O Centro de Segurança de Monitorização de Segurança para IoT fornece uma solução de segurança de ponta a ponta para cargas de trabalho IoT e simplifica a sua proteção, proporcionando visibilidade e controlo unificados, prevenção de ameaças adaptativas e deteção e resposta inteligente de ameaças através de cargas de trabalho de dispositivos de folha através da Edge, bem como através das nuvens.

Considerações de escalabilidade

Uma aplicação IoT deve ser criada como serviços discretos que possam ser dimensionados de forma independente. Considere os seguintes pontos de escalabilidade:

IoTHub. Para o Hub IoT, considere os seguintes fatores de dimensionamento:

  • A quota diária máxima de mensagens para o Hub IoT.
  • A quota de dispositivos ligados numa instância do Hub IoT.
  • Débito de ingestão — a rapidez com que o Hub IoT consegue ingerir mensagens.
  • Débito de processamento — a rapidez com que as mensagens a receber são processadas.

Cada hub IoT é aprovisionado com um determinado número de unidades num escalão específico. O escalão e o número de unidades determinam a quota diária máxima de mensagens que os dispositivos podem enviar para o hub. Para obter mais informações, veja as quotas e a limitação do Hub IoT. Pode aumentar verticalmente um hub sem interromper as operações existentes.

Stream Analytics. O dimensionamento das tarefas do Stream Analytics é mais eficiente se as mesmas forem paralelas em todos os pontos no pipeline do Stream Analytics, desde a entrada para consulta até à saída. Uma tarefa totalmente paralela permite ao Stream Analytics dividir o trabalho por vários nós de computação. Caso contrário, o Stream Analytics tem de combinar os dados de fluxo num único local. Para obter mais informações, veja Leverage query parallelization in Azure Stream Analytics (Tirar partido da paralelização de consultas no Azure Stream Analytics).

O Hub IoT cria automaticamente partições das mensagens do dispositivo com base no ID do dispositivo. Todas as mensagens de um dispositivo específico chegarão sempre à mesma partição, mas uma única partição terá mensagens de vários dispositivos. Portanto, a unidade de paralelização é o ID da partição.

Funções. Ao ler a partir do ponto final dos Hubs de Eventos, existe um máximo de instância de função por partição do hub de eventos. A velocidade máxima de processamento é determinada pela rapidez com que uma instância de função consegue processar os eventos de uma única partição. A função deve processar as mensagens em lotes.

Cosmos DB. Para ampliar uma coleção do Cosmos DB, crie a coleção com uma chave de partição e inclua a chave de partição em cada documento que escrever. Para obter mais informações, veja Melhores práticas ao escolher uma chave de partição.

  • Se armazenar e atualizar um único documento por dispositivo, o ID do dispositivo é uma boa chave de partição. As escritas são distribuídas uniformemente pelas chaves. O tamanho de cada partição é estritamente limitado, porque existe um único documento para cada valor de chave.
  • Se armazenar um documento separado para cada mensagem do dispositivo, a utilização do ID do dispositivo como chave de partição excederia rapidamente o limite de 10 GB por partição. Nesse caso, o ID da mensagem é uma chave de partição melhor. Normalmente, ainda incluiria o ID do dispositivo no documento para indexação e consulta.

Azure Time Series Insights (TSI) é um serviço de análise, armazenamento e visualização de dados de séries tempotamos, fornecendo capacidades incluindo filtragem e agregação semelhantes a SQL, aliviando a necessidade de funções definidas pelo utilizador. O Time Series Insights fornece um explorador de dados para visualizar e consultar dados, bem como AS DE CONSULTA REST. Além dos dados das séries de tempo, a TSI também é adequada para soluções que precisam de consultar agregados em grandes conjuntos de dados. Com suporte para armazenamento em várias camadas, APIs ricos, modelo e sua integração com o ecossistema Azure IoT, explorador para visualizações, e extensibilidade através do Power BI, etc. A TSI é a nossa recomendação para armazenamento e análise de dados de séries temporárias.

Considerações de segurança

Comunicação fiável e segura

Todas as informações recebidas de e enviadas para um dispositivo têm de ser fiáveis. A menos que um dispositivo consiga suportar as seguintes capacidades criptográficas, deve estar limitado às redes locais e todas as comunicações entre redes devem passar por um gateway de campo:

  • Encriptação de dados com um algoritmo de encriptação de chave simétrica comprovadamente seguro, publicamente analisado e amplamente implementado.
  • Assinatura digital com um algoritmo de assinatura de chave simétrica comprovadamente seguro, publicamente analisado e amplamente implementado.
  • Suporte para TLS 1.2 para TCP ou outros caminhos de comunicação baseados em fluxos ou para DTLS 1.2 para caminhos de comunicação baseados em datagramas. O suporte do processamento de certificados X.509 é opcional e pode ser substituído pelo modo de chave pré-partilhada mais eficiente em termos de computação e transmissão para TLS, que pode ser implementado com suporte para os algoritmos AES e SHA-2.
  • Arquivo de chaves atualizável e chaves por dispositivo. Cada dispositivo tem de ter material de chave exclusivo ou tokens que o identifiquem no sistema. Os dispositivos devem armazenar a chave em segurança no dispositivo (por exemplo, através de um arquivo de chaves seguro). O dispositivo deve conseguir atualizar as chaves ou os tokens de forma periódica ou reativa em situações de emergência, como em caso de falha do sistema.
  • O firmware e o software da aplicação no dispositivo têm de permitir atualizações para a reparação de vulnerabilidades de segurança detetadas.

No entanto, muitos dispositivos estão demasiado restritos para suportar estes requisitos. Nesse caso, deve utilizar um gateway de campo. Os dispositivos ligam em segurança ao gateway de campo através de uma rede local e o gateway permite a comunicação segura com a cloud.

Protegido com adulterações físicas

É altamente recomendável que o design do dispositivo incorpore funcionalidades que permitam a defesa contra tentativas de manipulação física, para ajudar a garantir a integridade da segurança e a fiabilidade do sistema global.

Por exemplo:

  • Escolha microcontroladores/microprocessadores ou hardware auxiliar que forneça armazenamento seguro e uso de material chave criptográfico, como integração de módulo de plataforma fidedigna (TPM).
  • Proteja o carregador de arranque e o carregamento de software, ancorados no TPM.
  • Utilize sensores para detetar tentativas de intrusão e de manipulação do ambiente do dispositivo com alertas e potencial "autodestruição digital" do dispositivo.

Para ver considerações de segurança adicionais, veja Arquitetura de segurança da Internet das Coisas (IoT).

Monitorização e registos

Os sistemas de registo e monitorização são utilizados para determinar se a solução está a funcionar e ajudar a resolver problemas. Os sistemas de monitorização e registo ajudam a responder às seguintes questões operacionais:

  • Os dispositivos ou sistemas estão numa condição de erro?
  • Os dispositivos ou sistemas estão configurados corretamente?
  • Os dispositivos ou sistemas estão a gerar dados precisos?
  • Os sistemas estão a cumprir as expectativas da empresa e dos clientes finais?

As ferramentas de registo e monitorização são, normalmente, compostas pelos quatro componentes seguintes:

  • Ferramentas de visualização de desempenho e de linha cronológica do sistema para monitorizar o sistema e resolver problemas básicos.
  • Ingestão de dados em memória intermédia, para colocar os dados de registo na memória intermédia.
  • Arquivo de persistência para armazenar dados de registo.
  • Capacidades de pesquisa e consulta, para ver os dados de registo para utilização na resolução de problemas detalhada.

Os sistemas de monitorização fornecem informações sobre o estado de funcionamento, a segurança, a estabilidade e o desempenho de uma solução IoT. Estes sistemas também podem fornecer uma vista mais detalhada, ao registar as alterações à configuração dos componentes e ao fornecer dados de registo extraídos que podem revelar potenciais vulnerabilidades de segurança, melhorar o processo de gestão de incidentes e ajudar o proprietário do sistema a resolver problemas. As soluções de monitorização abrangentes incluem a capacidade de consultar informações de subsistemas específicos ou de agregar em vários subsistemas.

O desenvolvimento do sistema de monitorização deve começar por definir os requisitos de bom estado de funcionamento, conformidade regulamentar e auditoria. As métricas recolhidas podem incluir:

  • Dispositivos físicos, dispositivos edge e componentes de infraestrutura que comunicam alterações à configuração.
  • Aplicações que comunicam alterações à configuração, registos de auditoria de segurança, taxas de pedidos, tempos de resposta, taxas de erros e estatísticas de libertação da memória para as linguagens geridas.
  • Bases de dados, arquivos de persistência e caches que comunicam o desempenho de consulta e escrita, alterações ao esquema, registo de auditoria de segurança, bloqueios ou impasses, desempenho de índice, CPU, memória e utilização do disco.
  • Serviços geridos (IaaS, PaaS, SaaS e FaaS) que comunicam as métricas de estado de funcionamento e as alterações à configuração que afetam o desempenho e o estado de funcionamento dos sistemas dependentes.

A visualização das métricas de monitorização alerta os operadores relativamente a instabilidades do sistema e facilita a resposta aos incidentes.

Telemetria de rastreio

A telemetria de rastreio permite a um operador seguir o percurso de uma parte da telemetria desde a criação até ao sistema. O rastreio é importante para depuração e resolução de problemas. Para soluções IoT que utilizem o Hub IoT do Azure e os SDKs de Dispositivo do Hub IoT, os datagramas de rastreio podem ser originados como mensagens Cloud para Dispositivo e incluídos no fluxo de telemetria.

Registo

Os sistemas de registo são fundamentais para compreender as ações ou atividades realizadas por uma solução e as falhas ocorridas, além de que podem prestar ajuda para corrigir essas falhas. Os registos podem ser analisados para ajudar a compreender e resolver condições de erro, melhorar as características de desempenho e garantir a conformidade com as regras e os regulamentos em vigor.

Embora o registo em texto simples tenha menor impacto nos custos de desenvolvimento iniciais, dificulta as tarefas de analise/leitura por parte do computador. Recomendamos que utilize o registo estruturado, uma vez que as informações recolhidas podem ser analisadas pelo computador e lidas por humanos. O registo estruturado adiciona contexto situacional e metadados às informações de registo. No registo estruturado, as propriedades são elementos cruciais formatados como pares chave-valor, ou com um esquema fixo, para melhorar as capacidades de pesquisa e consulta.

Considerações de DevOps

Utilize a Infraestrutura como código (IAC). O IAC é a gestão de infraestruturas (redes, máquinas virtuais, equilibradores de carga e topologia de ligação) com uma abordagem declarativa. Os modelos devem ser versados e parte do gasoduto de desbloqueio. Os processos de implantação mais fiáveis são automatizados e idempotentes. Uma maneira é criar o modelo Azure Resource Manager para o fornecimento dos recursos IoT e da infraestrutura.

Para automatizar a implementação de infraestruturas, pode utilizar os Serviços Azure DevOps, Jenkins ou outras soluções ci/CD. O Azure Pipelines faz parte do Azure DevOps Services e executa compilações, testes e implementações automatizados.

Considere encenar as suas cargas de trabalho implantando em várias fases e executando validações em cada etapa antes de passar para a próxima; desta forma, pode impulsionar as atualizações para os seus ambientes de produção de forma altamente controlada e minimizar problemas de implantação inesperados. A implantação azul-esverdeado e as versões canárias são estratégias de implantação recomendadas para atualizar ambientes de produção ao vivo. Considere também ter uma boa estratégia de retrocesso para quando uma implementação falhar; por exemplo, pode recolocar automaticamente uma implementação anterior e bem sucedida do seu histórico de implantação, o parâmetro de bandeira de reversão no erro em Azure CLI é um bom exemplo.

Considere monitorizar a sua solução utilizando o Azure Monitor. O Azure Monitor é a principal fonte de monitorização e registo de todos os seus serviços Azure, fornece informações de diagnóstico para recursos Azure. Pode, por exemplo, monitorizar as operações que ocorrem dentro do seu hub IoT. Existem métricas e eventos específicos que o Azure Monitor suporta, bem como serviços, esquemas e categorias para Registos de Diagnóstico Azure.

Para mais informações, consulte a secção DevOps no Microsoft Azure Well-Architected Framework.

Considerações de custos

Em geral, utilize a calculadora de preços Azure para estimar os custos. Outras considerações são descritas na secção Custo no Quadro de Well-Architected microsoft Azure.

Existem formas de otimizar os custos associados aos serviços utilizados nesta arquitetura de referência.

Hub IoT do Azure

Nesta arquitetura, o IoT Hub é o portal de nuvens que ingere eventos a partir de dispositivos. A faturação do IoT Hub varia consoante o tipo de operação. Criar, atualizar, inserir, eliminar são gratuitos. São carregadas operações bem sucedidas, como mensagens de dispositivo para nuvem e nuvem-para-dispositivo.

As mensagens dispositivo-nuvem enviadas com sucesso são carregadas em pedaços de 4-KB em entrada para o IoT Hub. Por exemplo, uma mensagem de 6 KB é carregada como duas mensagens.

O IoT Hub mantém informações estatais sobre cada dispositivo conectado num documento JSON duplo do dispositivo. São carregadas as operações de um documento duplo do dispositivo.

O IoT Hub oferece dois níveis: Básico e Standard.

Considere usar o nível Standard se a sua arquitetura IoT usar capacidades de comunicação bidis. Este nível também oferece uma edição gratuita que é mais adequada para fins de teste.

Se necessitar apenas de comunicação unidirecional dos dispositivos para a nuvem, utilize o nível Básico, que é mais barato.

Para mais informações, consulte o IoT Hub Pricing.

Azure Stream Analytics

O Azure Stream Analytics é utilizado para o processamento de fluxos e avaliação de regras. O Azure Stream Analytics tem o preço do número de Unidades de Streaming (SU) por hora, que entra em computação, memória e produção necessária para o processamento dos dados. Azure Stream Analytics on IoT Edge é faturado por trabalho. A faturação começa quando um trabalho stream Analytics é implementado em dispositivos independentemente do estado do trabalho, funcionando, falhado ou parado.

Para obter mais informações sobre preços, consulte os preços stream Analytics.

Funções do Azure

As Funções Azure são usadas para transformar dados depois de chegar ao Hub IoT. Do ponto de vista dos custos, a recomendação é usar o plano de consumo porque paga apenas pelos recursos computacionares que utiliza. É cobrado com base no consumo de recursos por segundo cada vez que um evento desencadeia a execução da função. Processar vários eventos numa única execução ou lotes pode reduzir o custo.

Azure Logic Apps

Nesta arquitetura, a Logic Apps é usada para integração de processos de negócio.

O preço das aplicações lógicas funciona no modelo pay-as-you-go. Os gatilhos, ações e execuções de conector são medidos cada vez que uma aplicação lógica é executada. Todas as ações bem sucedidas e mal sucedidas, incluindo os gatilhos, são consideradas execuções.

Por exemplo, a sua aplicação lógica processa 1000 mensagens por dia. Um fluxo de trabalho de cinco ações custará menos de $6.

Para obter mais informações, consulte os preços das Aplicações Lógicas.

Armazenamento de Dados

Para o armazenamento de caminhos frios, o Azure Blob Storage é a opção mais rentável.

Para um armazenamento de caminhos quentes, considere usar Azure Cosmos DB. Para mais informações, consulte os preços da Cosmos DB.

Passos seguintes