Un broker MQTT dédié fournit à un seul client un cluster de broker isolé au lieu d'une part d'un cluster mutualisé : les performances et la capacité sont réservées à votre seule flotte. Ce guide explique ce que l'isolation vous apporte, les signaux qui montrent que le palier serverless ne suffit plus, comment planifier la capacité avant de basculer, et propose une checklist pratique pour passer de ConnectMQ Serverless à Dedicated.
Qu'est-ce qu'un broker MQTT dédié ?
Sur un palier serverless, de nombreux clients partagent un même cluster et sont séparés logiquement par les identifiants, les espaces de noms de topics et les quotas. Un déploiement dédié supprime ce partage : le fournisseur exploite un cluster de broker qui ne sert que votre organisation. Vous ne gérez toujours ni serveurs, ni systèmes d'exploitation, ni certificats, car il s'agit toujours d'un broker MQTT managé, mais la puissance de calcul, la mémoire et le réseau derrière votre endpoint ne sont partagés avec personne.
Cette distinction compte moins qu'on ne le pense pour les petites flottes, et beaucoup plus qu'on ne le pense pour les flottes importantes ou sensibles à la latence. Si vous hésitez encore entre les modèles d'hébergement de manière générale, l'article pilier broker MQTT cloud décrit l'ensemble du paysage.
Ce que l'isolation vous apporte
Des performances prévisibles
Sur un cluster mutualisé, les quotas empêchent un client de monopoliser les ressources, mais votre trafic circule toujours à côté de celui des autres. Avec un broker MQTT dédié, un pic provenant d'une autre entreprise ne peut tout simplement pas vous affecter. La latence et le débit dépendent de votre propre charge, ce qui rend le comportement plus facile à comprendre et à tester.
Une marge de capacité que vous pouvez planifier
Les paliers mutualisés ont des quotas fixes par plan. Un cluster dédié est dimensionné pour votre charge attendue : vous planifiez votre marge délibérément au lieu de vous heurter à un plafond conçu pour le client moyen.
Un dossier sécurité et conformité plus simple
Certains audits de sécurité posent une question simple : le trafic d'un autre client touche-t-il le même processus de broker ? Avec un hébergement dédié, la réponse est non. Cela raccourcit souvent les discussions avec les achats, même lorsque le palier mutualisé était techniquement bien isolé.
Moins de contraintes de conception
Un large fan-out, de nombreux consommateurs backend sur des shared subscriptions, des payloads plus volumineux et des flux en QoS 2 sont tous plus faciles à absorber quand le cluster vous appartient.
Les signes que le serverless ne suffit plus
Surveillez ces signaux. Un seul n'est pas forcément une raison de migrer ; plusieurs à la fois le sont généralement.
| Signal | Ce que vous observez | Pourquoi c'est important |
|---|---|---|
| Plafond de connexions | Connexions refusées, reason code 0x97 | Les appareils ne peuvent pas se connecter |
| Débit de messages élevé et constant | Débit stable toute la journée | Vous payez une capacité mutualisée que vous utilisez en fait en permanence |
| Sensibilité à la latence | Boucles de contrôle, alarmes, interfaces opérateur | La variance pénalise plus que la moyenne |
| Exigences des achats | Questions sur l'infrastructure partagée | L'isolation simplifie la réponse |
| Plan de croissance de la flotte | Des milliers d'appareils dans la feuille de route | Mieux vaut migrer avant le rush |
| Nombreux consommateurs backend | Plusieurs services abonnés aux mêmes flux | Le fan-out multiplie la charge |
Le plan Serverless (Paid) de ConnectMQ prend en charge jusqu'à 1 000 connexions, la QoS 2, des messages de 1 Mo et les shared subscriptions, ce qui suffit largement pour de nombreux produits. Dedicated s'adresse à ceux qui veulent leur propre cluster isolé plutôt que des quotas plus élevés sur un cluster mutualisé.
Planifier la capacité d'un déploiement dédié
Une bonne planification de capacité part de vos appareils, pas des benchmarks de brokers. Passez en revue ces chiffres et notez-les ; c'est sur eux que portera la discussion de dimensionnement de votre cluster.
- Pic de connexions simultanées. Appareils, passerelles, services backend, tableaux de bord et outils de test comptent tous. Ajoutez le cas de la tempête de reconnexions : après une coupure réseau, tous les appareils se reconnectent dans un court intervalle.
- Messages entrants par seconde. Multipliez le nombre d'appareils par la fréquence de publication. 2 000 appareils à raison d'un message toutes les 10 secondes donnent 200 messages par seconde en moyenne, mais l'alignement (des appareils qui publient à la minute pile) crée des pics.
- Fan-out sortant. Chaque message publié est livré une fois par abonnement correspondant. Un message lu par un tableau de bord, un historian et un service d'alerte représente trois livraisons.
- Taille des payloads. Moyenne et maximale. Des payloads JSON compacts ou binaires réduisent la bande passante et la mémoire du broker.
- Répartition des QoS. Les QoS 1 et 2 ajoutent du trafic d'acquittement et de l'état en vol par rapport à la QoS 0. Voir les niveaux de QoS MQTT expliqués.
- État des sessions. Les sessions persistantes avec des messages en file d'attente pour les clients hors ligne consomment de la mémoire. Définissez une expiration de session pour que les sessions abandonnées ne s'accumulent pas.
- Retained messages. Un retained message par topic d'état ne coûte presque rien ; des millions de topics retained obsolètes, si.
- Croissance. Planifiez pour les 12 à 18 prochains mois de croissance de la flotte plutôt que pour le nombre actuel.
Une simple fiche de dimensionnement en texte brut aide à aligner l'équipe :
Peak devices online ............ 3,000
Backend/dashboard clients ...... 40
Reconnect storm window ......... 120 s
Avg publish interval ........... 15 s -> ~200 msg/s inbound
Avg subscribers per message .... 2 -> ~400 msg/s outbound
Avg payload .................... 350 bytes
QoS ............................ 1 (telemetry), 2 (commands)
Retained topics ................ ~3,000 (one status topic per device)
Session expiry ................. 1 hour
Growth target (18 months) ...... 3x
Mesurer avant de migrer
Avant de basculer, récupérez des chiffres réels depuis votre broker serverless. Un petit abonné Python qui compte les messages par topic de premier niveau vous donne rapidement une base de référence.
import collections
import ssl
import time
import paho.mqtt.client as mqtt
counts = collections.Counter()
start = time.time()
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("#", qos=0)
def on_message(client, userdata, msg):
counts[msg.topic.split("/")[0]] += 1
elapsed = time.time() - start
if elapsed >= 60:
for prefix, n in counts.most_common():
print(f"{prefix:20s} {n / elapsed:8.2f} msg/s")
counts.clear()
globals()["start"] = time.time()
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(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Combinez cela avec le tableau de bord du portail et le topic $SYS/broker/connection/{clientId}/state, qui indique si un client donné est connecté, pour comprendre à la fois le trafic et le comportement des connexions.
Checklist de migration : de Serverless à Dedicated
Comme un broker MQTT dédié parle le même protocole MQTT 3.1.1 et 5.0 sur les mêmes ports (1883, 8883, 8083 et 8084 avec /mqtt), la migration est essentiellement un exercice de configuration.
- Rendez l'endpoint configurable. Si le nom d'hôte, le port, le nom d'utilisateur, le mot de passe et le client ID sont compilés dans le firmware, corrigez cela en premier. Stockez-les dans la NVS, un fichier de configuration ou les données de provisionnement.
- Demandez et provisionnez le broker dédié. Récupérez de nouveaux identifiants depuis le portail pour l'environnement dédié.
- Migrez d'abord les consommateurs backend. Pointez une copie de chaque service backend vers le nouveau broker et vérifiez qu'il reçoit le trafic de test.
- Faites le pont pendant la transition avec votre propre outil. Si les appareils migrent sur plusieurs jours ou semaines, exécutez un petit relais (Node-RED ou un court script Python) qui s'abonne sur l'ancien broker et republie sur le nouveau. ConnectMQ ne fournit pas de bridges intégrés : cela se fait avec un client MQTT externe.
- Migrez les appareils par vagues. Mettez à jour un petit pourcentage, surveillez l'état des connexions et les journaux d'erreurs, puis poursuivez.
- Republiez l'état retained. Les retained messages ne migrent pas automatiquement ; faites publier leur statut courant par les appareils à la connexion.
- Retirez l'ancien broker. Quand l'ancien n'affiche plus aucune connexion d'appareil, arrêtez le relais et décommissionnez-le.
Pièges courants : oublier des tableaux de bord et des scripts qui pointent encore vers l'ancien nom d'hôte, des client ID codés en dur qui entrent en collision entre environnements, et un état retained manquant après la bascule. Notre guide des bonnes pratiques de sécurité MQTT mérite d'être lu en parallèle, car une migration est le moment idéal pour renouveler les identifiants.
Dedicated, BYOC ou Enterprise ?
Le dédié n'est pas la seule option isolée. Si votre organisation a besoin que le broker tourne dans son propre compte cloud, BYOC l'y déploie tandis que ConnectMQ le gère. Si vous devez tout exploiter vous-même, Self Managed Enterprise couvre ce cas. Le guide du broker MQTT pour l'entreprise compare ces modèles aux exigences typiques des grandes organisations.
Passez à un broker dédié avec ConnectMQ
La plupart des équipes valident d'abord leurs clients sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes, commencent avec le plan Serverless gratuit sur app.connectmq.com (sans carte bancaire), mesurent leur trafic réel, puis passent à un cluster Dedicated lorsque l'isolation et la marge de capacité deviennent prioritaires. ConnectMQ conserve les mêmes protocoles, ports et outils de portail d'un plan à l'autre : vos appareils, l'explorateur de topics, les tableaux de bord et les règles d'alerte continuent de fonctionner de la même façon après la bascule.
Questions fréquentes
Un broker MQTT dédié est-il plus rapide qu'un broker serverless ?
Pas nécessairement en moyenne, mais il est plus prévisible car aucun autre client ne partage le cluster. L'avantage se voit surtout sous charge soutenue et lors des pics.
Dois-je réécrire le firmware de mes appareils pour passer au dédié ?
Non, si les paramètres de connexion sont configurables. Le protocole et les ports restent identiques ; seuls le nom d'hôte et les identifiants changent.
Puis-je conserver un broker serverless après être passé au dédié ?
Oui. De nombreuses équipes gardent un broker serverless gratuit pour le développement et les tests, et font tourner la production sur le cluster dédié.
Un broker dédié inclut-il une réplication entre régions ?
Ne le supposez pas. Renseignez-vous sur le déploiement concerné, et concevez vos appareils pour qu'ils se reconnectent avec un backoff et republient leur état afin de se rétablir proprement après n'importe quel redémarrage du broker.
