Abordagens de arquitetura para IoT em uma solução de multilocatário

As soluções de IoT multilocatário vêm em vários tipos e tamanhos diferentes. Você pode ter muitos requisitos e restrições, desde a propriedade da infraestrutura até o isolamento de dados do cliente até a conformidade. Pode ser desafiador definir um padrão que atenda a todas essas restrições de design e fazer isso muitas vezes 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 arquiteturas multilocatários de exemplo que aproveitam componentes comuns, de acordo com a Arquitetura de Referência de IoT.

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.

Governança e conformidade

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

A governança em IoT também pode usar formulários adicionais, como a propriedade e o gerenciamento do dispositivo. O cliente possui o dispositivo ou o provedor de solução? Quem é o proprietário do gerenciamento desses dispositivos? Essas considerações e implicações são exclusivas para cada provedor de soluções e podem levar a diferentes opções nos padrões de tecnologia, de implantação e multilocatário que você usa.

Escala

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

• Quantidade de dispositivos: todos os serviços de gerenciamento de dispositivos do Azure – Azure IoT Central, DPS (Serviço de Provisionamento de Dispositivos no Hub IoT) no Hub IoT e Hub IoT do Azure – têm limitações no número de dispositivos com suporte em uma única instância.

  Dica

  Confira 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" nesse contexto refere-se ao número de mensagens durante um período de tempo e ao tamanho das mensagens. Por exemplo, em uma solução de construção inteligente, os termostatos provavelmente relatarão dados em uma frequência menor 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 escalar horizontalmente para mais instâncias de um determinado serviço, mas, se elas forem limitadas em relação ao tamanho, talvez seja necessário escalar verticalmente para instâncias maiores de um determinado serviço.

• Locatários: a escala de um único locatário pode ser pequena, mas, quando multiplicada pelo número de locatários, ela pode crescer rapidamente.

Desempenho e confiabilidade

Isolamento de locatário

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

Em soluções totalmente multilocatários, esses efeitos podem ser 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 Hub IoT e o IoT Central geralmente são os pontos de entrada para dados na nuvem, outros sistemas downstream que dependem desses dados provavelmente também falharão. Geralmente, a ocorrência mais comum para isso acontecer é quando um limite de cota de mensagem é excedido. Nessa situação, a correção mais rápida e mais simples para soluções de Hub IoT é atualizar a SKU Hub IoT, aumentar o número de unidades Hub IoT ou ambas. Para soluções do IoT Central, a solução é dimensionada automaticamente conforme necessário, até o número documentado de mensagens com suporte.

Você pode isolar e distribuir locatários entre os planos de controle, gerenciamento e comunicações de IoT usando as políticas de alocação personalizadas do DPS. Além disso, ao seguir as diretrizes 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 DPS.

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

As soluções de IoT tendem a ser muito intensivas no uso de dados, tanto com relação a streaming quanto dados inativos. Para obter mais informações sobre como gerenciar dados em soluções multilocatários, confira Abordagens de arquitetura para armazenamento e dados em soluções multilocatários.

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 Purdue Enterprise Reference Architecture modificada na nuvem ou soluções da Indústria 4.0. A abordagem de design selecionada entre as abaixo afetará as camadas e limites de rede existentes; Depois que o design físico é selecionado, a implementação de segurança pode ser selecionada. As ferramentas que podem ser usadas em qualquer abordagem incluem:

• Microsoft Defender para 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 Operações do Azure IoT, que você deve considerar como parte da conectividade de dispositivo com serviços hospedados no Azure sem expor diretamente os dispositivos ao acesso direto à Internet. Como as Operações do Azure IoT estão em pré-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ário de forma 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ário discute esse aspecto de uma solução multilocatário geral.

Abordagens a considerar

Todas as considerações que você normalmente faria em uma arquitetura de IoT, para todos os componentes principais (como gerenciamento, ingestão, processamento, armazenamento, segurança e assim por diante), são todas as opções 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 a multilocatário. Por exemplo, os pontos de decisão comuns para armazenamento podem ser decidir se deve ser usado o SQL Server ou o Azure Data Explorer ou, talvez, na camada de ingestão e gerenciamento, se você escolheria entre Hub IoT e o IoT Central.

A maioria das soluções de IoT se ajusta em um padrão de arquitetura raiz, que é uma combinação do destino de implantação, do modelo de locação e do 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 feitos, dentro do espaço de IoT, é selecionar entre uma abordagem de aPaaS (aplicativo-plataforma como serviço) e PaaS (plataforma como serviço). Para mais informações, confira Métodos de comparação de soluções de IoT (Internet das Coisas) (PaaS versus aPaaS).

Esse é o dilema comum "compilar 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 como serviço de integraçã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 do IoT Central, o Azure Data Explorer, Power BI e os Aplicativos Lógicos do Azure.

Essa abordagem geralmente é a maneira mais rápida de obter uma solução para o mercado. É um serviço de alta escala que dá suporte à 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 plano de dados, que combinam documentos declarativos com código imperativo.
• Em um padrão multilocatário, o limite máximo de nó do IoT Central (que se aplica a pais e folhas) e a profundidade máxima da árvore, pode 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 Selo de Implantação.
• O IoT Central impõe limites de chamada à API, o que pode afetar grandes implementações.

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

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

• Hub IoT do Azure como a plataforma de comunicação e configuração do dispositivo principal.
• Serviço de Provisionamento de Dispositivos de Internet das Coisas 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érie temporal de caminhos warm e cold de dispositivos IoT.
• Azure Stream Analytics para analisar dados de caminho crítico de dispositivos IoT.
• Azure IoT Edge para executar IA (inteligência artificial), 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ções. 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 (versus uma abordagem aPaaS). Menos recursos são predefinidos para a conveniência do implementador. Isso significa que essa abordagem também oferece mais controle, pois menos suposições são inseridas 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 tipo de destino, modelo e implantação.
• O destino de implantação, representando a Assinatura do Azure na qual implantar recursos.
• O modelo de locação que está sendo referenciado pelo padrão, conforme descrito em modelos multilocatários
• O padrão de implantação, referindo-se a uma implantação simples com considerações mínimas de implantação, um padrão de nó geográfico ou um padrão de Selo de Implantação.

