Checklist de migration HiveMQ : évaluer la charge, planifier les identifiants et tester un broker privé

Quitter HiveMQ Cloud Serverless se passe sans encombre lorsque trois choses sont faites avant de toucher au moindre appareil : vous connaissez votre charge, vous avez planifié vos nouveaux identifiants et vous avez testé un broker privé avec votre trafic réel. Cette checklist transforme ces trois étapes en points concrets à cocher. Elle fonctionne quel que soit le broker de destination ; lorsque c'est utile, nous montrons à quoi correspond chaque point chez ConnectMQ.

HiveMQ met fin à Serverless le 31 décembre 2026. Pour le contexte, lisez Fin de vie de HiveMQ Cloud Serverless.

Partie 1 : évaluer votre charge

Votre charge détermine le plan dont vous avez besoin et la durée de la migration.

Connexions

• Pic de connexions simultanées sur le cluster HiveMQ (consultez la console pendant votre heure la plus chargée).
• Croissance attendue sur les 12 à 18 prochains mois.
• Nombre de connexions correspondant à des applications ou des tableaux de bord plutôt qu'à des appareils.
• Clients qui ouvrent plusieurs connexions (par exemple une passerelle par site, ou un backend avec plusieurs workers).

Messages

• Débit de messages moyen et maximal.
• Taille du plus gros payload, y compris pour les formats binaires comme Sparkplug B.
• Niveaux de QoS utilisés ; notez tous les flux en QoS 2.
• Topics qui utilisent le flag retain, et importance de l'état retenu au démarrage.
• Clients qui utilisent des sessions persistantes et attendent des messages mis en file pendant qu'ils sont hors ligne.

Topologie

• Liste complète des préfixes de topics et de qui publie ou s'abonne sur chacun.
• Abonnements avec wildcards utilisés par les backends.
• Abonnements partagés utilisés pour la répartition de charge.
• Partenaires ou clients qui se connectent à votre cluster.

Comment dimensionner le nouveau plan

Dimensionnez toujours sur le pic, plus une marge. Un plan calibré sur la moyenne refusera des connexions lors de la tempête de reconnexions qui suit une panne réseau.

Partie 2 : planifier vos nouveaux identifiants

L'URL de votre cluster HiveMQ et vos identifiants ne peuvent pas être déplacés : chaque client en reçoit donc de nouveaux. Définissez le schéma une fois pour toutes plutôt que d'improviser appareil par appareil.

• Listez chaque identifiant HiveMQ et ce qui l'utilise.
• Associez les identifiants aux brokers. Sur ConnectMQ, chaque broker délivre un nom d'utilisateur, un mot de passe et un client ID. Regroupez sous un même broker les clients qui appartiennent au même périmètre de confiance.
• Concevez les client IDs. ConnectMQ lie le client ID aux identifiants ; les clients peuvent utiliser l'ID délivré ou y ajouter un suffixe, comme YOUR_CLIENT_ID_line1-plc. Dérivez les suffixes d'un identifiant matériel unique pour que deux appareils n'entrent jamais en collision. Voir bonnes pratiques pour le client ID MQTT.
• Séparez les périmètres de confiance. Si vous utilisiez les permissions de topics de HiveMQ pour isoler des clients ou des partenaires les uns des autres, donnez à chacun son propre broker plutôt qu'un identifiant partagé.
• Stockez correctement les secrets. Conservez les identifiants dans un gestionnaire de secrets et, sur les appareils, dans un stockage protégé, jamais dans le contrôle de source. Voir sécuriser les identifiants MQTT sur les appareils.
• Planifiez la rotation. Décidez comment vous ferez tourner les identifiants plus tard sans nouvelle migration. Voir rotation des identifiants MQTT.
• Rendez les endpoints configurables. Le nom d'hôte, le port, les identifiants et le client ID doivent pouvoir être modifiés à distance, pour que ce soit la dernière fois qu'un changement de broker exige une modification du firmware.

Partie 3 : tester un broker managé privé

Ne laissez jamais le premier appareil de production servir de premier test. Créez un broker privé, par exemple un broker gratuit sur app.connectmq.com, et déroulez ces tests.

