Expandir uma solução Azure IoT Hub para suportar milhões de dispositivos

Este artigo descreve como escalar uma solução de Internet das Coisas (IoT) utilizando um padrão de escalonamento na plataforma Azure IoT Hub. O padrão de expansão aborda os desafios de dimensionamento adicionando instâncias a uma implantação em vez de aumentar o tamanho da instância. Esta orientação de implementação mostra-lhe como escalar uma solução IoT que suporta milhões de dispositivos e considera os limites de serviços e subscrições do Azure. O artigo descreve modelos de implantação de intervenção mínima e sem intervenção do modelo de ampliação que podem ser adotados dependendo de suas necessidades.

Para obter mais informações, consulte os seguintes artigos:

Nota

Este documento não cobre a plataforma Azure IoT Operations, que escala com base na configuração da plataforma Kubernetes de alojamento.

Verificar os requisitos

Reúna os requisitos antes de implementar uma nova solução de IoT. Esta etapa ajuda a garantir que a implementação atenda aos seus objetivos de negócios. Seus objetivos de negócios e ambiente operacional devem orientar suas necessidades. No mínimo, reúna os seguintes requisitos:

Identifique os tipos de dispositivos que você deseja implantar. A IoT engloba uma ampla gama de soluções, desde unidades simples de microcontroladores (MCUs) até unidades de sistema em chip (SoC) e unidades de microprocessador (MPUs) de nível médio, até projetos completos de nível de PC. Os recursos de software do lado do dispositivo influenciam diretamente o design da solução.

Determine o número de dispositivos que você precisa implantar. Alguns princípios básicos de implementação de soluções de IoT aplicam-se em todas as escalas. Entenda a escala para ajudar a evitar a engenharia excessiva de uma solução. Uma solução para 1.000 dispositivos tem diferenças fundamentais em comparação com uma solução para 1 milhão de dispositivos. Uma solução de prova de conceito (PoC) para 10.000 dispositivos pode não ser dimensionada adequadamente para 10 milhões de dispositivos se você não considerar a escala de destino no início do projeto da solução.

Identifique quantos dispositivos precisa de implementar para que possa escolher o serviço Azure IoT certo. A escalabilidade do IoT Hub e do IoT Hub DPS é diferente. Por concepção, uma única instância DPS pode encaminhar para múltiplas instâncias do IoT Hub. Portanto, considere a escala de cada serviço individualmente em relação ao número de dispositivos. Mas os limites não existem isoladamente. Se um serviço apresenta uma preocupação com limites, outros serviços provavelmente também o fazem. Trate os limites de serviço como quotas distintas, mas relacionadas.

Documente os locais previstos dos dispositivos. Inclua localização física, disponibilidade de energia e conectividade com a Internet. Uma solução que você implanta em uma única geografia, como apenas na América do Norte, é projetada de forma diferente em comparação com uma solução global. Da mesma forma, uma solução de IoT industrial implantada em fábricas que têm energia em tempo integral difere de uma solução de gestão de frotas implantada em veículos motorizados que têm potência e localização variáveis. O protocolo de comunicação e a largura de banda disponível, seja para um gateway ou diretamente para um serviço de nuvem, afetam a escalabilidade do projeto em cada camada. Considere também a disponibilidade de conectividade. Determine se os dispositivos permanecem ligados ao Azure ou funcionam em modo desligado durante longos períodos.

Investigue os requisitos de localidade de dados. Requisitos legais, de conformidade ou do cliente podem restringir onde você pode armazenar dados (como telemetria) ou metadados (como informações do dispositivo) para a solução. Estas restrições influenciam significativamente a conceção geográfica da solução.

Determinar os requisitos de intercâmbio de dados. Uma solução que envia telemetria básica, como a temperatura atual, uma vez por hora, difere de uma solução que carrega arquivos de amostra de 1 MB uma vez a cada 10 minutos. Uma solução unidirecional de dispositivo para nuvem (D2C) difere de uma solução bidirecional D2C e nuvem para dispositivo (C2D). Além disso, as limitações de escalabilidade do produto tratam o tamanho e a quantidade de mensagens como dimensões diferentes.

Documente os requisitos esperados de alta disponibilidade e recuperação de desastres. Como qualquer solução de produção, os projetos completos de soluções IoT incluem requisitos de disponibilidade ou tempo de atividade. O projeto precisa cobrir cenários de manutenção planejada e tempo de inatividade não planejado, incluindo erros do usuário, fatores ambientais e bugs de solução. O design também precisa ter um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) documentados se ocorrer um desastre, como uma perda permanente de região ou agentes mal-intencionados. Este artigo se concentra na escala do dispositivo, portanto, inclui apenas informações limitadas sobre alta disponibilidade e preocupações com recuperação de desastres.