SaaS simples

A abordagem SaaS simples é a implementação mais simples para uma solução de IoT SaaS. Como mostra o diagrama anterior, toda a infraestrutura é compartilhada e a infraestrutura não tem selo geográfico ou de escala aplicado. Geralmente, 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 separe facilmente os locatários de maneira segura e hierárquica, ao mesmo tempo em que compartilha o design básico do aplicativo em todos os locatários.

A comunicação com sistemas fora do IoT Central, como para análise de dados de longo prazo, em um caminho frio ou conectividade com operações de negócios, é feita 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 e multiplataforma.
• Aplicativos Lógicos do Azure, como uma plataforma como serviço de integraçã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 do IoT Central distinta para cada locatário, enquanto no modelo SaaS Simples com aPaaS, você implanta uma instância compartilhada para vários clientes e cria uma organização do IoT Central para cada locatário.

Como você está compartilhando uma camada de dados multilocatários nesse modelo, será necessário implementar a segurança em nível de linha, conforme descrito em Abordagens de arquitetura para armazenamento e dados em soluções multilocatários, a fim de isolar os dados do cliente.

Benefícios:

• É mais fácil gerenciar e operar em relação às outras abordagens apresentadas aqui.

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. Esse é um risco para a confiabilidade e 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 das 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.

SaaS horizontal

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

Em uma solução de IoT, há muitos componentes que podem ser particionados horizontalmente. Os subsistemas particionados horizontalmente normalmente são organizados usando um padrão de selo de implantação que se integra à 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 dispositivo e administrações. Isso geralmente é feito de forma que o cliente final que consome a solução tenha controle total sobre a adição, remoção e atualização dos próprios dispositivos, sem a intervenção do fornecedor de software. O restante da solução segue um padrão de infraestrutura compartilhada padrão, que resolve para análise de caminho crítico, integrações de negócios, gerenciamento de SaaS e necessidades de análise de dispositivo.

Cada locatário tem sua própria organização do IoT Central, que envia telemetria a um aplicativo de funções compartilhadas e a disponibiliza aos usuários comerciais 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 de dimensionamento flexíveis, pois as camadas são dimensionadas conforme necessário.
• O impacto das falhas de componente é reduzido. Embora uma falha de um componente compartilhado afete todos os clientes, os componentes horizontalmente dimensionados afetam apenas os clientes associados a instâncias de escala específicas.
• Insights de consumo por locatário aprimorados para componentes particionados.
• Os componentes particionados fornecem personalizações por locatário mais fáceis.

Riscos:

• Considere a escala da solução, especialmente para todos os 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 considerações de gerenciamento e DevOps de longo prazo.

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

Bancos de dados

Você pode optar por particionar os bancos de dados. Geralmente, são os repositórios de dados de dispositivo e telemetria que são particionados. Com frequência, vários repositórios de dados são usados para diferentes finalidades específicas, como armazenamento warm versus armazenamento de arquivamento, ou para informações de status de assinatura de locação.

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

• Suporte aos padrões de conformidade. Os dados de cada locatário são isolados entre instâncias do armazenamento de dados.
• Correção de problemas de vizinho barulhento.

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

Aplicativos do IoT Central, Serviço de Provisionamento de Dispositivos no Hub IoT e Hub IoT 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, confira o whitepaper sobre dimensionamento de uma solução de Internet das Coisas do Azure 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 mais diretamente e totalmente isolados.

Se o plano de comunicações 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 aplicar 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 fluxo

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

Automatizado de locatário único

Uma abordagem automatizada de locatário único baseia-se em um processo de decisão e design semelhantes para uma solução corporativa.

Cada locatário tem seu próprio ambiente isolado e idêntico, com uma organização do 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ê tenha mais 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 dá suporte a 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 o desenvolvedor da solução.

Esse padrão também geralmente tem baixa latência, quando comparado a outros padrões, porque você é capaz de implantar os componentes da solução com base na geografia dos 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 dar suporte a uma maior latência ou escala, permitindo a implantação rápida de instâncias extras da solução, para um cliente em geografias 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 SaaS simples com o modelo aPaaS, você 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 locatário é essencialmente garantido.

Riscos:

• A automação inicial pode ser complicada para a nova equipe de desenvolvimento.
• A segurança das credenciais entre clientes para o gerenciamento de implantação de nível superior deve ser imposta ou os compromissos podem se estender entre os clientes.
• Espera-se que os custos sejam mais altos, pois os benefícios de escala de uma infraestrutura compartilhada entre os clientes não estão disponíveis.
• Se o provedor de solução possuir a manutenção de cada instância, talvez você tenha 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 larga escala, confira Dimensionar uma solução de Internet das Coisas do Azure para dar suporte a milhões de dispositivos.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• Michael C. Bazarewsky | Engenheiro Sênior do Cliente do FastTrack para Azure
• David Crook | Engenheiro de cliente principal, FastTrack para Azure

Outros colaboradores:

• John Downs | Engenheiro de software principal
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Próximas etapas

• Examine as diretrizes de multilocatário e do Azure Cosmos DB.
• Saiba mais sobre caminhos de dados frequentes, warm e frios com IoT no Azure.
• Confira as arquiteturas de referência de Internet das Coisas do Azure.
• Examine a documentação sobre como dimensionar soluções de IoT com selos de implantação.