Partager via

Développer des applications hautement disponibles avec l’Agent MQTT

  • Article

La création d’une application hautement disponible à l’aide de l’Agent MQTT implique un examen attentif des types de session, de la qualité de service (QoS), des accusés de réception de messages, du traitement parallèle des messages, de la rétention des messages et des abonnements partagés. L’Agent MQTT présente un agent de messages distribué en mémoire et un magasin qui offre une rétention des messages et une gestion intégrée des états avec la sémantique MQTT.

Les sections suivantes décrivent les paramètres et fonctionnalités qui contribuent à l’obtention d’une application distribuée, robuste et sans perte de message.

Quality of service (QoS)

Les éditeurs et les abonnés doivent utiliser QoS-1 pour garantir la remise des messages au moins une fois. L’Agent MQTT stocke et retransmet les messages jusqu’à ce qu’il reçoive un accusé de réception (ACK) du destinataire, ce qui garantit qu’aucun message n’est perdu pendant la transmission.

Type de session et indicateur Clean-Session

Pour garantir zéro perte de message, définissez l’indicateur clean-start avec la valeur false lors de la connexion à l’Agent MQTT. Ce paramètre informe le répartiteur de maintenir l’état de session du client, en préservant les abonnements et les messages sans accusé de réception entre les connexions. Si le client se déconnecte et se reconnecte ultérieurement, il reprend à partir de l’endroit où il s’est arrêté, recevant tous les messages QoS-1 sans accusé de réception via nouvelle tentative de remise de messages. S’il est configuré, l’Agent MQTT clôt la session cliente si le client ne se reconnecte pas dans l’Intervalle d’expiration de la session. La valeur par défaut est d’un jour.

Receive-Max (réception maximale) dans les applications multithread

Les applications multithread doivent utiliser la fonctionreceive-max (65 535 maximum) pour traiter les messages en parallèle et appliquer le contrôle de flux. Ce paramètre optimise le traitement des messages en autorisant plusieurs threads à travailler simultanément sur les messages sans que répartiteur ne surcharge l’application avec un taux de messages élevé supérieur la capacité de l’application. Chaque thread peut traiter un message indépendamment et envoyer son accusé de réception une fois l’opération terminée. Une pratique classique consiste à configurer la réception maximale proportionnellement au nombre de threads que l’application utilise.

Accuser réception des messages

Lorsque l’application d’un abonné envoie un accusé de réception pour un message QoS-1, elle prend possession du message. Dès réception de l’accusé de réception d’un message QoS-1, l’Agent MQTT cesse de suivre le message pour cette application et cette rubrique. Le transfert approprié de propriété garantit la conservation des messages en cas de problème de traitement ou d’incident d’application. Si une application souhaite la protéger contre les incidents d’application, l’application ne doit pas prendre possession avant de terminer le traitement de ce message. Les applications s’abonnant à l’Agent MQTT doivent retarder l’accusé de réception des messages jusqu’à ce que le traitement se termine et atteigne la valeur receive-max, soit un maximum de 65 535. Cela peut inclure que le message soit relayé ou dérivé vers l’Agent MQTT pour une future répartition.

Comportement de rétention et de répartition des messages

Le répartiteur conserve les messages jusqu’à ce qu’il reçoive un accusé de réception d’un abonné, ce qui garantit qu’aucun message n’a été perdu. Ce comportement garantit que même si l’application d’un abonné plante ou perd temporairement la connectivité, les messages ne se perdent pas et peuvent être traités une fois l’application reconnectée. Les messages de l’Agent MQTT risquent d’expirer s’ils sont configurés avec Message-Expiry-Interval et si un abonné n’a pas consommé le message.

Messages conservés

Les messages conservés gardent l’état temporaire de l’application, tel que l’état ou la valeur la plus récente d’une rubrique spécifique. Lorsqu’un nouveau client s’abonne à une rubrique, il reçoit le dernier message conservé, lui garantissant de disposer des informations les plus à jour.

Keep-Alive

Pour garantir une haute disponibilité en cas d'erreurs de connexion ou de déconnexions, configurez des intervalles de maintien de la connexion (keep-alive intervals) appropriés pour la communication client-serveur. Pendant les périodes d’inactivité, les clients envoient PINGREQs, en attente dePINGRESPs. En l’absence de réponse, mettez en place une logique de reconnexion automatique vers le client pour rétablir les connexions. La plupart des clients comme Paho disposent d’une logique de nouvelle tentative intégrée. Comme l’Agent MQTT est tolérant aux pannes, une reconnexion réussit s’il existe au moins deux instances d’agent saines : une front-end et une back-end.

Cohérence éventuelle avec l’abonnement QoS-1

Les abonnements MQTT avec QoS-1 garantissent la cohérence éventuelle entre les instances d’application identiques en s’abonnant à une rubrique partagée. À mesure que les messages sont publiés, les instances reçoivent et répliquent des données avec une livraison au moins une fois. Les instances doivent gérer les doublons et tolérer des incohérences temporaires jusqu’à ce que les données soient synchronisées.

