Un broker MQTT multi-tenant sert de nombreux clients ou équipes indépendants à partir d'une infrastructure partagée, tout en gardant séparés les messages, les identités et la consommation de ressources de chacun. Cet article passe en revue les briques de cette architecture (espaces de noms, identifiants et quotas), les compromis entre elles et les questions à poser à un fournisseur. Vous en ressortirez avec un modèle mental utilisable pour concevoir votre propre plateforme ou évaluer celle d'un autre.
Ce que signifie la multi-tenancy pour un broker MQTT
En MQTT, chaque client se connecte à un broker et publie sur des topics ou s'y abonne. Un broker classique possède un seul espace de topics à plat : tout client autorisé à s'abonner à # voit tout. C'est acceptable pour une application unique, et dangereux dès que deux clients partagent le même serveur.
Un tenant est une unité d'isolation : un client, une business unit, un environnement comme la préproduction ou une gamme de produits. La multi-tenancy signifie que le broker traite chaque tenant comme s'il disposait de son propre broker privé, même si les connexions aboutissent sur les mêmes processus et les mêmes machines. Pour y parvenir, l'architecture doit répondre à trois questions pour chaque connexion et chaque message :
- À quel tenant appartient ce client ? (identité)
- Quels topics ce client peut-il voir et écrire ? (espace de noms)
- Quelle part de la capacité partagée ce tenant peut-il consommer ? (ressources)
Si vous avez besoin d'un rappel sur les brokers en général, lisez d'abord le rôle d'un broker MQTT.
Brique 1 : les espaces de noms des tenants
Préfixes de topics
L'approche la plus simple est une convention : tous les topics d'un tenant commencent par un préfixe, comme tenant-42/site-a/line-1/temperature. Le broker, ou une couche d'autorisation placée devant lui, doit alors garantir qu'un client du tenant 42 ne peut utiliser que des topics sous tenant-42/. Sans contrôle, un préfixe n'est qu'un nommage soigné, pas une isolation.
Mountpoints et hôtes virtuels
Certains brokers prennent en charge les mountpoints ou des mécanismes similaires : le broker ajoute discrètement un préfixe propre au tenant devant chaque topic utilisé par un client. Le client publie sur sensors/temp, et le broker le stocke et le route sous tenant-42/sensors/temp. Les clients ne peuvent même pas exprimer un topic hors de leur espace de noms, et un abonnement à # ne correspond qu'à l'intérieur de l'espace du tenant. C'est plus robuste qu'une convention, car cela ne dépend pas du bon comportement des clients.
Brokers logiques séparés
Le modèle logique le plus fort donne à chaque tenant sa propre identité d'instance de broker, avec ses propres identifiants, son propre stockage de sessions et ses propres retained messages, même si le cluster sous-jacent est partagé. Un abonnement wildcard dans un tenant ne peut jamais correspondre à un topic d'un autre, car ils ne partagent tout simplement pas d'arborescence de topics.
Brique 2 : identité et identifiants
L'isolation commence au CONNECT. Une conception robuste rattache chaque identifiant à exactement un tenant et le vérifie avant d'accepter la moindre opération sur un topic.
- Des identifiants par tenant. Noms d'utilisateur et mots de passe, jetons ou certificats clients sont délivrés par tenant, idéalement par appareil.
- Liaison du client ID. Lier le client ID à l'identifiant délivré empêche un appareil d'en usurper un autre et de détourner la session de quelqu'un d'autre, puisque MQTT déconnecte l'ancienne connexion lorsqu'un client ID en double se connecte.
- Protection contre la force brute. Une infrastructure partagée est une cible plus grande. Limiter le débit et bloquer les adresses après des échecs de connexion répétés protège tous les tenants à la fois.
- Rotation des secrets. Les tenants ont besoin d'un moyen de renouveler leurs identifiants sans demander à l'exploitant de redémarrer quoi que ce soit.
Brique 3 : quotas de ressources et voisins bruyants
Le problème du voisin bruyant est le risque classique d'une infrastructure partagée. Un bug de firmware chez un tenant qui se reconnecte en boucle serrée, ou un script qui publie aussi vite que possible, peut consommer le CPU, la mémoire et la bande passante dont les autres tenants ont besoin. Les quotas transforment ce risque en un problème borné, propre à chaque tenant.
| Ressource | Pourquoi la limiter | Mise en œuvre typique |
|---|---|---|
| Connexions simultanées | Mémoire et descripteurs de fichiers par connexion | Rejeter le CONNECT au-delà de la limite |
| Débit de messages | Coût CPU et de diffusion | Ralentir ou déconnecter, reason code MQTT 5 |
| Taille maximale des messages | Pics de mémoire, bande passante | Rejeter les PUBLISH trop volumineux |
| Abonnements par client | Taille de la table de routage | Rejeter le SUBSCRIBE au-delà de la limite |
| Niveau de QoS | État des messages en vol et renvois | Rétrograder ou rejeter |
| Expiration de session | Messages stockés hors ligne | Plafonner l'intervalle d'expiration |
| Retained messages | Stockage | Limites de nombre et de taille |
MQTT 5 aide ici, car le broker peut s'expliquer. Le reason code 0x97 (Quota exceeded) indique à un client bien écrit qu'il a atteint une limite, au lieu de le laisser deviner pourquoi une publication a été abandonnée. Pour le côté client des limites, voir les quotas de connexion d'un broker MQTT.
Cluster mutualisé ou cluster dédié ?
La multi-tenancy est un continuum. À une extrémité, tous les tenants partagent un cluster avec une isolation logique. À l'autre, chaque tenant dispose de machines dédiées. Le tableau résume le compromis.
| Aspect | Cluster multi-tenant mutualisé | Cluster dédié par tenant |
|---|---|---|
| Efficacité économique | Élevée, la capacité est mutualisée | Plus faible, la capacité est réservée |
| Isolation | Logique (identité, espace de noms, quotas) | Physique |
| Exposition aux voisins bruyants | Limitée par les quotas | Aucune vis-à-vis des autres tenants |
| Délai de mise à disposition | Quelques secondes | Plus long |
| Limites personnalisées | Selon le plan | Dimensionnées pour le tenant |
| Usage typique | Prototypes, flottes petites et moyennes | Grandes flottes, exigences strictes |
La plupart des fournisseurs proposent les deux et permettent à un tenant de passer de l'un à l'autre à mesure que ses besoins grandissent. La question plus profonde du niveau de séparation entre clients est traitée dans l'isolation des tenants MQTT.
Exploiter un broker multi-tenant
Concevoir l'isolation représente la moitié du travail. L'exploiter représente l'autre moitié :
- Observabilité par tenant. Les métriques ont besoin d'une dimension tenant : connexions, débits de messages et rejets pour quota par tenant, et pas seulement des totaux du cluster.
- Des mises à jour équitables. Les redémarrages progressifs doivent étaler la charge de reconnexion, et les clients doivent utiliser un délai de reconnexion aléatoire pour que des milliers d'appareils de nombreux tenants ne reviennent pas au même instant.
- Gestion des abus. La protection contre l'inondation de messages doit agir sur le tenant ou le client fautif, pas sur l'ensemble du cluster.
- Cycle de vie des tenants. La création, la suspension et la suppression des tenants doivent nettoyer complètement les sessions, les retained messages et les identifiants.
Comment ConnectMQ met en œuvre la multi-tenancy
ConnectMQ est conçu comme une plateforme multi-tenant. Sur les plans Serverless, de nombreux brokers partagent un cluster, et chaque broker est isolé des autres : il dispose de ses propres nom d'utilisateur, mot de passe et client ID générés, les client ID sont liés aux identifiants délivrés, et des quotas par plan plafonnent les connexions, la QoS et la taille des messages. Le plan Serverless gratuit autorise jusqu'à 25 connexions, QoS jusqu'à 1 et des messages de 256 Ko ; le plan Serverless payant porte cela à 1 000 connexions, QoS 2, messages de 1 Mo et abonnements partagés.
La protection contre l'inondation de messages et le blocage d'IP après des échecs de connexion répétés protègent chaque tenant du cluster mutualisé. Lorsqu'un client dépasse ses limites, les clients MQTT 5 reçoivent le reason code 0x97, ce qui rend la cause visible. Si l'isolation logique ne suffit pas, le plan Dedicated vous offre un cluster isolé, et BYOC fait tourner le broker dans votre propre compte cloud tout en restant un broker MQTT managé par ConnectMQ.
Essayez une organisation de topics par tenant
Même au sein de votre propre broker, une organisation de topics cohérente rend les applications multi-tenant plus faciles à appréhender. Cet exemple MQTT.js publie sur un topic préfixé par tenant et par site sur le serveur MQTT public gratuit ; rappelez-vous que l'espace public est lisible par tous et réservé aux tests et aux prototypes, jamais aux données de production.
const mqtt = require("mqtt");
const tenant = "tenant-demo-91b2";
const base = `connectmq/demo/${tenant}`;
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
clientId: `${tenant}-gw-01`,
protocolVersion: 5,
});
client.on("connect", () => {
client.subscribe(`${base}/+/+/temperature`, { qos: 1 });
setInterval(() => {
const payload = JSON.stringify({ value: 20 + Math.random() * 5, ts: Date.now() });
client.publish(`${base}/site-a/line-1/temperature`, payload, { qos: 1 });
}, 5000);
});
client.on("message", (topic, message) => console.log(topic, message.toString()));
client.on("error", (err) => console.error("MQTT error:", err.message));
Sur un broker ConnectMQ privé, ajoutez username: "YOUR_USERNAME" et password: "YOUR_PASSWORD", et utilisez le YOUR_CLIENT_ID fourni par le portail.
Démarrez avec ConnectMQ
Ne construisez pas vous-même l'isolation des tenants. Créez un broker Serverless gratuit et isolé sur app.connectmq.com, sans carte bancaire, et passez à Dedicated ou BYOC lorsque vous avez besoin d'une séparation plus forte. Découvrez le modèle du broker MQTT managé, ou consultez le guide complet du broker MQTT cloud.
Questions fréquentes
Un préfixe de topic suffit-il à séparer les tenants ?
Seulement si le broker l'impose. Un préfixe sans contrôle n'est qu'une convention de nommage ; un client abonné à # verrait toujours les messages des autres tenants.
Qu'est-ce que le problème du voisin bruyant en MQTT ?
Il survient lorsque le trafic intense ou défaillant d'un tenant consomme les ressources partagées du broker et dégrade le service des autres. Les quotas par tenant et la protection contre l'inondation de messages limitent les dégâts.
Un broker multi-tenant a-t-il un impact sur mon code client ?
En général, non. Les clients utilisent du MQTT standard ; la frontière du tenant est définie par les identifiants et l'endpoint avec lesquels vous vous connectez.
Quand passer d'un broker mutualisé à un broker dédié ?
Passez-y lorsque vous avez besoin d'une capacité prévisible et non partagée, de limites supérieures aux quotas des plans mutualisés, ou lorsqu'une politique impose une isolation physique.
