Abordagens arquitetônicas para IoT em uma solução multilocatária

As soluções de IoT multilocatário vêm em muitos sabores e tamanhos diferentes. Você pode ter muitos requisitos e restrições, que vão desde a propriedade da infraestrutura até o isolamento dos dados do cliente e a conformidade. Pode ser desafiador definir um padrão que atenda a todas essas restrições de design, e fazer isso com frequência requer considerar várias dimensões. Este artigo descreve várias abordagens comumente usadas para resolver considerações de multilocação para soluções baseadas em IoT. Este documento inclui exemplos de arquiteturas multilocatárias que aproveitam componentes comuns, de acordo com a Arquitetura de Referência da IoT.

Principais considerações e requisitos

Essas considerações e requisitos são apresentados na ordem em que normalmente são priorizados para o design de uma solução.

Governação e conformidade

Considerações de governança e conformidade podem exigir que você use um determinado padrão ou conjunto de recursos de IoT. Nem todos os serviços de IoT têm as mesmas certificações ou recursos. Se você precisar atender a padrões de conformidade específicos, talvez seja necessário selecionar serviços específicos. As informações sobre governança e conformidade são abordadas em um artigo específico sobre esse tópico.

A governança em IoT também pode assumir formas adicionais, como propriedade e gerenciamento de dispositivos. O cliente é o proprietário do dispositivo ou o fornecedor da solução? Quem é o proprietário da gestão desses dispositivos? Essas considerações e implicações são exclusivas para cada provedor de soluções e podem levar a diferentes escolhas na tecnologia, no padrão de implantação e no padrão de multilocação que você usa.

Escala

É importante planejar a escala da sua solução. A escala é frequentemente considerada nestas três dimensões:

• Quantidade de dispositivos: todos os serviços de gerenciamento de dispositivos do Azure - Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) e Azure IoT Hub - têm limitações no número de dispositivos suportados em uma única instância.

  Gorjeta

  Consulte a documentação de alta escala, se você planeja implantar um número muito grande de dispositivos.

• Taxa de transferência do dispositivo: dispositivos diferentes, mesmo na mesma solução, podem ter requisitos de taxa de transferência diferentes. "Taxa de transferência", neste contexto, refere-se tanto ao número de mensagens ao longo de um período de tempo como ao tamanho das mensagens. Por exemplo, em uma solução de construção inteligente, os termostatos provavelmente relatarão dados em uma frequência mais baixa do que os elevadores, enquanto em uma solução de veículo conectado, as mensagens de dados de gravação da câmera do veículo provavelmente serão maiores do que as mensagens de telemetria de navegação. Se suas mensagens forem limitadas em relação à frequência, talvez seja necessário expandir para mais instâncias de um serviço específico, mas se elas forem limitadas em relação ao tamanho, talvez seja necessário expandir para instâncias maiores de um serviço específico.

• Inquilinos: A escala de um único inquilino pode ser pequena, mas quando multiplicada pelo número de inquilinos, pode crescer rapidamente.

Desempenho e fiabilidade

Isolamento de inquilinos

Soluções totalmente compartilhadas podem ter vizinhos barulhentos. Nos casos do Hub IoT e do IoT Central, isso pode resultar em códigos de resposta HTTP 429 ("Muitas Solicitações"), que são falhas difíceis que podem causar um efeito em cascata. Para obter mais informações, consulte Cotas e limitação.

Em soluções totalmente multilocatário, esses efeitos podem ocorrer em cascata. Quando os clientes compartilham Hubs IoT ou aplicativos do IoT Central, todos os clientes na infraestrutura compartilhada começarão a receber erros. Como o Hub IoT e o IoT Central geralmente são os pontos de entrada de dados para a nuvem, outros sistemas downstream que dependem desses dados provavelmente também falharão. Muitas vezes, a ocorrência mais comum para que isso aconteça é quando um limite de cota de mensagens foi excedido. Nessa situação, a correção mais rápida e simples para as soluções do Hub IoT é atualizar o SKU do Hub IoT, aumentar o número de unidades do Hub IoT ou ambos. Para soluções IoT Central, a solução é dimensionada automaticamente conforme necessário, até o número documentado de mensagens suportadas.