Abonnements partagés

Les abonnements partagés permettent l’équilibrage de charge entre plusieurs instances d’une application hautement disponible. Plutôt que chaque abonné reçoive une copie de chaque message, les messages sont distribués uniformément entre les abonnés. Actuellement, l’Agent MQTT prend uniquement en charge un algorithme de tourniquet (round robin) pour distribuer les messages permettant à une application d’effectuer un scale-out. Un cas d’utilisation classique consiste à déployer plusieurs pods à l’aide de Kubernetes ReplicaSet qui s’abonnent tous à l’Agent MQTT en utilisant le même filtre de rubrique dans l’abonnement partagé.

Magasin d’état

Le magasin d’état est unetable de hachage répliquée en mémoire pour gérer l’état de traitement de l’application. Contrairement à etcd par exemple, le magasin d’état privilégie un haut débit, une mise à l’échelle horizontale et une faible latence par le biais de structures de données en mémoire, du partitionnement et de la réplication en chaîne. Cela permet aux applications d’utiliser la nature distribuée et la tolérance de panne du magasin d’état tout en accédant rapidement à un état cohérent entre les instances. Pour utiliser le magasin de clés-valeur intégré fourni par le répartiteur distribué :

  • Mettez en place des opérations de stockage et de récupération éphémères à l’aide de l’API de magasin de clés-valeur du répartiteur, ce qui garantit une gestion des erreurs appropriée et une cohérence des données. L’état éphémère est un stockage de données de courte durée utilisé dans le traitement avec conservation d'état pour un accès rapide aux résultats intermédiaires ou aux métadonnées pendant les calculs en temps réel. Dans le contexte de l’application à haute disponibilité (HA), un état éphémère permet de récupérer les états de l’application entre des incidents. Il peut être écrit sur un disque mais reste temporaire, par opposition au stockage à froid conçu pour le stockage à long terme des données rarement sollicitées.

  • Utilisez le magasin d’état pour le partage d’état, la mise en cache, la configuration ou d’autres données essentielles parmi plusieurs instances de l’application, ce qui leur permet de conserver une vue cohérente des données.

Utiliser l’intégration Dapr intégrée de l’Agent MQTT

Pour des cas d’usage plus simples, une application peut utiliser Dapr (Runtime d’application distribuée). Dapr est un runtime open source, portable et piloté par les événements, qui simplifie la création de microservices et d’applications distribuées. Il propose un ensemble de blocs de construction, tels que l’invocation de service à service, la gestion de l’état et la messagerie pub/sub (éditeurs/abonnés).

Dapr est offert dans le cadre de l’Agent MQTT et permet d’éliminer les détails de la gestion de session MQTT, de la qualité de service des messages, des accusés de réception, et des magasins de clés-valeurs intégrés, ce qui en fait un choix pratique pour développer une application hautement disponible dans des cas d’utilisation simples en :

  • Concevant votre application à l’aide des blocs de construction de Dapr, tels que le traitement de l’état pour gérer le magasin de clé-valeur, ou encore la messagerie pub/sub pour interagir avec le répartiteur MQTT. Si le cas d’utilisation nécessite des composantes et des abstractions qui ne sont pas prises en charge par Dapr, envisagez d’utiliser les fonctionnalités de l’Agent MQTT mentionnées précédemment.

  • Mettant en place l’application à l’aide de votre langage de programmation et de votre infrastructure préférés, en tirant parti des SDK ou API Dapr pour une intégration transparente avec le répartiteur et le magasin de clés-valeur.

Effectuant une vérification dans le but de développer une application hautement disponible

  • Choisissant une bibliothèque client MQTT adaptée à votre langage de programmation. Le client doit pouvoir prendre en charge MQTT v5. Utilisant une bibliothèque C ou Rust si votre application est sensible à la latence.
  • Configurez la bibliothèque de client pour vous connecter à l’Agent MQTT avec l’indicateurclean-session défini avec la valeur false et le niveau de qualité de service souhaité (QoS-1).
  • Déterminant une valeur appropriée pour l’expiration de la session, l’expiration du message et les intervalles de conservation.
  • Exécutant la logique de traitement des messages destinée à l’application abonnée, y compris l’envoi d’un accusé de réception lorsque le message a été remis ou traité.
  • Pour les applications multithreads, configurez le paramètre dede réception maximaleafin d’activer le traitement parallèle des messages.
  • Utilisant les messages conservés pour que l’état de l’application reste temporaire.
  • Utilisez le magasin d’état distribué pour gérer l’état d’application éphémère.
  • Évaluant Dapr pour développer votre application si votre cas d’usage est simple et ne nécessite pas de contrôle détaillé sur la connexion MQTT ou la gestion des messages.
  • Mettant en place des abonnements partagés pour distribuer uniformément des messages entre plusieurs instances de l’application, ce qui permet une mise à l’échelle efficace.

Contenu connexe