Gérer les reconnexions d’appareils pour créer des applications résilientes

Article
10/17/2024

Cet article fournit une aide de haut niveau pour vous permettre de concevoir des applications résilientes en ajoutant une stratégie de reconnexion d’appareil. Elle explique pourquoi les appareils se déconnectent et doivent se reconnecter, et décrit également des stratégies spécifiques que les développeurs peuvent adopter pour reconnecter les appareils qui ont été déconnectés.

Ce qui provoque des déconnexions

Voici les raisons les plus courantes pour lesquelles les appareils se déconnectent d’IoT Hub :

Expiration de jeton SAP ou de certificat X.509. Le jeton SAP ou le certificat d’authentification X.509 de l’appareil a expiré.
Interruption réseau. La connexion de l’appareil au réseau est interrompue.
Interruption de service. Le service Azure IoT Hub rencontre des erreurs ou est temporairement indisponible.
Reconfiguration du service. Une reconfiguration des paramètres du service IoT Hub peut nécessiter un réapprovisionnement ou une reconnexion des appareils.

Pourquoi une stratégie de reconnexion est-elle nécessaire ?

Il est important d’avoir une stratégie de reconnexion des appareils, comme décrit dans les sections suivantes. Sans stratégie de reconnexion, vous risquez d’observer une dégradation des performances et de la disponibilité de votre solution ainsi qu’une augmentation des coûts.

Des tentatives de reconnexion en masse peuvent entraîner une attaque DDoS

Un nombre élevé de tentatives de connexion par seconde peut entraîner une condition similaire à une attaque par déni de service distribué (DDoS). Ce scénario est pertinent pour les flottes comptant plusieurs millions d’appareils. Le problème peut s’étendre au-delà du locataire propriétaire de la flotte, et affecter l’ensemble de l’unité d’échelle. Une attaque DDoS pourrait entraîner une augmentation importante des coûts pour vos ressources Azure IoT Hub, en raison de la nécessité d’un scale-out. Une attaque DDoS pourrait également nuire aux performances de votre solution en raison d’une privation de ressources. Dans le pire des cas, une attaque DDoS peut entraîner une interruption de service.

Une défaillance ou une reconfiguration du hub peut déconnecter de nombreux appareils

Après une défaillance de hub IoT, ou après une reconfiguration des paramètres de service sur un hub IoT, il se peut que les appareils soient déconnectés. Pour un basculement approprié, les appareils déconnectés nécessitent un réapprovisionnement. Pour en savoir plus sur les options de basculement, consultez Haute disponibilité et récupération d’urgence IoT Hub.

Le réapprovisionnement de nombreux appareils peut augmenter les coûts

Après la déconnexion des appareils d’IoT Hub, la solution optimale consiste à les reconnecter plutôt qu’à les réapprovisionner. Si vous utilisez IoT Hub avec DPS, DPS a un coût par approvisionnement. Si vous réapprovisionnez de nombreux appareils sur DPS, cela augmente le coût de votre solution IoT. Si vous souhaitez en savoir plus sur les coûts d’approvisionnement DPS, veuillez consulter la rubrique Tarification IoT Hub DPS.

Conception pour la résilience

Les appareils IoT s’appuient souvent sur des connexions réseau non continues ou instables (telles que des connexions GSM ou satellite). Des erreurs peuvent se produire quand les appareils interagissent avec les services cloud à cause d’une disponibilité intermittente des services et d’erreurs d’infrastructure ou temporaires. Une application qui s’exécute sur un appareil doit gérer les mécanismes de connexion et reconnexion ainsi que la logique de nouvelle tentative pour l’envoi et la réception de messages. De plus, les exigences de stratégie de nouvelles tentatives dépendent fortement du scénario IoT, du contexte et des fonctionnalités de l’appareil.

Les kits SDK d’appareil Azure IoT Hub ont pour but de simplifier la connexion et la communication de cloud-à-appareil et d’appareil-à-cloud. Ces kits fournissent un moyen fiable de se connecter à Azure IoT Hub et un ensemble complet d’options pour envoyer et recevoir des messages. Les développeurs peuvent également modifier l’implémentation existante pour personnaliser une meilleure stratégie de nouvelles tentatives pour un scénario donné.

Les fonctionnalités SDK pertinentes qui prennent en charge la connectivité et la messagerie fiable sont disponibles dans les kits SDK d’appareil IoT Hub suivants. Pour plus d’informations, consultez la documentation de l’API ou le kit SDK spécifique :

Les sections suivantes décrivent les fonctionnalités de kit SDK qui prennent en charge la connectivité.

Connexion et nouvelle tentative

Cette section fournit une vue d’ensemble des modèles de reconnexion et de nouvelles tentatives disponibles lors de la gestion des connexions. Elle détaille les conseils d’implémentation pour l’utilisation d’une stratégie de nouvelles tentatives différente dans votre application d’appareil et répertorie les API appropriées des kits SDK d’appareil.

Modèles d’erreur

Des échecs de connexion peuvent se produire à de nombreux niveaux :

Erreurs réseau : socket déconnecté et erreurs de résolution de nom
Erreurs au niveau du protocole pour le transport HTTP, AMQP et MQTT : liens détachés ou sessions expirées
Erreurs au niveau de l’application qui résultent d’erreurs locales, telles que des informations d’identification non valides, ou du comportement des services, tel que le dépassement du quota ou de la limitation

Les kits SDK d’appareil détectent les erreurs aux trois niveaux. Toutefois, les kits SDK d’appareil ne détectent pas et ne gèrent pas les erreurs liées au système d’exploitation et les erreurs matérielles. La conception des kits SDK est basée sur le Guide de gestion des erreurs temporaires fourni dans le Centre des architectures Azure.