Você pode isolar e distribuir locatários nos planos de controle, gerenciamento e comunicação da IoT usando as políticas de alocação personalizadas do DPS. Além disso, ao seguir as orientações para soluções de IoT de alta escala, você pode gerenciar a distribuição de alocação adicional no nível do balanceador de carga do DPS.

Armazenamento, consulta, uso e retenção de dados

As soluções de IoT tendem a ser muito intensivas em dados, tanto durante o streaming quanto em repouso. Para obter mais informações sobre como gerenciar dados em soluções multilocatário, consulte Abordagens arquitetônicas para armazenamento e dados em soluções multilocatário.

Segurança

As soluções de IoT geralmente têm considerações de segurança em várias camadas, especialmente em soluções que são implantadas em uma arquitetura de referência empresarial Purdue modificada na nuvem ou em soluções da Indústria 4.0. A abordagem de design selecionada entre as abaixo afetará quais camadas e limites de rede existem; Uma vez selecionado o design físico, a implementação de segurança pode ser selecionada. As ferramentas que podem ser usadas em qualquer abordagem incluem:

• Microsoft Defender for IoT, uma solução abrangente de monitoramento de IoT que você deve considerar que oferece uma licença EIoT por dispositivo e licenças de site OT para cada dispositivo e/ou site do cliente. Dependendo da abordagem selecionada posteriormente neste artigo, o cenário de licenciamento de usuário nomeado do Microsoft 365 pode não ser possível. Nesse caso, as opções de licença por dispositivo e site estão disponíveis, que são opções de licença independentes das licenças de locatário do Microsoft 365.

• Firewall do Azure ou um dispositivo de firewall de terceiros, que você deve considerar para isolar as camadas de rede, bem como monitorar o tráfego de rede. A escolha exata da abordagem afetará onde as cargas de trabalho terão isolamento de rede versus uma rede compartilhada, conforme abordado abaixo.

• Azure IoT Edge ou Azure IoT Operations, que você deve considerar como parte da conectividade do dispositivo com serviços hospedados no Azure sem expor diretamente os dispositivos ao acesso direto à Internet. Como o Azure IoT Operations está em visualização no momento, este documento não descreve o uso dessa oferta em geral. Uma futura revisão deste documento abordará esta questão.

A maioria desses tópicos de segurança se aplica em uma solução multilocatária semelhante a uma solução de locatário único, com as variações vinculadas à abordagem selecionada. Um componente que provavelmente será substancialmente diferente em uma solução geral de IoT é a identidade do usuário e do aplicativo. Abordagens arquitetônicas para identidade em soluções multilocatárias discute esse aspeto de uma solução multilocatária geral.

Abordagens a considerar

Todas as considerações que você normalmente faria em uma arquitetura IoT, para todos os componentes principais (como gerenciamento, ingestão, processamento, armazenamento, segurança e assim por diante), são todas as escolhas que você ainda deve fazer ao buscar uma solução multilocatário. A principal diferença é como você organiza e utiliza os componentes para dar suporte à multilocação. Por exemplo, pontos de decisão comuns para armazenamento podem ser decidir se deseja usar o SQL Server ou o Azure Data Explorer, ou talvez na camada de ingestão e gerenciamento, você escolheria entre o Hub IoT e o IoT Central.

A maioria das soluções de IoT se encaixa em um padrão de arquitetura raiz, que é uma combinação do destino de implantação, modelo de locação e padrão de implantação. Esses fatores são determinados pelos principais requisitos e considerações descritos acima.

Um dos maiores pontos de decisão que precisam ser tomados, dentro do espaço IoT, é selecionar entre uma abordagem de plataforma de aplicativo como serviço (aPaaS) e plataforma como serviço (PaaS). Para obter mais informações, consulte Comparar abordagens de solução de Internet das Coisas (IoT) (PaaS vs. aPaaS).

Este é o dilema comum de "construir versus comprar" que muitas organizações enfrentam em muitos projetos. É importante avaliar as vantagens e desvantagens de ambas as opções.

Conceitos e considerações para soluções aPaaS

Uma solução aPaaS típica usando o Azure IoT Central, como o núcleo da solução, pode usar os seguintes serviços de PaaS e aPaaS do Azure:

• Hubs de Eventos do Azure como um mecanismo de fluxo de dados e mensagens de nível empresarial entre plataformas.
• Aplicativos Lógicos do Azure como uma oferta de plataforma de integração como serviço, ou iPaaS.
• Azure Data Explorer como uma plataforma de análise de dados.
• Power BI como uma plataforma de visualização e relatórios.