Decida sobre um modelo de alojamento de clientes, se apropriado. Em uma solução de empresa de desenvolvimento de software multilocatário, onde o desenvolvedor de soluções cria uma solução para clientes externos, o design deve definir como segregar e gerenciar os dados do cliente. Para obter mais informações, consulte Modelos de locação e as diretrizes específicas de IoT relacionadas.

Compreender os conceitos do Azure IoT

Ao criar uma solução, escolha os componentes Azure IoT apropriados e outros serviços Azure de suporte. A arquitetura da sua solução requer um esforço significativo. Utilizar corretamente os serviços IoT Hub e IoT Hub DPS pode ajudá-lo a escalar as suas soluções para milhões de dispositivos.

Hub IoT

IoT Hub é um serviço gerido alojado na cloud que atua como um centro central de mensagens para a comunicação entre uma aplicação IoT e os seus dispositivos ligados. Pode usar o IoT Hub sozinho ou com o IoT Hub DPS.

O IoT Hub escala com base na funcionalidade desejada e no número de mensagens ou volume de dados por dia. Use as três entradas a seguir para determinar como dimensionar uma instância:

As camadas gratuita, básica e padrão determinam os recursos disponíveis. Uma instância de produção não usa o nível gratuito porque este é limitado na escala e destina-se apenas a cenários de desenvolvimento inicial. A maioria das soluções utiliza o nível padrão para obter todas as capacidades do IoT Hub.
O size determina a unidade base para o débito de mensagens e dados de mensagens do tipo D2C no IoT Hub. O tamanho máximo para uma instância de IoT Hub é o tamanho 3, que suporta 300 milhões de mensagens por dia e 1.114,4 GB de dados por dia, por unidade.
A contagem de unidades determina o multiplicador para a escala de tamanho. Por exemplo, três unidades suportam três vezes a escala de uma unidade. O limite de instâncias de hub de tamanho 1 ou 2 é de 200 unidades e o limite de instâncias de hub de tamanho 3 é de 10 unidades.

Para além dos limites diários baseados no tamanho e número de unidades e dos limites gerais de funcionalidade baseados no nível, o IoT Hub aplica limites por segundo no rendimento. Cada IoT Hub instância também suporta até 1 milhão de dispositivos como um limite rígido. Seus requisitos de troca de dados ajudam a definir a configuração apropriada. Para obter mais informações, consulte Outros limites.

Os requisitos da sua solução determinam o tamanho e o número necessários de instâncias do IoT Hub como ponto de partida. Se usar o IoT Hub DPS, o Azure ajuda-o a distribuir as suas cargas de trabalho por várias instâncias do IoT Hub.

IoT Hub DPS

O IoT Hub DPS é um serviço auxiliar para o IoT Hub que permite o provisionamento zero-touch e just-in-time para o IoT Hub certo, sem necessidade de intervenção humana. Cada subscrição Azure suporta um máximo de 10 instâncias DPS. Cada instância de serviço suporta um máximo de 1 milhão de registros. Aborde os limites de serviço em seu limite de design de carga de trabalho para evitar problemas no futuro.

As instâncias do DPS residem em regiões geográficas específicas, mas têm um ponto de extremidade público global por padrão. Instâncias específicas são acessadas através de um escopo de ID. Como as instâncias estão em regiões específicas e cada instância tem seu próprio escopo de ID, você deve ser capaz de configurar o escopo de ID para seus dispositivos.

Compreender os conceitos de resiliência partilhada

Você deve considerar conceitos de resiliência compartilhada, como tratamento de falhas transitórias, impacto na localização do dispositivo e, para empresas de software, resiliência de dados SaaS (software como serviço).

Compreender o tratamento de falhas transitórias. Qualquer solução distribuída de produção, seja no local ou na nuvem, deve ser capaz de se recuperar de falhas transitórias ou temporárias. Falhas transitórias podem ocorrer com mais frequência em uma solução de nuvem devido aos seguintes fatores:

Dependência de um fornecedor externo
Confiança na conectividade de rede entre o dispositivo e os serviços na nuvem
Limites de implementação de serviços em nuvem

O tratamento de falhas transitórias requer que você tenha um recurso de repetição incorporado ao código do dispositivo. Existem várias estratégias de repetição, incluindo backoff exponencial com randomização, também conhecido como backoff exponencial com jitter. Para obter mais informações, consulte Tratamento de falhas transitórias.

