Gerenciar reconexões de dispositivo para criar aplicativo resilientes

Artigo
04/12/2024

Este artigo fornece diretrizes de alto nível para ajudar você a projetar aplicativos resilientes adicionando uma estratégia de reconexão de dispositivo. Ela 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 as desconexões

Veja a seguir os motivos mais comuns pelos quais os dispositivos se desconectam do Hub IoT:

Token SAS ou certificado X.509 expirado. O token SAS do dispositivo ou o certificado de autenticação X.509 expirou.
Interrupção de rede. A conexão do dispositivo com a rede é interrompida.
Interrupção de serviço. O serviço Hub IoT do Azure apresenta erros ou está temporariamente indisponível.
Reconfiguração de serviço. Depois de reconfigurar as configurações de serviço do 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, disponibilidade e custo da solução.

Tentativas de reconexão em massa podem causar um DDoS

Um alto número de tentativas de conexão por segundo pode causar uma condição semelhante a um DDoS (ataque de negação de serviço distribuído). Este cenário é relevante para grandes frotas de dispositivos que chegam a milhões. O problema pode se estender além do locatário que possui a frota e afetar toda a unidade de escala. Um DDoS pode gerar um grande aumento de custo para seus recursos do Hub IoT do Azure devido à necessidade de expansão. Um DDoS também pode prejudicar o desempenho da solução devido à falta de recursos. Em pior caso, um DDoS pode causar interrupção de serviço.

A falha ou reconfiguração do hub pode desconectar muitos dispositivos

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

Reprovisionar 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ê usar Hub IoT com DPS, o DPS terá um custo por provisionamento. Se você reprovisionar muitos dispositivos no DPS, ele aumentará o custo da solução de IoT. Para saber mais sobre os custos de provisionamento de DPS, consulte Preços do IoT Hub DPS.

Design para resiliência

Os dispositivos IoT geralmente dependem de conexões de rede não descontínuas ou instáveis (por exemplo, GSM ou satélite). Erros podem ocorrer quando os dispositivos interagem com serviços baseados em nuvem devido por causa da disponibilidade do serviço intermitente e nível de infraestrutura ou falhas transitórias. Um aplicativo em execução em um dispositivo precisa gerenciar os mecanismos de conexão, reconexão, bem como a lógica de nova tentativa para enviar e receber mensagens. Além disso, os requisitos da estratégia de repetição dependem consideravelmente o do cenário de IoT do dispositivo, contexto, recursos.

Os SDKs do dispositivo Hub IoT do Azure têm como objetivo simplificar a conexão e comunicação da nuvem para o dispositivo e o dispositivo para a nuvem. Esses SDKs fornecem uma maneira robusta para 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 estratégia de tentativa melhor para um determinado cenário.

Os recursos relevantes do SDK que dão suporte a 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 API ou SDK específico:

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

Conexão e repetição

Esta seção fornece uma visão geral da reconexão e tentar novamente padrões disponíveis ao gerenciar conexões. Ela fornece detalhes sobre diretrizes de implementação para usar uma política de repetição diferente em seu aplicativo de dispositivo e lista as APIs relevantes de SDKs do dispositivo.

Padrões de erros

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

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

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

Padrões de repetição

As etapas a seguir descrevem o processo de repetição quando forem detectados erros de conexão:

O SDK detecta 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 identifica um erro irrecuperável, operações, como a conexão, enviar e receber são interrompidos. O SDK notificará o usuário. Exemplos de erros irrecuperáveis incluem um erro de autenticação e um erro de ponto de extremidade ruim.
Se o SDK identifica um erro recuperável, ele tentará novamente de acordo com a política de repetição especificada até que tenha decorrido o tempo limite definido. O SDK usa retirada exponencial com a política de repetição de variação por padrão.
Quando o tempo limite definido expira, o SDK para de tentar conectar ou enviar. Notifica o usuário.
O SDK permite ao usuário anexar um retorno de chamada para receber alterações no status da conexão.

Normalmente, os SDKs fornecem três políticas de repetição:

Retirada exponencial com tremulação: Essa política de repetição padrão tende a ser agressiva no início e diminuir ao longo do tempo até atingir um atraso máximo. O design é baseado nas Diretrizes de repetição do Azure Architecture Center.
Repetição personalizada: Para alguns idiomas do SDK, é possível criar uma política de repetição personalizada mais adequada ao seu cenário e, em seguida, injetá-la na RetryPolicy. A repetição personalizada não está disponível no SDK C e atualmente não tem suporte no SDK Python. O SDK do Python reconecta conforme necessário.
Sem repetição: você pode definir a política de repetição para "nenhuma repetição," que desabilitará a lógica de repetição. O SDK tenta conectar uma vez e enviar uma mensagem uma vez, assumindo que a conexão foi estabelecida. Essa política é normalmente usada em cenários com questões 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 da política de repetição

.	Método SetRetryPolicy	Implementações de política	Diretrizes de implementação
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Consulte : IOTHUB_CLIENT_RETRY_POLICY	Implementação em C
Java	SetRetryPolicy	Padrão: Classe ExponentialBackoffWithJitter Personalizado: implementar interface RetryPolicy Sem repetição:classe NoRetry	Implementação Java
.NET	DeviceClient.SetRetryPolicy	Padrão: Classe ExponentialBackoff Personalizado: implementa interface IRetryPolicy Sem repetição:classe NoRetry	Implementação C#
Nó	setRetryPolicy	Padrão: Classe ExponentialBackoffWithJitter Personalizado: implementa interface RetryPolicy Sem repetição:classe NoRetry	Implementação Node
Python	Sem suporte no momento	Sem suporte no momento	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 desejar 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 falha ao se conectar ao Hub IoT ou é desconectado do Hub IoT:

Use uma retirada exponencial com a função de atraso de tremulação.
Reconecte-se ao Hub IoT.

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

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

Hub com fluxo de reconexão de DPS

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

Quando um dispositivo falhar ao conectar o Hub IoT ou for desconectado do Hub IoT, faça a reconexão 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 uma retirada exponencial com a função de atraso de tremulação. Reconecte-se ao Hub IoT.
Para erros indicando que uma repetição é possível, mas a reconexão falhou 10 vezes consecutivas	Reprovisione o dispositivo para o 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 o DPS.