Gerencie reconexões de dispositivos para criar aplicativos resilientes

Artigo
10/17/2024

Este artigo fornece orientação de alto nível para ajudá-lo a projetar aplicativos resilientes adicionando uma estratégia de reconexão de dispositivo. Ele explica por que os dispositivos se desconectam e precisam se reconectar. E descreve estratégias específicas que os desenvolvedores podem usar para reconectar dispositivos que foram desconectados.

O que causa desconexões

A seguir estão os motivos mais comuns pelos quais os dispositivos se desconectam do Hub IoT:

Token SAS expirado ou certificado X.509. O token SAS ou certificado de autenticação X.509 do dispositivo expirou.
Interrupção da rede. A ligação do dispositivo à rede é interrompida.
Interrupção do serviço. O serviço Hub IoT do Azure apresenta erros ou está temporariamente indisponível.
Reconfiguração do serviço. Depois de reconfigurar as configurações do serviço Hub IoT, isso pode fazer com que os dispositivos exijam reprovisionamento ou reconexão.

Por que você precisa de uma estratégia de reconexão

É importante ter uma estratégia para reconectar dispositivos, conforme descrito nas seções a seguir. Sem uma estratégia de reconexão, você pode ver um efeito negativo no desempenho, na disponibilidade e no custo da solução.

Tentativas de novas ligações em massa podem causar um DDoS

Um elevado número de tentativas de ligação por segundo pode causar uma condição semelhante a um ataque Denial of Service distribuído (DDoS). Este cenário é relevante para grandes frotas de dispositivos que somam milhões. O problema pode ir além do inquilino proprietário da frota e afetar toda a unidade de escala. Um DDoS pode gerar um grande aumento do custo para os recursos do Hub IoT do Azure, devido à necessidade de escalamento horizontal. Um DDoS também pode prejudicar o desempenho da sua solução devido à escassez de recursos. No pior dos casos, um DDoS pode causar interrupção do serviço.

Falha ou reconfiguração do hub pode desconectar muitos dispositivos

Depois que um hub IoT tiver uma falha ou depois que você reconfigurar as configurações de serviço em um hub IoT, os dispositivos poderão ser desconectados. Para um failover adequado, os dispositivos desconectados exigem reprovisionamento. Para saber mais sobre opções de failover, consulte Alta disponibilidade e recuperação de desastres do Hub IoT.

O reprovisionamento de muitos dispositivos pode aumentar os custos

Depois que os dispositivos se desconectam do Hub IoT, a solução ideal é reconectar o dispositivo em vez de reprovisioná-lo. Se você usa o Hub IoT com DPS, o DPS tem um custo por provisionamento. Se você reprovisionar muitos dispositivos no DPS, isso aumentará o custo da sua solução de IoT. Para saber mais sobre os custos de provisionamento do DPS, consulte Preços do DPS do Hub IoT.

Estrutura para resiliência

Os dispositivos IoT dependem frequentemente de ligações de rede não contínuas ou instáveis (por exemplo, GSM ou satélite). Os erros podem ocorrer quando os dispositivos interagem com serviços baseados na nuvem devido à disponibilidade intermitente do serviço e a falhas transitórias ou ao nível da infraestrutura. Um aplicativo executado em um dispositivo tem que gerenciar os mecanismos de conexão, reconexão e a lógica de repetição para enviar e receber mensagens. Além disso, os requisitos da estratégia de repetição dependem muito do cenário, do contexto e dos recursos de IoT do dispositivo.

Os SDKs de dispositivo do Hub IoT do Azure visam simplificar a conexão e a comunicação da nuvem para o dispositivo e do dispositivo para a nuvem. Esses SDKs fornecem uma maneira robusta de se conectar ao Hub IoT do Azure e um conjunto abrangente de opções para enviar e receber mensagens. Os desenvolvedores também podem modificar a implementação existente para personalizar uma melhor estratégia de repetição para um determinado cenário.

Os recursos relevantes do SDK que suportam conectividade e mensagens confiáveis estão disponíveis nos seguintes SDKs de dispositivo do Hub IoT. Para obter mais informações, consulte a documentação da API ou SDK específico:

As seções a seguir descrevem os recursos do SDK que oferecem suporte à conectividade.

Conexão e nova tentativa

Esta seção fornece uma visão geral dos padrões de reconexão e repetição disponíveis ao gerenciar conexões. Ele detalha as diretrizes de implementação para usar uma política de repetição diferente em seu aplicativo de dispositivo e lista APIs relevantes dos SDKs de dispositivo.

Padrões de erro

Falhas de conexão podem acontecer em vários níveis:

Erros de rede: soquete desconectado e erros de resolução de nomes
Erros no nível de protocolo para transporte HTTP, AMQP e MQTT: links desanexados ou sessões expiradas
Erros no nível do aplicativo que resultam de erros locais: credenciais inválidas ou comportamento de serviço (por exemplo, exceder a cota ou limitação)