Diferentes fatores podem afetar a conectividade de rede de um dispositivo:

A fonte de alimentação de um dispositivo: Dispositivos alimentados por bateria ou dispositivos alimentados por fontes transitórias, como solar ou eólica, podem ter menos conectividade de rede do que dispositivos alimentados por linha em tempo integral.
O local de implantação de um dispositivo: Dispositivos em configurações urbanas de fábrica provavelmente têm melhor conectividade de rede do que dispositivos em ambientes de campo isolados.
A estabilidade de localização de um dispositivo: Os dispositivos móveis provavelmente têm menos conectividade de rede do que os dispositivos de localização fixa.

Essas preocupações também afetam o tempo de disponibilidade e conectividade do dispositivo. Por exemplo, dispositivos alimentados por linha em ambientes urbanos densos, como alto-falantes inteligentes, podem se desconectar e reconectar em grandes grupos. Considere os seguintes cenários:

Um apagão pode fazer com que 1 milhão de dispositivos fiquem offline ao mesmo tempo e voltem a ficar online simultaneamente por causa da perda e reconexão da rede elétrica. Esse cenário se aplica tanto em cenários de consumo, como alto-falantes inteligentes, quanto em cenários de IoT empresariais e industriais, como termostatos conectados alimentados por linha que relatam a uma empresa de gestão imobiliária.
Durante um evento de onboarding de curto prazo e em grande escala, como a Black Friday ou o Natal, muitos consumidores ligam os dispositivos pela primeira vez em um período de tempo relativamente curto.
Muitos dispositivos recebem atualizações agendadas em uma janela de tempo curta, e todos eles são reinicializados com a nova atualização aproximadamente ao mesmo tempo.

Esses muitos dispositivos inicializando ao mesmo tempo podem desencadear a limitação do serviço de nuvem, mesmo com conectividade de rede quase constante.

Para além dos problemas de rede e quotas, deve também considerar falhas de serviço no Azure. Essas interrupções podem afetar serviços individuais ou regiões inteiras. Alguns serviços, como o IoT Hub, suportam a geo-redundância. Outros serviços, como o IoT Hub DPS, armazenam os seus dados numa única região. Você pode vincular um hub IoT a várias instâncias DPS, o que ajuda a mitigar os riscos regionais.

Se a redundância regional for uma preocupação, use o padrão Geode. Esse padrão hospeda recursos independentes e agrupados em diferentes geografias. Da mesma forma, um carimbo de implantação, também conhecido como carimbo de escala, aplica este padrão para gerir múltiplas cargas de trabalho ou inquilinos. Para obter mais informações, consulte o padrão Deployment Stamps.

Compreenda o impacto na localização do dispositivo. A maioria dos serviços Azure são regional, até o DPS com endpoints globais. Exceções incluem o Azure Traffic Manager e o Microsoft Entra ID. As suas decisões sobre a localização do dispositivo, localização dos dados e localização dos metadados (como grupos de recursos do Azure) desempenham um papel fundamental no seu design.

Localização do dispositivo: Os requisitos de localização do dispositivo afetam sua seleção regional porque afetam a latência transacional.
Localização dos dados: A localização dos dados está ligada à localização do dispositivo, que está sujeita a preocupações de conformidade. Por exemplo, uma solução que armazena dados de um estado nos Estados Unidos pode exigir armazenamento de dados na geografia dos Estados Unidos. Os requisitos de localidade de dados também podem impulsionar essa necessidade.
Localização dos metadados: Embora a localização do dispositivo geralmente não afete a localização dos metadados porque os dispositivos interagem com os dados da solução e não com os metadados da solução, a conformidade e as preocupações com os custos afetam a localização dos metadados. Em muitos casos, a conveniência determina que o local dos metadados seja o mesmo que o local dos dados para serviços regionais.

O Azure Cloud Adoption Framework inclui orientação sobre seleção regional.

Entenda as preocupações de SaaS da empresa de software. As empresas de software que oferecem soluções SaaS devem atender às expectativas dos clientes em termos de disponibilidade e resiliência. As empresas de software devem arquitetar os serviços Azure para serem altamente disponíveis e considerar o custo de resiliência e redundância ao faturar o cliente.

