Saber cómo escalar un broker MQTT empieza por saber qué tipo de carga está creciendo realmente: conexiones, mensajes entrantes o fan-out saliente. Esta guía explica cada dimensión, compara el escalado vertical y el horizontal, recorre el cálculo de fan-out que necesitas para dimensionar y muestra los hábitos del lado cliente que a menudo importan más que el propio broker.
Las tres dimensiones de la carga MQTT
Un broker MQTT realiza tres tipos de trabajo distintos, y cada uno escala de forma independiente.
Conexiones. Cada cliente conectado mantiene un socket TCP, una sesión TLS si va cifrado, un objeto de estado de sesión y temporizadores de keepalive. La carga de conexiones es sobre todo cuestión de memoria y descriptores de archivo, y crece con el tamaño de la flota aunque los dispositivos estén en silencio.
Mensajes entrantes. Cada PUBLISH de un cliente debe analizarse, autorizarse, compararse con las suscripciones y confirmarse si el QoS es 1 o 2. La carga entrante crece con el tamaño de la flota multiplicado por la frecuencia de publicación.
Fan-out saliente. Por cada mensaje entrante, el broker entrega una copia a cada suscriptor que coincida. Una lectura de sensor consumida por un dashboard, un proceso que escribe en base de datos y un servicio de alertas se convierte en tres mensajes salientes. El fan-out es la dimensión que los equipos olvidan con más frecuencia, y a menudo es la mayor.
Un cuarto factor, más discreto, es el estado de sesión: las sesiones persistentes con mensajes QoS 1 en cola para clientes desconectados consumen memoria hasta que esos clientes vuelven o la sesión caduca.
Cálculo de fan-out: cómo estimar la carga real del broker
No necesitas un benchmark para razonar sobre la carga; necesitas aritmética. Las fórmulas básicas son:
- Tasa entrante = dispositivos x mensajes por dispositivo por segundo
- Tasa saliente = suma sobre los topics de (tasa entrante en ese topic x suscriptores que coinciden)
- El trabajo total del broker es aproximadamente la suma de entrante y saliente, con un coste extra por los acuses de QoS 1 y 2 y por TLS
Aquí tienes una pequeña calculadora que puedes adaptar a tu flota. Las cifras son un ejemplo, no una medición.
# fanout.py - estimación aproximada de la carga MQTT para planificar capacidad
fleet = [
# (nombre, dispositivos, mensajes_por_dispositivo_por_minuto, suscriptores_por_mensaje, payload_medio_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)")
Ejecútala con python fanout.py. Normalmente saltan a la vista dos lecciones. Primera: un puñado de máquinas muy habladoras puede pesar más que cientos de sensores lentos. Segunda: añadir un suscriptor más a un topic de alto volumen, como un segundo servicio de analítica, puede aumentar la carga saliente más que añadir cientos de dispositivos. Para un análisis más detallado, lee cómo estimar los mensajes MQTT por segundo.
Escalado vertical frente a horizontal
Hay dos grandes formas de dar más capacidad a un broker.
| Escalado vertical | Escalado horizontal | |
|---|---|---|
| Cómo | Máquina más grande: más CPU, memoria y red | Más nodos de broker trabajando juntos |
| Complejidad | Baja; la configuración apenas cambia | Mayor; los nodos deben compartir el enrutamiento y el estado de sesión |
| Dominio de fallo | Un nodo | Varios nodos, según el diseño |
| Límite típico | La máquina más grande disponible | La sobrecarga de coordinación entre nodos |
| Indicado para | La mayoría de las flotas pequeñas y medianas | Flotas muy grandes u objetivos de redundancia estrictos |
El escalado vertical está infravalorado. Un único proceso de broker bien ajustado y con hardware adecuado maneja una gran cantidad de tráfico, y la sencillez operativa es valiosa. El ajuste suele consistir en aumentar los límites de descriptores de archivo, dimensionar la memoria para las sesiones y los mensajes en tránsito, y descargar u optimizar TLS.
El escalado horizontal implica varios nodos de broker detrás de un balanceador de carga. Lo difícil no es añadir nodos, sino mantenerlos coherentes: un mensaje publicado en el nodo A debe llegar a un suscriptor conectado al nodo B, y un cliente que se reconecta a otro nodo espera encontrar su sesión. Cada producto de broker resuelve esto de una manera distinta, con distintos compromisos entre latencia y consistencia.
Un tercer patrón es el particionado: ejecutar brokers separados e independientes para distintas plantas, inquilinos o líneas de producto. Evita por completo la coordinación entre nodos, a costa de no tener un único espacio global de topics. En muchos despliegues con varias plantas o varios clientes, el particionado es la forma más sencilla de crecer.
Escalar el lado consumidor con suscripciones compartidas
Los consumidores backend suelen ser el primer cuello de botella. Un único servicio en Python suscrito a acme/# debe procesar cada mensaje que envía la flota. Cuando se queda atrás, los mensajes se acumulan en el broker y la memoria crece.
Las suscripciones compartidas de MQTT 5 lo resuelven permitiendo que varias instancias consumidoras se repartan una suscripción. Cada mensaje va a un miembro del grupo en lugar de a todos. Las suscripciones compartidas están disponibles en el plan Serverless (Paid) de ConnectMQ.
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):
# Escribe aquí en tu base de datos, cola o archivo.
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()
Ejecuta una copia por instancia consumidora, cada una con sus propias credenciales y su propio client ID. Añadir una instancia reparte aún más la carga sin tocar los dispositivos.
Hábitos del lado cliente que escalan
Muchos problemas de escalado son en realidad problemas de los clientes. Estos hábitos ayudan con cualquier broker:
- Publica al cambiar, no por temporizador. Informar por excepción reduce drásticamente la carga entrante para valores que cambian despacio.
- Agrupa las lecturas. Envía diez muestras en un mensaje en lugar de diez mensajes.
- Usa el QoS de forma deliberada. QoS 0 para telemetría de alta frecuencia en la que la siguiente muestra sustituye a la anterior; QoS 1 para eventos y comandos; QoS 2 solo cuando los duplicados sean inaceptables. Consulta niveles de QoS de MQTT explicados.
- Suscríbete de forma acotada. Un dashboard que muestra una planta no debería suscribirse a
#. - Configura keepalives razonables. Los keepalives muy cortos multiplican el tráfico de PINGREQ en una flota grande.
- Añade jitter a las reconexiones y a las publicaciones periódicas. Miles de dispositivos publicando exactamente en el mismo segundo crean picos innecesarios.
- Haz caducar lo que no necesites. La caducidad de sesión y la de mensajes evitan que el broker mantenga estado para clientes que nunca volverán.
- Usa topic aliases para topics largos en enlaces limitados. Los topic aliases de MQTT 5 sustituyen cadenas de topic largas y repetidas por un entero corto.
Cuándo pasar a un plan mayor
En un broker MQTT gestionado, escalar es sobre todo una decisión de plan. Con ConnectMQ la escalera es así:
- Serverless (Free): hasta 25 conexiones, QoS hasta 1, mensajes de 256 KB. Prototipos y pilotos pequeños.
- Serverless (Paid): hasta 1.000 conexiones, QoS 2, mensajes de 1 MB, suscripciones compartidas. Flotas en crecimiento sobre un clúster compartido.
- Dedicated: un clúster aislado para que tu carga de trabajo no comparta recursos con otros inquilinos.
- BYOC: un broker que se ejecuta en tu propia cuenta cloud, gestionado por ConnectMQ, útil cuando quieres elegir y controlar la infraestructura.
- Self Managed Enterprise: para organizaciones que necesitan operar el broker por sí mismas.
Las señales de que debes subir de plan incluyen acercarte al techo de conexiones, necesitar suscripciones compartidas para los consumidores backend o querer aislamiento respecto al tráfico de otros inquilinos. Habla con el equipo sobre las conexiones y tasas de mensajes previstas para que un despliegue Dedicated o Enterprise se dimensione según tu carga de trabajo. Si estás comparando modelos en general, la guía del broker MQTT en la nube cubre cada uno, y alta disponibilidad de un broker MQTT explica las preguntas de redundancia que conviene hacer junto a las de capacidad.
Errores de escalado que debes evitar
- Dimensionar con medias. Planifica para los picos, como cambios de turno, tormentas de reconexión y vaciados de backlog.
- Ignorar a los suscriptores. Cuenta el fan-out saliente, no solo los dispositivos.
- Un único consumidor gigante con comodín. Divídelo con suscripciones compartidas antes de que se convierta en un cuello de botella.
- Mensajes retenidos grandes por todas partes. Cada nuevo suscriptor los recibe de inmediato, lo que suma mucho con comodines amplios.
- Hacer pruebas de carga contra producción. Usa un broker o un plan separado para las pruebas de carga y así no chocarás con tus propias cuotas.
Escala tu flota MQTT con ConnectMQ
ConnectMQ te permite empezar con poco e ir subiendo de plan a medida que crecen tus conexiones y tu fan-out, sin cambiar de protocolos ni de diseño de topics. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y amplía cuando tus cifras indiquen que ha llegado el momento. Si quieres repasar qué hace un broker MQTT antes de planificar, empieza por ahí.
Preguntas frecuentes
¿Qué suele limitar primero el escalado de un broker MQTT?
Depende de la carga de trabajo. Las flotas grandes y silenciosas chocan primero con los límites de conexiones y memoria, mientras que las flotas activas con varios consumidores por topic chocan primero con los límites de fan-out saliente.
¿Es siempre mejor el escalado horizontal que el vertical?
No. El escalado vertical es más sencillo y basta para muchos despliegues. El escalado horizontal añade sobrecarga de coordinación y merece la pena cuando un solo nodo no puede cumplir los objetivos de capacidad o redundancia.
¿Cómo ayudan las suscripciones compartidas a escalar?
Permiten que varias instancias consumidoras se repartan una suscripción, de modo que cada mensaje lo procesa una sola vez un miembro del grupo. Eso elimina el cuello de botella del consumidor único sin cambiar los dispositivos.
¿Cuándo debo pasar de Serverless a Dedicated?
Plantéate Dedicated cuando necesites aislamiento respecto a otros inquilinos o prevés una carga superior a la que ofrecen los planes Serverless compartidos. Comparte tus conexiones y tasas de mensajes previstas para que el despliegue se dimensione correctamente.
