Faire évoluer un broker MQTT : connexions et diffusion

Savoir faire évoluer un broker MQTT commence par savoir quel type de charge augmente réellement : les connexions, les messages entrants ou la diffusion sortante. Ce guide explique chaque dimension, compare montée en charge verticale et horizontale, détaille le calcul de diffusion nécessaire au dimensionnement et présente les habitudes côté client qui comptent souvent davantage que le broker lui-même.

Les trois dimensions de la charge MQTT

Un broker MQTT effectue trois types de travail différents, qui évoluent indépendamment.

Les connexions. Chaque client connecté occupe un socket TCP, une session TLS s'il est chiffré, un objet d'état de session et des minuteurs keepalive. La charge liée aux connexions concerne surtout la mémoire et les descripteurs de fichiers, et elle croît avec la taille de la flotte, même lorsque les appareils sont silencieux.

Les messages entrants. Chaque PUBLISH d'un client doit être analysé, autorisé, confronté aux abonnements et acquitté si la QoS est de 1 ou 2. La charge entrante croît avec la taille de la flotte multipliée par la fréquence de publication.

La diffusion sortante. Pour chaque message entrant, le broker livre une copie à chaque abonné correspondant. Une mesure de capteur consommée par un tableau de bord, un enregistreur en base de données et un service d'alerte devient trois messages sortants. La diffusion (fan-out) est la dimension que les équipes oublient le plus souvent, et c'est fréquemment la plus importante.

Un quatrième facteur, plus discret, est l'état des sessions : les sessions persistantes avec des messages QoS 1 en file pour des clients hors ligne consomment de la mémoire jusqu'au retour de ces clients ou à l'expiration de la session.

Le calcul de diffusion : estimer la charge réelle du broker

Nul besoin d'un benchmark pour raisonner sur la charge ; il suffit d'arithmétique. Les formules de base sont :

Débit entrant = appareils x messages par appareil et par seconde
Débit sortant = somme, pour chaque topic, de (débit entrant sur ce topic x abonnés correspondants)
Le travail total du broker correspond à peu près à l'entrant plus le sortant, avec un surcoût pour les acquittements QoS 1 et 2 et pour le TLS

Voici un petit calculateur que vous pouvez adapter à votre flotte. Les chiffres sont un exemple, pas une mesure.

# fanout.py - estimation grossière de la charge MQTT pour la planification de capacité
fleet = [
    # (name, devices, msgs_per_device_per_min, subscribers_per_message, avg_payload_bytes)
    ("env sensors",  400, 2,  2, 180),
    ("machines",      60, 60, 3, 600),
    ("status",       460, 0.1, 1, 20),
]

total_in = total_out = total_bytes = 0.0
for name, devices, per_min, subs, size in fleet:
    inbound = devices * per_min / 60
    outbound = inbound * subs
    total_in += inbound
    total_out += outbound
    total_bytes += (inbound + outbound) * size
    print(f"{name:12s} in={inbound:7.1f}/s out={outbound:7.1f}/s")

print(f"\nTOTAL inbound  {total_in:8.1f} msg/s")
print(f"TOTAL outbound {total_out:8.1f} msg/s")
print(f"Approx traffic {total_bytes/1024:8.1f} KB/s (payload only, no protocol/TLS overhead)")

Exécutez-le avec python fanout.py. Deux enseignements ressortent généralement. D'abord, une poignée de machines bavardes peut peser plus lourd que des centaines de capteurs lents. Ensuite, ajouter un abonné de plus à un topic à fort volume, comme un second service d'analyse, peut augmenter la charge sortante davantage que l'ajout de centaines d'appareils. Pour aller plus loin, lisez estimer les messages MQTT par seconde.

Montée en charge verticale ou horizontale

Il existe deux grandes façons de donner plus de capacité à un broker.

	Montée en charge verticale	Montée en charge horizontale