Separe o custo das mercadorias vendidas com base na segregação de dados do cliente para cada cliente de software. Essa distinção é importante quando o usuário não é o mesmo que o cliente. Por exemplo, para uma plataforma de TV inteligente, o cliente do fornecedor da plataforma pode ser o fornecedor de televisão, mas o usuário é o comprador da televisão. Esta segregação, impulsionada pelo modelo de arrendamento do cliente em relação aos requisitos, requer instâncias separadas de DPS e IoT Hub. O serviço de provisionamento também deve ter uma identidade de cliente exclusiva, que você pode definir por meio de um processo de autenticação de dispositivo ou ponto de extremidade exclusivo. Para obter mais informações, consulte Orientações multiclientes da IoT.

Dimensionar componentes e seus serviços de suporte

Ao dimensionar soluções de IoT, avalie cada serviço e como eles se relacionam. Pode escalar a sua solução IoT em múltiplas instâncias de DPS ou utilizando o IoT Hub.

Expansão por várias instâncias do DPS

Devido aos limites de serviço do DPS, muitas vezes você precisa expandir para várias instâncias do DPS. Você pode abordar o provisionamento de dispositivos em várias instâncias DPS por meio do provisionamento zero-touch ou do provisionamento low-touch.

As abordagens seguintes aplicam o conceito anteriormente descrito de carimbo para resiliência e escalabilidade. Este conceito inclui implementar Azure App Service em múltiplas regiões e utilizar uma ferramenta como Traffic Manager ou um global balancer de carga. Para simplificar, os diagramas a seguir não mostram esses componentes.

Abordagem 1: Provisionamento Zero-touch com várias instâncias DPS

Para provisionamento automatizado ou sem toque, uma estratégia comprovada inclui fazer com que o dispositivo solicite um escopo de ID DPS de uma API da Web. A API compreende e equilibra os dispositivos nas instâncias DPS dimensionadas horizontalmente. Essa ação torna o aplicativo Web uma parte crítica do processo de provisionamento, portanto, ele deve ser escalável e altamente disponível. Este design tem três variações principais.

O diagrama a seguir mostra a primeira opção que usa uma API de provisionamento personalizada que gerencia como mapear o dispositivo para o pool de DPS apropriado. Cada instância de DPS mapeia então o dispositivo para o Hub IoT apropriado, usando os mecanismos padrão de DPS de balanceamento de carga.

O dispositivo faz uma solicitação a uma API de provisionamento hospedada no Serviço de Aplicativo para solicitar um escopo de ID DPS. A API de provisionamento verifica com a sua base de dados persistente para determinar a melhor instância para o dispositivo, com base no inventário de dispositivos existente, e retorna o âmbito do ID do DPS.

Neste exemplo, a base de dados é uma instância do Azure Cosmos DB que tem escrita multi-primária ativada para alta disponibilidade entre regiões. Este banco de dados armazena o DPS atribuído a cada dispositivo. Ele suporta o rastreamento do uso da instância do DPS para todas as métricas apropriadas, como solicitações de provisionamento por minuto e total de dispositivos provisionados. Este banco de dados também permite a reconfiguração com o mesmo âmbito de ID do DPS, quando necessário. Autentique a API de provisionamento para evitar solicitações de provisionamento inadequadas.
O dispositivo faz uma solicitação contra o DPS usando o escopo de ID atribuído. DPS responde com detalhes da atribuição do hub IoT.
O dispositivo armazena o escopo de ID e as informações de conexão do hub IoT em armazenamento persistente, idealmente em um local de armazenamento seguro, pois o escopo de ID faz parte da autenticação em relação à instância do DPS. Em seguida, o dispositivo usa essas informações de conexão do hub IoT para solicitações adicionais no sistema.

Este design exige que o software do dispositivo inclua o SDK DPS e gere o processo de inscrição do DPS, que é o design típico para um dispositivo Azure IoT. Mas em um ambiente de microcontrolador, onde o tamanho do software do dispositivo é um componente crítico do design, ele pode não ser aceitável e pode exigir um design alternativo.

Abordagem 2: Provisionamento Zero-Touch com uma API de Provisionamento

A segunda versão move a chamada de DPS para a API de aprovisionamento. Neste modelo, a autenticação do dispositivo no DPS está contida na API de provisionamento, assim como a maior parte da lógica de repetição. Esse processo permite cenários de enfileiramento mais avançados e um código de provisionamento potencialmente mais simples no próprio dispositivo. Ele também permite armazenar em cache o hub IoT atribuído para facilitar mensagens C2D mais rápidas. As mensagens são enviadas sem a necessidade de interrogar o DPS para obter as informações do hub atribuído.