Connectivité

• Connectez-vous en TLS sur le port 8883 depuis chaque type de réseau utilisé par vos appareils.
• Connectez-vous en WebSocket sécurisé sur le port 8084 (chemin /mqtt) depuis votre tableau de bord web.
• Vérifiez que les appareils font confiance au certificat du broker. ConnectMQ utilise Let's Encrypt ; la racine ISRG Root X1 doit figurer dans le magasin de confiance. Voir configuration TLS de MQTT.

Comportement

• Publiez et abonnez-vous avec votre vraie structure de topics et vos vrais payloads.
• Testez chaque niveau de QoS que vous utilisez.
• Publiez un message retenu et vérifiez qu'un nouvel abonné le reçoit.
• Définissez un message Last Will et tuez le client pour vérifier qu'il est bien délivré.
• Reconnectez-vous avec une session persistante et vérifiez que les messages en file arrivent.
• Envoyez votre plus gros payload.

Performances et limites

• Mesurez la latence aller-retour depuis les emplacements des appareils, pas seulement depuis le bureau.
• Reconnectez un lot de clients de test en même temps pour simuler la reprise après une panne.
• Vérifiez le comportement de vos clients lorsqu'une limite est atteinte ; les clients MQTT 5 reçoivent le reason code 0x97 en cas de quota dépassé.
• Suivez le test dans l'explorateur de topics en direct et le tableau de bord.

Un test de latence rapide avec MQTT.js :

// npm install mqtt
const mqtt = require("mqtt");
const topic = "migration-test/rtt";
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `${process.env.MQTT_CLIENT_ID}_rtt`,
  protocolVersion: 5,
});

let sentAt = 0, n = 0;
client.on("connect", () => client.subscribe(topic, { qos: 1 }, send));
function send() { sentAt = Date.now(); client.publish(topic, String(n), { qos: 1 }); }
client.on("message", () => {
  console.log(`round trip ${n}: ${Date.now() - sentAt} ms`);
  if (++n < 20) setTimeout(send, 250); else client.end();
});

Partie 4 : go / no-go avant la première vague

• Inventaire terminé et responsables identifiés pour chaque type de client.
• Plan choisi et dimensionné sur le pic, plus une marge.
• Schéma des identifiants et des client IDs documenté.
• Tous les tests de la partie 3 réussis.
• État retenu exporté ou republié par les clients à la connexion. Voir suppression des données HiveMQ Serverless.
• Relais pour le fonctionnement en parallèle testé. Voir migration HiveMQ sans interruption.
• Plan de retour arrière : comment une vague revient sur HiveMQ en cas d'échec, tant que l'ancien cluster fonctionne encore.
• Date cible de la dernière vague, plusieurs semaines avant le 31 décembre 2026.

Une fois toutes les cases cochées, suivez le guide de migration HiveMQ Serverless pour la migration proprement dite.

Questions fréquentes

Comment connaître mon pic de connexions sur HiveMQ Serverless ?

Consultez les informations de connexion dans la console HiveMQ Cloud pendant votre période la plus chargée, et recoupez-les avec votre propre inventaire d'appareils. En cas de doute, dimensionnez le nouveau plan généreusement.

Faut-il un identifiant par appareil ?

Pas nécessairement. Sur ConnectMQ, de nombreux appareils peuvent partager un même jeu d'identifiants grâce à des suffixes de client ID uniques. Utilisez des brokers ou des identifiants distincts lorsque des appareils ou des utilisateurs appartiennent à des périmètres de confiance différents.

Puis-je tester ConnectMQ avant de payer ?

Oui. Le plan Serverless (Free) ne demande pas de carte bancaire et prend en charge jusqu'à 25 connexions, ce qui suffit pour exécuter tous les tests de cette checklist.

Et si un test échoue ?

Corrigez le problème avant de migrer les clients de production. La plupart des échecs viennent des magasins de confiance TLS, des règles de client ID ou des limites du plan, et les trois sont plus faciles à corriger tant que l'ancien cluster fonctionne encore.