Comment	Machine plus puissante : plus de CPU, de mémoire, de réseau	Plus de nœuds de broker travaillant ensemble
Complexité	Faible ; configuration en grande partie inchangée	Plus élevée ; les nœuds doivent partager routage et état des sessions
Domaine de panne	Un nœud	Plusieurs nœuds, selon la conception
Limite typique	La plus grosse machine disponible	Surcoût de coordination entre nœuds
Adaptée à	La plupart des petites et moyennes flottes	Très grandes flottes ou objectifs de redondance stricts

La montée en charge verticale est sous-estimée. Un seul processus de broker bien réglé sur un matériel adapté absorbe un volume de trafic important, et la simplicité d'exploitation a de la valeur. Le réglage consiste généralement à relever les limites de descripteurs de fichiers, à dimensionner la mémoire pour les sessions et les messages en vol, et à décharger ou optimiser le TLS.

La montée en charge horizontale consiste à placer plusieurs nœuds de broker derrière un load balancer. La difficulté n'est pas d'ajouter des nœuds, mais de les garder cohérents : un message publié sur le nœud A doit atteindre un abonné connecté au nœud B, et un client qui se reconnecte à un autre nœud s'attend à y retrouver sa session. Chaque broker résout ce problème à sa manière, avec des compromis différents en latence et en cohérence.

Un troisième schéma est le partitionnement : exécuter des brokers distincts et indépendants pour des sites, des tenants ou des gammes de produits distincts. Il évite totalement la coordination entre nœuds, au prix de l'absence d'un espace de topics global unique. Pour de nombreux déploiements multisites et multiclients, le partitionnement est le moyen le plus simple de grandir.

Faire évoluer les consommateurs avec les abonnements partagés

Les consommateurs backend sont souvent le premier goulot d'étranglement. Un service Python unique abonné à acme/# doit traiter chaque message envoyé par la flotte. Lorsqu'il prend du retard, les messages s'accumulent sur le broker et la mémoire augmente.

Les abonnements partagés de MQTT 5 résolvent ce problème en permettant à plusieurs instances consommatrices de se répartir un même abonnement. Chaque message est remis à un seul membre du groupe plutôt qu'à tous. Les abonnements partagés sont disponibles sur l'offre ConnectMQ Serverless (Paid).

import os
import paho.mqtt.client as mqtt

GROUP = "writers"
FILTER = "acme/+/+/+/+/telemetry"

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"$share/{GROUP}/{FILTER}", qos=1)

def on_message(client, userdata, msg):
    # Écrivez ici dans votre base de données, file ou fichier.
    print(os.getpid(), msg.topic, len(msg.payload), "bytes")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883)
client.loop_forever()

Lancez une copie par instance consommatrice, chacune avec ses propres identifiants et son propre client ID. Ajouter une instance répartit davantage la charge sans toucher aux appareils.

Les habitudes côté client qui facilitent la montée en charge

Beaucoup de problèmes de montée en charge sont en réalité des problèmes de clients. Ces habitudes aident sur n'importe quel broker :

Publier sur changement, pas sur minuterie. Le report par exception réduit considérablement la charge entrante pour les valeurs qui évoluent lentement.
Regrouper les mesures. Envoyez dix échantillons dans un message plutôt que dix messages.
Choisir la QoS délibérément. QoS 0 pour la télémétrie haute fréquence où l'échantillon suivant remplace le précédent ; QoS 1 pour les événements et les commandes ; QoS 2 uniquement là où les doublons sont inacceptables. Voir les niveaux de QoS MQTT expliqués.
S'abonner de façon ciblée. Un tableau de bord qui affiche un seul site ne devrait pas s'abonner à #.
Définir des keepalives raisonnables. Des keepalives très courts multiplient le trafic PINGREQ sur une grande flotte.
Ajouter de la gigue aux reconnexions et aux publications périodiques. Des milliers d'appareils publiant exactement à la même seconde créent des pics inutiles.
Faire expirer ce dont vous n'avez pas besoin. L'expiration des sessions et des messages évite au broker de conserver l'état de clients qui ne reviendront jamais.
Utiliser les alias de topic pour les topics longs sur les liaisons contraintes. Les alias de topic de MQTT 5 remplacent les longues chaînes de topic répétées par un entier court.