O dispositivo faz uma solicitação para uma API de provisionamento hospedada em uma instância do Serviço de Aplicativo. A API de provisionamento verifica com seu banco de dados persistente a melhor instância para o dispositivo com base no inventário de dispositivos existente e, em seguida, determina o escopo da ID do DPS.

Neste exemplo, a base de dados é uma instância do Azure Cosmos DB que tem escrita multi-primária ativada para alta disponibilidade entre regiões. Este banco de dados armazena o DPS atribuído a cada dispositivo. Ele suporta o acompanhamento do uso da instância do DPS para todas as métricas apropriadas. O banco de dados também permite o reprovisionamento usando o mesmo escopo de ID DPS quando necessário.

Autentique a API de provisionamento para evitar solicitações de provisionamento inadequadas. Você provavelmente pode usar a mesma autenticação que o serviço de provisionamento usa contra o DPS, como uma chave privada para um certificado emitido. Mas existem outras opções. Por exemplo, o FastTrack for Azure pode funcionar com um cliente que utiliza identificadores únicos de hardware como parte do seu processo de autenticação de serviço. O parceiro de fabricação de dispositivos fornece regularmente uma lista de identificadores exclusivos ao fornecedor do dispositivo para carregar em um banco de dados, que faz referência ao serviço por trás da API de provisionamento personalizada.
A API de provisionamento executa o processo de provisionamento do DPS usando o escopo de ID atribuído, agindo efetivamente como um proxy DPS.
A API encaminha os resultados do DPS para o dispositivo.
O dispositivo armazena as informações de conexão do hub IoT em armazenamento persistente, idealmente em um local de armazenamento seguro, pois o escopo do ID faz parte da autenticação na instância do DPS. O dispositivo usa essas informações de conexão do hub IoT para solicitações posteriores no sistema.

Esse design evita a necessidade de fazer referência ao SDK do DPS ou ao serviço DPS. Ele também evita a necessidade de armazenar ou manter um escopo DPS no dispositivo. Esse modelo oferece suporte a cenários de transferência de propriedade porque o serviço de provisionamento pode direcionar para a instância DPS do cliente final apropriada. No entanto, essa abordagem faz com que a API de provisionamento duplique algumas funcionalidades do DPS, que podem não se adequar a todos os cenários.

Abordagem 3: Provisionamento zero touch com transferência de propriedade

Um terceiro design de provisionamento zero-touch usa uma instância DPS configurada de fábrica como ponto de partida e redireciona dispositivos para outras instâncias DPS conforme necessário. Esse design permite o provisionamento sem uma API de provisionamento personalizada, mas requer um aplicativo de gerenciamento para rastrear instâncias DPS e fornecer redirecionamento conforme necessário.

Os requisitos do aplicativo de gerenciamento incluem o rastreamento de qual DPS deve ser o DPS ativo para cada dispositivo específico. Você pode usar essa abordagem para cenários de transferência de propriedade, em que o fornecedor do dispositivo transfere a propriedade do dispositivo do fornecedor para o cliente do dispositivo final.

O dispositivo se conecta à instância DPS configurada de fábrica e solicita um processo de provisionamento inicial.
O dispositivo recebe uma configuração inicial, incluindo a instância DPS de destino desejada.
O dispositivo se conecta à instância DPS de destino desejada e solicita provisionamento.
O dispositivo armazena as informações de conexão do hub IoT em armazenamento persistente, idealmente em um local de armazenamento seguro, pois o escopo do ID faz parte da autenticação na instância do DPS. O dispositivo usa essas informações de conexão do hub IoT para solicitações adicionais no sistema.

Abordagem 4: Provisionamento de baixo toque com várias instâncias DPS

Em alguns casos, como em cenários voltados para o consumidor ou dispositivos da equipe de implantação em campo, uma opção comum é oferecer provisionamento de baixo toque ou assistido pelo usuário. Exemplos de provisionamento com mínima interação física incluem uma aplicação móvel no telemóvel de um instalador ou uma aplicação baseada na Web num gateway de dispositivo. Essa abordagem executa as mesmas operações que o processo de provisionamento zero-touch, mas o aplicativo de provisionamento transfere os detalhes para o dispositivo.

O administrador inicia um aplicativo de configuração do dispositivo, que se conecta ao dispositivo.
O aplicativo de configuração se conecta a uma API de provisionamento hospedada em uma instância do Serviço de Aplicativo para solicitar um escopo de ID DPS. A API de provisionamento verifica seu banco de dados persistente para determinar a melhor instância para o dispositivo, com base no inventário de dispositivos existente, e retorna o escopo da ID do DPS.