Modèles de nouvelle tentative

Les étapes suivantes décrivent le processus de nouvelle tentative lors de la détection d’erreurs de connexion :

Le kit SDK détecte l’erreur et l’erreur associée dans le réseau, le protocole ou l’application.
Le kit SDK utilise le filtre d’erreur pour déterminer le type d’erreur et décider si une nouvelle tentative est nécessaire.
Si le kit SDK identifie une erreur irrécupérable, les opérations telles que la connexion, l’envoi et la réception sont arrêtées. Le kit SDK en informe l’utilisateur. Une erreur d’authentification et une erreur de point de terminaison défectueux sont des exemples d’erreurs irrécupérables.
Si le kit SDK identifie une erreur irrécupérable, il effectue une nouvelle tentative en fonction de la stratégie de nouvelles tentatives spécifiée jusqu’à l’expiration du délai donné. Par défaut, le kit SDK utilise une stratégie de nouvelles tentatives basée sur le backoff exponentiel avec gigue.
Quand le délai imparti expire, le kit SDK arrête d’essayer d’établir la connexion ou l’envoi. Il en informe l’utilisateur.
Le kit SDK permet à l’utilisateur de joindre un rappel pour recevoir les modifications de l’état de la connexion.

Les Kits de développement logiciel (SDK) fournissent trois stratégies de nouvelles tentatives :

Interruption exponentielle avec instabilité : cette stratégie de nouvelles tentatives par défaut a tendance à être agressive au début, puis ralentit progressivement avant d’atteindre un délai maximal. La conception est basée sur le Guide sur les nouvelles tentatives fourni dans le Centre des architectures Azure.
Nouvelle tentative personnalisée : pour certains langages de SDK, vous pouvez concevoir une stratégie de nouvelles tentatives personnalisée qui est mieux adaptée à votre scénario, puis l’injecter dans la stratégie de nouvelles tentatives. La nouvelle tentative personnalisée n’est pas disponible sur le Kit de développement logiciel (SDK) C et n’est actuellement pas prise en charge sur le Kit de développement logiciel (SDK) Python. Le kit SDK Python se reconnecte en fonction des besoins.
Aucune nouvelle tentative : vous pouvez définir la stratégie de nouvelles tentatives sur « aucune nouvelle tentative », ce qui désactive la logique de nouvelle tentative. Le kit SDK tente de se connecter une fois et d’envoyer un message une fois, en supposant que la connexion est établie. Cette stratégie est généralement utilisée dans des scénarios avec des problèmes de bande passante ou de coût. Si vous choisissez cette option, les messages qui ne peuvent pas être envoyés sont perdus et ne peuvent pas être récupérés.

API de stratégie de nouvelles tentatives

Kit SDK	Méthode SetRetryPolicy	Implémentations de stratégie	Conseils d’implémentation
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Veuillez consulter la rubrique : IOTHUB_CLIENT_RETRY_POLICY	Implémentation C
Java	SetRetryPolicy	Par défaut : classe ExponentialBackoffWithJitter Personnalisé : implémenter l’interface RetryPolicy Aucune nouvelle tentative : classe NoRetry	Implémentation Java
.NET	DeviceClient.SetRetryPolicy	Par défaut : classe ExponentialBackoff Personnalisée : implémenter l’interface IRetryPolicy Aucune nouvelle tentative : classe NoRetry	Implémentation C#
Nœud	setRetryPolicy	Par défaut : classe ExponentialBackoffWithJitter Personnalisée : implémenter l’interface RetryPolicy Aucune nouvelle tentative : classe NoRetry	Implémentation Node
Python	Non prise en charge pour le moment	Non prise en charge pour le moment	Nouvelles tentatives de connexion intégrées : les connexions supprimées sont retentées à un intervalle fixe de dix secondes par défaut. Cette fonctionnalité peut être désactivée si vous le souhaitez, et l’intervalle peut être configuré.

Flux de reconnexion au hub

Si vous utilisez IoT Hub uniquement sans DPS, utilisez la stratégie de reconnexion suivante.

Lorsqu’un appareil ne parvient pas à se connecter à IoT Hub ou s’il est déconnecté d’IoT Hub :

Utilisez une fonction de retardement basé sur le backoff exponentiel avec gigue.
Reconnectez-vous à IoT Hub.

Le diagramme suivant résume le flux de reconnexion :

Diagramme du flux de reconnexion d’appareil pour IoT Hub.

Flux de reconnexion à un hub avec DPS

Si vous utilisez IoT Hub avec DPS, utilisez la stratégie de reconnexion suivante.

Lorsqu’un appareil ne peut pas se connecter à IoT Hub ou est déconnecté d’IoT Hub, reconnectez-vous sur la base des cas suivants :

Scénario de reconnexion	Stratégie de reconnexion
Pour les erreurs qui autorisent les nouvelles tentatives de connexion (code de réponse HTTP 500)	Utilisez une fonction de retardement basé sur le backoff exponentiel avec gigue. Reconnectez-vous à IoT Hub.
Pour les erreurs indiquant qu’une nouvelle tentative est possible, mais la reconnexion a échoué 10 fois de suite	Réapprovisionnez l’appareil sur DPS.
Pour les erreurs qui n’autorisent pas les nouvelles tentatives de connexion (réponses HTTP 401, Non autorisé ou 403, Interdit ou 404, Introuvable)	Réapprovisionnez l’appareil sur DPS.