Quand passer à une offre supérieure

Sur un broker MQTT managé, la montée en charge est surtout une décision d'offre. Avec ConnectMQ, l'échelle se présente ainsi :

Serverless (Free) : jusqu'à 25 connexions, QoS jusqu'à 1, messages de 256 Ko. Prototypes et petits pilotes.
Serverless (Paid) : jusqu'à 1 000 connexions, QoS 2, messages de 1 Mo, abonnements partagés. Flottes en croissance sur un cluster partagé.
Dedicated : un cluster isolé pour que votre charge ne partage pas ses ressources avec d'autres tenants.
BYOC : un broker qui tourne dans votre propre compte cloud et géré par ConnectMQ, utile lorsque vous voulez choisir et contrôler l'infrastructure.
Self Managed Enterprise : pour les organisations qui doivent exploiter le broker elles-mêmes.

Les signaux qui doivent vous inciter à monter en gamme : l'approche du plafond de connexions, le besoin d'abonnements partagés pour les consommateurs backend, ou la volonté d'être isolé du trafic des autres tenants. Échangez avec l'équipe sur vos connexions et débits de messages attendus afin qu'un déploiement Dedicated ou Enterprise soit dimensionné pour votre charge. Si vous comparez les modèles de façon générale, le guide sur le broker MQTT cloud les couvre tous, et la haute disponibilité d'un broker MQTT explique les questions de redondance à poser en parallèle de la capacité.

Les pièges de la montée en charge à éviter

Dimensionner sur des moyennes. Prévoyez les pics, comme les changements d'équipe, les tempêtes de reconnexions et les purges d'arriérés.
Ignorer les abonnés. Comptez la diffusion sortante, pas seulement les appareils.
Un consommateur géant sur un joker unique. Répartissez-le avec des abonnements partagés avant qu'il ne devienne un goulot d'étranglement.
Des retained messages volumineux partout. Chaque nouvel abonné les reçoit immédiatement, ce qui s'accumule sur des jokers larges.
Des tests de charge contre la production. Utilisez un broker ou une offre distincts pour les tests de charge afin de ne pas atteindre vos propres quotas. Le serveur MQTT public gratuit ne s'y prête pas davantage : ses limites par client le réservent aux tests fonctionnels et aux prototypes, sans données de production.

Faites évoluer votre flotte MQTT avec ConnectMQ

ConnectMQ vous permet de commencer petit et de gravir l'échelle des offres à mesure que vos connexions et votre diffusion augmentent, sans changer de protocole ni de conception de topics. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et montez en gamme lorsque vos chiffres l'exigent. Si vous voulez revoir ce que fait un broker MQTT avant de planifier, commencez par là.

Questions fréquentes

Qu'est-ce qui limite généralement en premier la montée en charge d'un broker MQTT ?

Cela dépend de la charge. Les grandes flottes peu bavardes atteignent d'abord les limites de connexions et de mémoire, tandis que les flottes actives avec plusieurs consommateurs par topic atteignent d'abord les limites de diffusion sortante.

La montée en charge horizontale est-elle toujours préférable à la verticale ?

Non. La montée en charge verticale est plus simple et suffit pour de nombreux déploiements. La montée en charge horizontale ajoute un surcoût de coordination et se justifie lorsqu'un seul nœud ne peut pas atteindre les objectifs de capacité ou de redondance.

Comment les abonnements partagés aident-ils à monter en charge ?

Ils permettent à plusieurs instances consommatrices de se répartir un abonnement, de sorte que chaque message est traité une seule fois par un membre du groupe. Cela supprime le goulot d'étranglement du consommateur unique sans modifier les appareils.

Quand passer de Serverless à Dedicated ?

Envisagez Dedicated lorsque vous avez besoin d'une isolation vis-à-vis des autres tenants ou que vous prévoyez une charge supérieure à ce que proposent les offres Serverless partagées. Communiquez vos connexions et débits de messages attendus pour que le déploiement soit correctement dimensionné.

Comment faire évoluer un broker MQTT : connexions, débit et diffusion