No diagrama anterior, os locatários compartilham um ambiente IoT Central, Azure Data Explorer, Power BI e Azure Logic Apps.

Esta abordagem é geralmente a maneira mais rápida de colocar uma solução no mercado. É um serviço de alta escala que suporta multilocação usando organizações.

É importante entender que, como o IoT Central é uma oferta de aPaaS, há certas decisões que estão fora do controle de um implementador. Essas decisões incluem:

• O IoT Central usa o Microsoft Entra ID como seu provedor de identidade.
• As implantações do IoT Central são obtidas usando operações de controle e de plano de dados, que combinam documentos declarativos com código imperativo.
• Em um padrão multilocatário, tanto o limite máximo do nó do IoT Central (que se aplica aos pais quanto às folhas) e a profundidade máxima da árvore podem forçar um provedor de serviços a ter várias instâncias do IoT Central. Nesse caso, você deve considerar seguir o padrão Deployment Stamp.
• O IoT Central impõe limites de chamada de API, o que pode afetar grandes implementações.

Conceitos e considerações para soluções PaaS

Uma abordagem baseada em PaaS pode usar os seguintes serviços do Azure:

• Hub IoT do Azure como a principal plataforma de configuração e comunicação do dispositivo.
• Serviço de Provisionamento de Dispositivo IoT do Azure como a implantação do dispositivo e a plataforma de configuração inicial.
• Azure Data Explorer para armazenar e analisar dados de séries cronológicas de caminhos quentes e frios de dispositivos IoT.
• Azure Stream Analytics para analisar dados de caminho ativo de dispositivos IoT.
• Azure IoT Edge para executar inteligência artificial (IA), serviços de terceiros ou sua própria lógica de negócios em dispositivos IoT Edge.

No diagrama anterior, cada locatário se conecta a um aplicativo Web compartilhado, que recebe dados de Hubs IoT e um aplicativo de função. Os dispositivos se conectam ao Serviço de Provisionamento de Dispositivos e aos Hubs IoT.

Essa abordagem requer mais esforço do desenvolvedor para criar, implantar e manter a solução (em comparação com uma abordagem aPaaS). Menos recursos são pré-construídos para a conveniência do implementador. Isso significa que essa abordagem também oferece mais controle, porque menos suposições são incorporadas na plataforma subjacente.

Padrões de arquitetura raiz

A tabela a seguir lista padrões comuns para soluções de IoT multilocatário. Cada padrão inclui as seguintes informações:

• O nome do Padrão, que se baseia na combinação do destino, modelo e tipo de implantação.
• O destino de Implantação, representando a Assinatura do Azure para implantar recursos.
• O modelo de arrendamento sendo referenciado pelo padrão, conforme descrito em Modelos de multilocação
• O padrão de implantação, referindo-se a uma implantação simples com considerações mínimas de implantação, um padrão Geode ou um padrão de carimbo de implantação.

SaaS simples

A abordagem SaaS simples é a implementação mais simples para uma solução SaaS IoT. Como mostra o diagrama anterior, toda a infraestrutura é compartilhada e a infraestrutura não tem carimbo geográfico ou de escala aplicado. Muitas vezes, a infraestrutura reside em uma única assinatura do Azure.

O Azure IoT Central dá suporte ao conceito de organizações. As organizações permitem que um provedor de soluções segregue facilmente locatários de maneira segura e hierárquica, enquanto compartilha o design básico do aplicativo entre todos os locatários.

As comunicações com sistemas fora do IoT Central, como para análise de dados de longo prazo, ao longo de um caminho frio ou conectividade com operações de negócios, são feitas por meio de outras ofertas de PaaS e aPaaS da Microsoft. Essas ofertas adicionais podem incluir os seguintes serviços:

• Hubs de Eventos do Azure como um mecanismo de fluxo de dados e mensagens de nível empresarial entre plataformas.
• Aplicativos Lógicos do Azure como uma plataforma de integração como serviço ou iPaaS.
• Azure Data Explorer como uma plataforma de análise de dados.
• Power BI como uma plataforma de visualização e relatórios.