Neste exemplo, a base de dados é uma instância do Azure Cosmos DB que tem escrita multi-primária ativada para alta disponibilidade entre regiões. Este banco de dados armazena o DPS atribuído a cada dispositivo. Ele suporta o acompanhamento do uso das instâncias DPS para todas as métricas apropriadas. Esse banco de dados também permite o reprovisionamento usando o mesmo escopo de ID do DPS quando necessário. Autentique a API de provisionamento para evitar que solicitações de provisionamento inadequadas sejam atendidas.
A aplicação devolve o escopo da ID de provisionamento ao dispositivo.
O dispositivo faz uma solicitação ao DPS com o escopo de ID atribuído. O DPS retorna detalhes da atribuição do hub IoT para o dispositivo.
O dispositivo armazena o escopo de ID e as informações de conexão do hub IoT em armazenamento persistente, idealmente em um local seguro, porque o escopo de ID faz parte da autenticação na instância do DPS. O dispositivo usa essas informações de conexão do hub IoT para solicitações adicionais no sistema.

Este artigo não abrange outras variações. Pode-se, por exemplo, configurar esta abordagem movendo a chamada do DPS para a API de provisionamento, conforme mostrado anteriormente no provisionamento zero-touch com uma API de provisionamento. O objetivo é garantir que cada camada seja escalável, configurável e prontamente implantável.

Diretrizes gerais de provisionamento do DPS

Aplique as seguintes recomendações à sua implantação do DPS:

Não configure a cada arranque. A documentação do DPS recomenda que você não provisione em todas as inicializações. Para pequenos casos de uso, pode parecer razoável realizar o provisionamento em cada inicialização, pois é o caminho mais curto para a implantação. No entanto, quando você escala para milhões de dispositivos, o DPS pode se tornar um gargalo devido ao seu limite rígido de 1.000 registros por minuto, por instância de serviço. Até mesmo consultas de estado de registro de dispositivos podem se tornar um gargalo, porque têm um limite de 5 a 10 operações de interrogação por segundo. Os resultados do provisionamento normalmente são mapeados estaticamente para um hub IoT. Portanto, você só deve iniciar o provisionamento quando necessário, a menos que seus requisitos incluam solicitações de reprovisionamento automatizado. Se você prevê mais tráfego, expanda para várias instâncias do DPS para dar suporte ao seu cenário.

Use uma agenda de provisionamento escalonada. Para reduzir as limitações baseadas no tempo, use um cronograma de provisionamento escalonado. Para o provisionamento inicial, você pode aplicar um atraso aleatório de alguns segundos ou estender o atraso para minutos, dependendo dos requisitos de implantação.

Sempre consulte o status antes de solicitar o provisionamento. Como prática recomendada, os dispositivos devem sempre consultar seu status antes de solicitar o provisionamento usando a API de Pesquisa de Status de Registro de Dispositivo. Esta chamada não conta como um item faturado e o limite é independente do limite de registo. A operação de consulta é relativamente rápida comparada com um pedido de provisionamento, pelo que o dispositivo pode validar o seu estado e iniciar a sua carga de trabalho normal mais rapidamente. Para obter a lógica de registro de dispositivo apropriada, consulte Implantação em larga escala.

Siga as considerações da API de provisionamento. Vários dos designs neste artigo incluem uma API de provisionamento. A API de provisionamento necessita de um armazenamento de metadados de apoio, como o Azure Cosmos DB. Nesses níveis de escala, você deve implementar um padrão de design globalmente disponível e resiliente. As capacidades multi-primárias e geo-redundantes integradas e as garantias de latência no Azure Cosmos DB tornam-no uma excelente escolha para este cenário. Esta API tem as seguintes responsabilidades principais:

Sirva o escopo da ID do DPS. Essa interface pode usar uma solicitação GET. Dispositivos físicos ou aplicativos de gerenciamento se conectam a essa interface.
Suporte ao ciclo de vida do dispositivo. Um dispositivo pode precisar de nova configuração, ou podem ocorrer eventos inesperados. No mínimo, mantenha o ID do dispositivo e o DPS atribuído para um dispositivo. Essas informações permitem o desprovisionamento do DPS atribuído e o reprovisionamento em outro. Ou se o ciclo de vida de um dispositivo terminar, pode removê-lo completamente do sistema.
Sistemas de balanceamento de carga. O sistema usa os mesmos metadados em relação ao ID do dispositivo e ao DPS, para que possa entender a carga atual em cada subsistema e aplicar essas informações para equilibrar melhor os dispositivos entre os componentes dimensionados horizontalmente.
Mantenha a segurança do sistema. A API de provisionamento deve autenticar cada solicitação. A prática recomendada é usar um certificado X.509 exclusivo para cada dispositivo. Esse certificado pode autenticar o dispositivo na API de provisionamento e na instância do DPS, se a arquitetura oferecer suporte a ele. Outros métodos, como certificados de frota e tokens, estão disponíveis, mas oferecem menos segurança. Sua implementação específica e suas implicações de segurança dependem se você escolhe uma opção zero-touch ou low-touch.

