Un broker MQTT multi-tenant atiende a muchos clientes o equipos independientes desde una infraestructura compartida, manteniendo separados los mensajes, las identidades y el consumo de recursos de cada uno. Este artículo recorre los componentes de esa arquitectura (namespaces, credenciales y cuotas), los compromisos entre ellos y las preguntas que conviene hacer a un proveedor. Terminarás con un modelo mental que te servirá para diseñar tu propia plataforma o evaluar la de otro.
Qué significa multi-tenancy en un broker MQTT
En MQTT, cada cliente se conecta a un broker y publica o se suscribe a topics. Un broker básico tiene un único espacio de topics plano: cualquier cliente autorizado a suscribirse a # lo ve todo. Eso está bien para una sola aplicación, y se vuelve peligroso en cuanto dos clientes comparten el mismo servidor.
Un tenant es una unidad de aislamiento: un cliente, una unidad de negocio, un entorno como staging o una línea de producto. Multi-tenancy significa que el broker trata a cada tenant como si tuviera su propio broker privado, aunque las conexiones lleguen a los mismos procesos y máquinas. Para lograrlo, la arquitectura debe responder tres preguntas para cada conexión y cada mensaje:
- ¿A qué tenant pertenece este cliente? (identidad)
- ¿Qué topics puede ver y escribir este cliente? (namespace)
- ¿Cuánta capacidad compartida puede consumir este tenant? (recursos)
Si necesitas repasar los conceptos básicos, lee primero qué hace un broker MQTT.
Componente 1: namespaces por tenant
Prefijos de topic
El enfoque más sencillo es una convención: todos los topics de un tenant empiezan con un prefijo, como tenant-42/site-a/line-1/temperature. El broker, o una capa de autorización situada delante, debe garantizar entonces que un cliente del tenant 42 solo pueda usar topics bajo tenant-42/. Sin esa aplicación forzosa, un prefijo es solo una nomenclatura ordenada, no aislamiento.
Mountpoints y hosts virtuales
Algunos brokers admiten mountpoints o mecanismos similares: el broker antepone de forma transparente un prefijo específico del tenant a cada topic que usa un cliente. El cliente publica en sensors/temp y el broker lo almacena y enruta como tenant-42/sensors/temp. Los clientes ni siquiera pueden expresar un topic fuera de su namespace, y una suscripción a # solo coincide dentro del espacio del tenant. Esto es más robusto que una convención, porque no depende de que los clientes se comporten correctamente.
Brokers lógicos separados
El modelo lógico más fuerte da a cada tenant su propia identidad de instancia de broker, con sus propias credenciales, su propio almacén de sesiones y sus propios retained messages, aunque el clúster subyacente sea compartido. Una suscripción con comodín en un tenant nunca puede coincidir con un topic de otro, porque no comparten en absoluto el árbol de topics.
Componente 2: identidad y credenciales
El aislamiento empieza en el CONNECT. Un diseño robusto vincula cada credencial a exactamente un tenant y la verifica antes de aceptar cualquier operación sobre topics.
- Credenciales por tenant. Los usuarios y contraseñas, tokens o certificados de cliente se emiten por tenant, idealmente por dispositivo.
- Vinculación del client ID. Vincular el client ID a la credencial emitida impide que un dispositivo suplante a otro o secuestre la sesión ajena, ya que MQTT desconecta la conexión más antigua cuando se conecta un client ID duplicado.
- Protección contra fuerza bruta. La infraestructura compartida es un objetivo más atractivo. Limitar la tasa de intentos y bloquear direcciones tras inicios de sesión fallidos repetidos protege a todos los tenants a la vez.
- Rotación de secretos. Los tenants necesitan poder rotar credenciales sin pedir al operador que reinicie nada.
Componente 3: cuotas de recursos y vecinos ruidosos
El problema del vecino ruidoso es el riesgo clásico de la infraestructura compartida. Un fallo de firmware de un tenant que se reconecta en un bucle cerrado, o un script que publica tan rápido como puede, puede consumir CPU, memoria y ancho de banda que otros tenants necesitan. Las cuotas convierten ese riesgo en un problema acotado y por tenant.
| Recurso | Por qué limitarlo | Aplicación habitual |
|---|---|---|
| Conexiones simultáneas | Memoria y descriptores de archivo por conexión | Rechazar el CONNECT por encima del límite |
| Tasa de mensajes | Coste de CPU y de fan-out | Limitar o desconectar, con reason code de MQTT 5 |
| Tamaño máximo de mensaje | Picos de memoria, ancho de banda | Rechazar PUBLISH demasiado grandes |
| Suscripciones por cliente | Tamaño de la tabla de enrutamiento | Rechazar el SUBSCRIBE por encima del límite |
| Nivel de QoS | Estado en vuelo y reintentos | Degradar o rechazar |
| Expiración de sesión | Mensajes almacenados sin conexión | Limitar el intervalo de expiración |
| Retained messages | Almacenamiento | Límites de cantidad y tamaño |
MQTT 5 ayuda aquí porque el broker puede explicarse. El reason code 0x97 (Quota exceeded) indica a un cliente bien escrito que ha alcanzado un límite, en lugar de dejarle adivinar por qué se descartó una publicación. Para el lado del cliente, consulta las cuotas de conexión de un broker MQTT.
¿Clúster compartido o clúster dedicado?
La multi-tenancy es un espectro. En un extremo, todos los tenants comparten un clúster con aislamiento lógico. En el otro, cada tenant obtiene máquinas dedicadas. La tabla resume el compromiso.
| Aspecto | Clúster multi-tenant compartido | Clúster dedicado por tenant |
|---|---|---|
| Eficiencia de costes | Alta, la capacidad se agrupa | Menor, la capacidad se reserva |
| Aislamiento | Lógico (identidad, namespace, cuotas) | Físico |
| Exposición a vecinos ruidosos | Limitada por las cuotas | Ninguna por parte de otros tenants |
| Tiempo de aprovisionamiento | Segundos | Más largo |
| Límites personalizados | Según el plan | Dimensionados para el tenant |
| Uso típico | Prototipos, flotas pequeñas y medianas | Flotas grandes, requisitos estrictos |
La mayoría de los proveedores ofrecen ambos y permiten que un tenant pase de uno a otro a medida que crecen sus necesidades. La cuestión de fondo sobre con qué intensidad separar a los clientes se trata en aislamiento de tenants en MQTT.
Operar un broker multi-tenant
Diseñar el aislamiento es la mitad del trabajo. Operarlo es la otra mitad:
- Observabilidad por tenant. Las métricas necesitan una dimensión de tenant: conexiones, tasas de mensajes y rechazos por cuota por tenant, no solo totales del clúster.
- Actualizaciones justas. Los reinicios escalonados deben repartir la carga de reconexión, y los clientes deben usar un backoff aleatorio para que miles de dispositivos de muchos tenants no vuelvan en el mismo instante.
- Gestión de abusos. La protección contra inundaciones debe actuar sobre el tenant o cliente infractor, no sobre todo el clúster.
- Ciclo de vida del tenant. Crear, suspender y eliminar tenants debe limpiar por completo sesiones, retained messages y credenciales.
Cómo implementa ConnectMQ la multi-tenancy
ConnectMQ está construido como una plataforma multi-tenant. En los planes Serverless, muchos brokers comparten un clúster y cada broker está aislado de los demás: tiene su propio usuario, contraseña y client ID generados, los client IDs están vinculados a las credenciales emitidas y las cuotas de cada plan limitan las conexiones, el QoS y el tamaño de los mensajes. El plan Serverless gratuito permite hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB; el plan Serverless de pago lo eleva a hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas.
La protección contra inundaciones y el bloqueo de IP tras inicios de sesión fallidos repetidos protegen a todos los tenants del clúster compartido. Cuando un cliente supera sus límites, los clientes MQTT 5 reciben el reason code 0x97, de modo que la causa es visible. Si el aislamiento lógico no basta, el plan Dedicated te ofrece un clúster aislado, y BYOC ejecuta el broker en tu propia cuenta de nube mientras ConnectMQ sigue gestionándolo.
Prueba una estructura de topics por tenant
Incluso dentro de tu propio broker, una estructura de topics coherente hace que las aplicaciones multi-tenant sean más fáciles de razonar. Este ejemplo con MQTT.js publica en un topic con prefijo de tenant y sitio en el servidor MQTT público gratuito; recuerda que el área pública la puede leer cualquiera, así que úsalo solo para pruebas y nunca para datos de producción.
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));
En un broker privado de ConnectMQ, añade username: "YOUR_USERNAME" y password: "YOUR_PASSWORD" y usa YOUR_CLIENT_ID del portal.
Empieza con ConnectMQ
Ahórrate construir el aislamiento de tenants por tu cuenta. Crea un broker Serverless gratuito y aislado en app.connectmq.com, sin tarjeta de crédito, y escala a Dedicated o BYOC cuando necesites una separación más fuerte. Descubre más sobre el modelo de broker MQTT gestionado o consulta la guía completa de broker MQTT en la nube.
Preguntas frecuentes
¿Basta un prefijo de topic para separar tenants?
Solo si el broker lo hace cumplir. Un prefijo sin aplicación forzosa es una convención de nombres; un cliente que se suscriba a # seguiría viendo los mensajes de otros tenants.
¿Qué es el problema del vecino ruidoso en MQTT?
Ocurre cuando el tráfico intenso o defectuoso de un tenant consume recursos compartidos del broker y degrada el servicio para los demás. Las cuotas por tenant y la protección contra inundaciones limitan el daño.
¿Un broker multi-tenant afecta a mi código de cliente?
Normalmente no. Los clientes usan MQTT estándar; el límite del tenant lo definen las credenciales y el endpoint con los que te conectas.
¿Cuándo debo pasar de un broker compartido a uno dedicado?
Cuando necesites una capacidad predecible y no compartida, límites superiores a las cuotas de los planes compartidos o una política que exija aislamiento físico.