Se você comparar a abordagem SaaS simples com o modelo aPaaS automatizado de locatário único, muitas características serão semelhantes. A principal diferença entre os dois modelos é que, no modelo automatizado de locatário único, você implanta uma instância distinta do IoT Central para cada locatário, enquanto no modelo Simple SaaS com aPaaS , implanta uma instância compartilhada para vários clientes e cria uma organização do IoT Central para cada locatário.

Ao compartilhar uma camada de dados multilocatária neste modelo, você precisará implementar segurança em nível de linha, conforme descrito em Abordagens arquitetônicas para armazenamento e dados em soluções multilocatário, a fim de isolar os dados do cliente.

Benefícios:

• Mais fácil de gerir e operar em relação às outras abordagens aqui apresentadas.

Riscos:

• Essa abordagem pode não ser facilmente dimensionada para um número muito alto de dispositivos, mensagens ou locatários.

• Como todos os serviços e componentes são compartilhados, uma falha em qualquer componente pode afetar todos os seus locatários. Isso representa um risco para a confiabilidade e a alta disponibilidade da sua solução.

• É importante considerar como você gerencia a conformidade, as operações, o ciclo de vida do locatário e a segurança de subfrotas de dispositivos. Essas considerações tornam-se importantes devido à natureza compartilhada desse tipo de solução nos planos de controle, gerenciamento e comunicações.

Horizontal SaaS

Uma abordagem de escalabilidade comum é particionar horizontalmente a solução. Isso significa que você tem alguns componentes compartilhados e alguns componentes por cliente.

Dentro de uma solução IoT, há muitos componentes que podem ser particionados horizontalmente. Os subsistemas particionados horizontalmente são normalmente organizados usando um padrão de carimbo de implantação que se integra com a solução maior.

Exemplo de SaaS horizontal

O exemplo de arquitetura abaixo particiona o IoT Central por cliente final, que serve como o portal de gerenciamento de dispositivos, comunicações de dispositivos e administrações. Isso geralmente é feito de tal forma que o cliente final que consome a solução tem controle total sobre a adição, remoção e atualização de dispositivos, sem a intervenção do fornecedor do software. O restante da solução segue um padrão de infraestrutura compartilhada padrão, que resolve as necessidades de análise de caminho quente, integrações de negócios, gerenciamento de SaaS e análise de dispositivos.

Cada locatário tem sua própria organização do IoT Central, que envia telemetria para um aplicativo de função compartilhada e o disponibiliza para os usuários corporativos dos locatários por meio de um aplicativo Web.

Benefícios:

• Geralmente fácil de gerenciar e operar, embora o gerenciamento adicional possa ser necessário para componentes de locatário único.
• Opções flexíveis de dimensionamento, porque as camadas são dimensionadas conforme necessário.
• O impacto de falhas de componentes é reduzido. Enquanto uma falha de um componente compartilhado afeta todos os clientes, os componentes dimensionados horizontalmente afetam apenas os clientes associados a instâncias de escala específicas.
• Informações de consumo por locatário aprimoradas para componentes particionados.
• Os componentes particionados fornecem personalizações mais fáceis por locatário.

Riscos:

• Considere a escala da solução, especialmente para quaisquer componentes compartilhados.
• A confiabilidade e a alta disponibilidade são potencialmente afetadas. Uma única falha nos componentes compartilhados pode afetar todos os locatários de uma só vez.
• A personalização do componente particionado por locatário requer DevOps de longo prazo e considerações de gerenciamento.

Abaixo estão os componentes mais comuns que são normalmente adequados para particionamento horizontal.

Bases de Dados

Você pode optar por particionar os bancos de dados. Muitas vezes, são os armazenamentos de dados de telemetria e dispositivo que são particionados. Frequentemente, vários armazenamentos de dados são usados para diferentes finalidades específicas, como armazenamento quente versus arquivamento, ou para informações de status de assinatura de locação.

Separe os bancos de dados para cada locatário, para obter os seguintes benefícios:

• Apoie as normas de conformidade. Os dados de cada locatário são isolados entre instâncias do armazenamento de dados.
• Remediar problemas de vizinhos barulhentos.

Gerenciamento, comunicações e administração de dispositivos