Ampliar o IoT Hub

Comparado com escalar DPS, expandir o IoT Hub é relativamente simples. Uma das vantagens do DPS é a sua capacidade de se ligar a muitas instâncias de IoT Hub. Quando segue a prática recomendada de usar DPS em soluções Azure IoT, expandir o IoT Hub envolve os seguintes passos:

Crie uma nova instância do serviço IoT Hub.
Configure a nova instância com regras de roteamento apropriadas e outros detalhes.
Vincule a nova instância às instâncias DPS apropriadas.
Se necessário, reconfigure a política de alocação do DPS ou sua política de alocação personalizada.

Projeto de software para dispositivos

O design de dispositivos escaláveis requer seguir as melhores práticas e considerações do lado do dispositivo. Algumas dessas práticas provêm de anti-padrões encontrados no campo. Esta seção descreve os principais conceitos para uma implantação dimensionada com êxito.

Estime cargas de trabalho em diferentes partes do ciclo de vida do dispositivo e cenários dentro do ciclo de vida. As cargas de trabalho de registro de dispositivos podem variar muito entre as fases de desenvolvimento, como piloto, desenvolvimento, produção, descomissionamento e fim de vida útil. Em alguns casos, eles também podem variar com base em fatores externos, como o cenário de apagão mencionado anteriormente. Projete para o cenário de trabalho mais exigente para ajudar a assegurar o sucesso em escala.

Suporte ao reprovisionamento a pedido. Você pode fornecer esse recurso por meio de um comando de dispositivo e uma solicitação de usuário administrativo. Para mais informações, consulte Reprovisionar dispositivos. Esta opção facilita cenários de transferência de propriedade e de reset padrão de fábrica.

Evite reprovisionamentos desnecessários. Dispositivos ativos e funcionais raramente exigem reprovisionamento porque as informações de provisionamento permanecem relativamente estáticas. Não reprovisione sem um bom motivo.

Verifique o status do provisionamento se precisar reprovisionar com frequência, por exemplo, em cada inicialização do dispositivo. Se você não tiver certeza sobre o status de provisionamento do dispositivo, consulte o status de provisionamento primeiro. A operação de consulta está sujeita a uma cota diferente do que uma operação de provisionamento e é mais rápida. Essa consulta permite que o dispositivo valide o status de provisionamento antes de prosseguir. Essa abordagem é especialmente útil quando um dispositivo não tem armazenamento persistente disponível para armazenar os resultados do provisionamento.

Garanta uma boa estratégia de lógica de reintento. O dispositivo deve ter algoritmos de repetição apropriados incorporados no código do dispositivo para provisionamento inicial e reprovisionamento posterior. Use técnicas como backoff exponencial com randomização. O provisionamento inicial, por definição, pode precisar ser mais agressivo no processo de tentativas do que o reprovisionamento, dependendo do caso de uso. Quando limitado, o DPS devolve um código de erro HTTP 429 Too Many Requests, como a maioria dos serviços do Azure. Para obter mais informações, consulte Repetir e Antipadrões a evitar. A documentação do DPS também explica como interpretar recomendações de repetição dos serviços e calcular jitter. A estabilidade da localização do dispositivo e o acesso à conectividade também influenciam a estratégia de repetição apropriada. Por exemplo, se um dispositivo detetar que está offline durante períodos de tempo, deve evitar voltar a tentar operações online.

Suporte a atualizações sem fio (OTA). Dois modelos de atualização simples incluem o uso de propriedades gêmeas de dispositivo com gerenciamento automático de dispositivos e o uso de comandos de dispositivo simples. Para cenários e relatórios de atualizações mais sofisticados, consulte Azure Atualização do Dispositivo. As atualizações OTA permitem corrigir defeitos no código do dispositivo e reconfigurar serviços, como o escopo da ID DPS, se necessário.