Os SDKs de dispositivo detetam erros em todos os três níveis. No entanto, os SDKs de dispositivo não detetam e lidam com erros relacionados ao sistema operacional e erros de hardware. O design do SDK é baseado na Orientação de Tratamento de Falhas Transitórias do Centro de Arquitetura do Azure.

Padrão de Repetição

As etapas a seguir descrevem o processo de repetição quando erros de conexão são detetados:

O SDK deteta o erro e o erro associado na rede, protocolo ou aplicativo.
O SDK usa o filtro de erro para determinar o tipo de erro e decidir se uma nova tentativa é necessária.
Se o SDK identificar um erro irrecuperável, operações como conexão, envio e recebimento serão interrompidas. O SDK notifica o usuário. Exemplos de erros irrecuperáveis incluem um erro de autenticação e um erro de ponto final incorreto.
Se o SDK identificar um erro recuperável, ele tentará novamente de acordo com a política de repetição especificada até que o tempo limite definido expire. O SDK usa back-off exponencial com política de repetição de jitter por padrão.
Quando o tempo limite definido expira, o SDK para de tentar se conectar ou enviar. Ele notifica o usuário.
O SDK permite que o usuário anexe um retorno de chamada para receber alterações no status da conexão.

Os SDKs normalmente fornecem três políticas de repetição:

Retrocesso exponencial com instabilidade: essa política de repetição padrão tende a ser agressiva no início e desacelerar ao longo do tempo até atingir um atraso máximo. O design é baseado nas diretrizes de repetição do Centro de Arquitetura do Azure.
Repetição personalizada: para alguns idiomas do SDK, você pode criar uma política de repetição personalizada que seja mais adequada ao seu cenário e, em seguida, injetá-la na RetryPolicy. A repetição personalizada não está disponível no C SDK e atualmente não é suportada no Python SDK. O SDK do Python se reconecta conforme necessário.
No retry: Você pode definir a política de repetição como "no retry", o que desativa a lógica de repetição. O SDK tenta se conectar uma vez e enviar uma mensagem uma vez, supondo que a conexão seja estabelecida. Essa política geralmente é usada em cenários com problemas de largura de banda ou custo. Se você escolher essa opção, as mensagens que não forem enviadas serão perdidas e não poderão ser recuperadas.

APIs de política de repetição

SDK	Método SetRetryPolicy	Implementação de políticas	Documentação de orientação para a implementação
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Veja: IOTHUB_CLIENT_RETRY_POLICY	Execução C
Java	SetRetryPolicy	Padrão: classe ExponentialBackoffWithJitter Personalizado: implementar a interface RetryPolicy Sem retry: classe NoRetry	Implementação Java
.NET	DeviceClient.SetRetryPolicy	Padrão: classe ExponentialBackoff Personalizado: implementar interface IRetryPolicy Sem retry: classe NoRetry	Implementação em C#
Nó	setRetryPolicy	Padrão: classe ExponentialBackoffWithJitter Personalizado: implementar a interface RetryPolicy Sem retry: classe NoRetry	Implementação do nó
Python	Não é suportado atualmente	Não é suportado atualmente	Tentativas de conexão internas: as conexões descartadas são repetidas com um intervalo fixo de 10 segundos por padrão. Essa funcionalidade pode ser desabilitada, se desejado, e o intervalo pode ser configurado.

Fluxo de reconexão do hub

Se você usar o Hub IoT somente sem DPS, use a seguinte estratégia de reconexão.

Quando um dispositivo não consegue se conectar ao Hub IoT ou é desconectado do Hub IoT:

Use um back-off exponencial com a função de atraso de desvio.
Reconecte-se ao Hub IoT.

O diagrama a seguir resume o fluxo de reconexão:

Diagrama do fluxo de reconexão de dispositivos para o Hub IoT.

Hub com fluxo de reconexão DPS

Se você usa o Hub IoT com DPS, use a seguinte estratégia de reconexão.

Quando um dispositivo não consegue se conectar ao Hub IoT ou é desconectado do Hub IoT, reconecte-se com base nos seguintes casos:

Cenário de reconexão	Estratégia de reconexão
Para erros que permitem novas tentativas de conexão (código de resposta HTTP 500)	Use um back-off exponencial com a função de atraso de desvio. Reconecte-se ao Hub IoT.
Para erros que indicam que uma nova tentativa é possível, mas a reconexão falhou 10 vezes consecutivas	Reprovisione o dispositivo para DPS.
Para erros que não permitem novas tentativas de conexão (respostas HTTP 401, Não autorizadas ou 403, Proibidas ou 404, Não encontradas)	Reprovisione o dispositivo para DPS.