O Serviço de Provisionamento de Dispositivo do Hub IoT do Azure, o Hub IoT e os aplicativos do IoT Central geralmente podem ser implantados como componentes particionados horizontalmente. Se você seguir essa abordagem, precisará ter um serviço adicional para redirecionar dispositivos para o Serviço de Provisionamento de Dispositivos apropriado para o plano de gerenciamento, controle e telemetria desse locatário específico. Para obter mais informações, consulte o whitepaper Dimensionando uma solução do Azure IoT para dar suporte a milhões de dispositivos.

Isso geralmente é feito para permitir que os clientes finais gerenciem e controlem suas próprias frotas de dispositivos que são mais direta e totalmente isolados.

Se o plano de comunicação do dispositivo for particionado horizontalmente, os dados de telemetria deverão ser enriquecidos com dados para o locatário de origem, de modo que o processador de fluxo saiba quais regras de locatário devem ser aplicadas ao fluxo de dados. Por exemplo, se uma mensagem de telemetria gerar uma notificação no processador de fluxo, o processador de fluxo precisará determinar o caminho de notificação adequado para o locatário associado.

Processamento de fluxos

Ao particionar o processamento de fluxo, você habilita personalizações por locatário da análise dentro dos processadores de fluxo.

Automatizado de inquilino único

Uma abordagem automatizada de locatário único é baseada em um processo de decisão e design semelhantes a uma solução corporativa.

Cada locatário tem seu próprio ambiente idêntico e isolado, com uma organização IoT Central e outros componentes dedicados a eles.

Um ponto de decisão crítico nessa abordagem é escolher em qual assinatura do Azure os componentes devem ser implantados. Se os componentes forem implantados em sua assinatura, você terá mais controle e melhor visibilidade sobre o custo da solução, mas isso exigirá que você possua mais das preocupações de segurança e governança da solução. Por outro lado, se a solução for implantada na assinatura do cliente, o cliente será responsável pela segurança e governança da implantação.

Esse padrão suporta um alto grau de escalabilidade. Isso ocorre porque os requisitos de locatário e assinatura geralmente são os fatores limitantes na maioria das soluções. Portanto, isole cada locatário para dar um grande escopo para dimensionar a carga de trabalho de cada locatário, sem esforço substancial de sua parte, como desenvolvedor da solução.

Esse padrão também geralmente tem baixa latência, quando comparado a outros padrões, porque você pode implantar os componentes da solução com base na geografia de seus clientes. A afinidade geográfica permite caminhos de rede mais curtos entre um dispositivo IoT e sua implantação do Azure.

Se necessário, você pode estender a implantação automatizada para oferecer suporte a latência ou escala aprimoradas, permitindo a implantação rápida de instâncias extras da solução, para um cliente em regiões existentes ou novas.

A abordagem automatizada de locatário único é semelhante ao modelo SaaS aPaaS simples. A principal diferença entre os dois modelos é que, na abordagem automatizada de locatário único, você implanta uma instância distinta do IoT Central para cada locatário, enquanto no modelo SaaS simples com aPaaS implanta uma instância compartilhada do IoT Central com várias organizações do IoT Central.

Benefícios:

• Relativamente fácil de gerenciar e operar.
• O isolamento do inquilino é essencialmente garantido.

Riscos:

• A automação inicial pode ser complicada para a nova equipe de desenvolvimento.
• A segurança das credenciais entre clientes para gerenciamento de implantação de nível superior deve ser imposta, ou os comprometimentos podem se estender entre os clientes.
• Espera-se que os custos sejam mais altos, porque os benefícios de escala de uma infraestrutura compartilhada entre os clientes não estão disponíveis.
• Se o provedor de soluções for o proprietário da manutenção de cada instância, você pode ter muitas instâncias para manter.

Aumentar a escala de SaaS

Quando você expande a escala de uma solução para implantações muito grandes, há desafios específicos que surgem com base em limites de serviço, preocupações geográficas e outros fatores. Para obter mais informações sobre arquiteturas de implantação de IoT em grande escala, consulte Dimensionando uma solução do Azure IoT para dar suporte a milhões de dispositivos.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Michael C. Bazarewsky - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
• David Crook - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

• John Downs - Brasil | Engenheiro de Software Principal
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Próximos passos

• Revise as diretrizes para multilocação e o Azure Cosmos DB.
• Saiba mais sobre caminhos de dados quentes, quentes e frios com IoT no Azure.
• Consulte as arquiteturas de referência do Azure IoT.
• Consulte a documentação sobre como dimensionar soluções de IoT com selos de implantação.