Responsável pela arquitetura das alterações de certificados em todas as camadas e seus usos. Esta recomendação está alinhada com as melhores práticas de atualização da OTA. Você deve considerar a rotação de certificados. A documentação IoT Hub DPS aborda este cenário do ponto de vista de um certificado de identidade de dispositivo. Numa solução de dispositivo, outros certificados são usados para o acesso a serviços como IoT Hub, App Service e contas do Azure Storage. O Azure por vezes altera as configurações da autoridade certificadora, por isso deve antecipar alterações em todas as camadas. Além disso, use a fixação de certificados com cuidado, especialmente quando os certificados estiverem fora do controle do fabricante do dispositivo.

Considere um estado padrão razoável. Para resolver falhas iniciais de provisionamento, estabeleça uma configuração que seja razoável para estar desconectada ou não provisionada, dependendo das circunstâncias. Se o dispositivo tiver um componente de interação pesado como parte do provisionamento inicial, o processo de provisionamento poderá ocorrer em segundo plano enquanto o usuário executa outras tarefas de provisionamento. Certifique-se de emparelhar esta abordagem com um padrão de repetição apropriado e o Circuit Breaker pattern.

Inclua capacidades de configuração de ponto de extremidade onde apropriado. Permita a configuração do escopo da ID do DPS, do ponto de extremidade do DPS ou do ponto de extremidade do serviço de provisionamento personalizado. Embora o endpoint DPS raramente mude, permitir esta flexibilidade suporta cenários como a validação automática do processo de provisionamento do dispositivo através de testes de integração sem acesso direto ao Azure ou futuros modelos de provisionamento que utilizam um serviço proxy.

Use os SDKs do Azure IoT para provisionamento. Quer as chamadas DPS estejam no próprio dispositivo ou numa API de provisionamento personalizada, use os SDKs Azure IoT para beneficiar das melhores práticas integradas e simplificar o suporte. Os SDKs são publicados em open source, por isso podes rever como funcionam e sugerir alterações. Sua escolha de SDK depende do hardware do dispositivo e dos tempos de execução disponíveis no dispositivo.

Implantar dispositivos

A implantação de dispositivos é uma parte fundamental do ciclo de vida do dispositivo, mas está fora do escopo deste artigo porque depende do caso de uso. Os pontos de discussão mencionados anteriormente sobre transferência de propriedade podem se aplicar à implantação e aos padrões que envolvem um aplicativo de provisionamento, como um aplicativo móvel. Mas você deve selecionar a abordagem de implantação com base no tipo de dispositivo IoT em uso.

Dispositivos de monitorização

Uma parte importante de sua implantação geral é monitorar a solução do início ao fim para garantir que o sistema funcione adequadamente. Este artigo se concentra explicitamente na arquitetura e no design e não nos aspetos operacionais da solução, portanto, o monitoramento não está incluído. No entanto, a um nível geral, as ferramentas de monitorização estão integradas em Azure através de Azure Monitor para garantir que a solução não atinge limites. Para obter mais informações, consulte os seguintes artigos:

Pode usar estas ferramentas individualmente ou como parte de uma solução mais sofisticada de Gestão de Informação e Eventos de Segurança (SIEM), como Microsoft Sentinel.

Use os seguintes padrões de monitoramento para monitorar o uso do DPS ao longo do tempo:

Crie um aplicativo que consulte cada grupo de registro em uma instância do DPS, recupere o total de dispositivos registrados nesse grupo e agrega os números de vários grupos de registro. Este método fornece uma contagem exata de dispositivos atualmente registrados via DPS e ajuda a monitorar o estado do serviço.
Monitorize os registos de dispositivos durante um período específico. Por exemplo, você pode monitorar as taxas de registro para uma instância do DPS nos últimos cinco dias. Esta abordagem fornece apenas um valor aproximado e está limitada a um período de tempo definido.

Conclusão

Expandir uma solução de IoT para suportar milhões, ou mesmo centenas de milhões, de dispositivos requer um planejamento cuidadoso. Você deve considerar muitos fatores e várias maneiras de resolver os problemas que surgem nessas escalas. Este artigo resume as principais preocupações e fornece abordagens sobre como lidar com essas preocupações em uma implantação bem-sucedida.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

Michael C. Bazarewsky | Engenheiro de Cliente Sénior, Microsoft Azure CXP

Outros contribuidores:

David Crook | Director de Engenharia de Cliente Principal, Microsoft Azure CXP
Alberto Gorni | Antigo Engenheiro Sénior de Clientes, Microsoft Azure CXP

Para ver perfis de LinkedIn não públicos, inicie sessão no LinkedIn.

Próximos passos

Comentários

Esta página foi útil?

Last updated on 2026-04-22