Abordagens arquitetônicas para soluções multilocatárias baseadas no Hub IoT

As soluções baseadas em Hub 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 no Hub 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. Para saber mais, consulte Abordagens arquitetônicas para governança e conformidade em soluções multilocatárias.

A governança em IoT também pode assumir outras formas, 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 um:

  • Solução de construção inteligente, os termostatos normalmente relatam dados em uma frequência mais baixa do que os elevadores.
  • Numa solução de veículo conectado, as mensagens de dados de gravação da câmara do veículo são normalmente maiores do que as mensagens de telemetria de navegação.

  Se suas mensagens estiverem limitadas em relação à frequência, considere expandir para mais instâncias de um serviço. Se as suas mensagens estiverem limitadas em relação ao tamanho, considere aumentar para instâncias maiores de um serviço.

• 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, vizinhos barulhentos podem 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 aplicativos do Hub IoT ou do IoT Central, todos os clientes na infraestrutura compartilhada recebem 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 razão mais comum para esses erros é quando um limite de cota de mensagens é 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 inquilinos nos planos de controle, gestão e comunicação da IoT, utilizando 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, pode-se gerir outras distribuições de alocação ao nível do balanceador de carga do DPS.

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

As soluções de IoT tendem a ser intensivas em dados, tanto em 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 afeta quais camadas e limites de rede existem; Depois de selecionar o design físico, você pode selecionar a implementação de segurança. Você pode usar as seguintes ferramentas em qualquer abordagem:

• 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 não Microsoft, que deverá ser considerado para isolar as camadas de rede e monitorizar o tráfego de rede. A escolha exata da abordagem determina onde as cargas de trabalho têm isolamento de rede versus uma rede compartilhada, conforme abordado mais adiante neste artigo.

• Azure IoT Edge.

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

As considerações e opções para componentes primários, como gestão, entrada de dados, processamento, armazenamento e segurança, são as mesmas para soluções de IoT de inquilino único e multi-inquilino. A principal diferença é como você organiza e utiliza os componentes para dar suporte à multilocação. Por exemplo, pontos de decisão comuns para:

• O armazenamento pode ser optar por usar o SQL Server ou o Azure Data Explorer.
• A escolha na camada de ingestão e gerenciamento é 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. Os principais requisitos e considerações descritos anteriormente determinam esses fatores.

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 saber mais, consulte Comparar abordagens de solução de Internet das Coisas (IoT) (PaaS vs. aPaaS).

Esta escolha é 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 do 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.
• Limite máximo de nó e profundidade máxima da árvore num padrão multilocatário baseado no IoT Central poderá forçar os provedores de serviços a terem 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.
• do Azure IoT Edge para executar inteligência artificial (IA), serviços que não sejam da Microsoft 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. Portanto, 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 outras ofertas 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.
• No modelo Simple SaaS com aPaaS, é implantada uma instância partilhada para vários clientes e é criada uma organização do IoT Central para cada inquilino.

Como você compartilha uma camada de dados multilocatária nesse modelo, precisa implementar segurança em nível de linha para isolar os dados do cliente. Para saber mais, consulte Abordagens arquitetônicas para armazenamento e dados em soluções multilocatárias.

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 grande número de dispositivos, mensagens ou locatários.

• Serviços e componentes são compartilhados, portanto, uma falha em qualquer componente pode afetar todos os seus locatários. Esse risco é 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 a seguir particiona o IoT Central por cliente final, que serve como o portal de gerenciamento de dispositivos, comunicações de dispositivos e administrações. Esse particionamento geralmente é feito de tal forma que o cliente final que consome a solução tem controle total sobre adicionar, remover e atualizar seus 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:

• Fácil de gerenciar e operar, embora um gerenciamento extra 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 efeito 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:

• Dimensione 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.

A seguir estão os componentes mais comuns que normalmente são 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. Nessa abordagem, você precisa de outro serviço para redirecionar dispositivos para a instância DPS apropriada para o plano de gerenciamento, controle e telemetria desse locatário específico. Para saber mais, consulte o whitepaper Dimensionamento de uma solução do Azure IoT para dar suporte a milhões de dispositivos.

Esta abordagem é frequentemente adotada 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 que identifiquem o locatário de origem. Este enriquecimento permite que o processador de fluxo identifique quais regras de inquilino 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 oferece suporte a um alto grau de escalabilidade 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 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:

• Fácil de gerenciar e operar.
• O isolamento do inquilino é 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.
• Muitas instâncias a serem mantidas se o provedor de soluções for o proprietário da manutenção de cada instância.

Aumentar a escala de SaaS

Quando você expande a escala de uma solução para grandes implantações, 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.