Um broker MQTT multi-tenant atende muitos clientes ou equipes independentes a partir de uma infraestrutura compartilhada, mantendo separados as mensagens, as identidades e o uso de recursos de cada um. Este artigo percorre os blocos de construção dessa arquitetura, namespaces, credenciais e cotas, os trade-offs entre eles e as perguntas a fazer a um provedor. Ao final, você terá um modelo mental para projetar a sua própria plataforma ou avaliar a de outra empresa.
O Que Multi-Tenancy Significa para um Broker MQTT
No MQTT, todo cliente se conecta a um broker e publica ou assina topics. Um broker simples tem um único espaço de topics plano: qualquer cliente com permissão para assinar # vê tudo. Isso funciona para uma única aplicação e se torna perigoso no momento em que dois clientes compartilham o mesmo servidor.
Um tenant é uma unidade de isolamento: um cliente, uma unidade de negócio (como cada fazenda de uma cooperativa agrícola ou cada usina de um grupo de energia), um ambiente como staging ou uma linha de produtos. Multi-tenancy significa que o broker trata cada tenant como se ele tivesse o seu próprio broker privado, mesmo que as conexões caiam nos mesmos processos e máquinas. Para chegar lá, a arquitetura precisa responder três perguntas para cada conexão e cada mensagem:
- A qual tenant este cliente pertence? (identidade)
- Quais topics este cliente pode ver e escrever? (namespace)
- Quanto da capacidade compartilhada este tenant pode consumir? (recursos)
Se precisar relembrar os conceitos de brokers em geral, leia primeiro sobre o que um broker MQTT faz.
Bloco de Construção 1: Namespaces de Tenants
Prefixos de Topic
A abordagem mais simples é uma convenção: todos os topics de um tenant começam com um prefixo, como tenant-42/site-a/line-1/temperature. O broker, ou uma camada de autorização à frente dele, precisa então garantir que um cliente do tenant 42 só use topics sob tenant-42/. Sem essa imposição, um prefixo é só uma nomenclatura organizada, não isolamento.
Mountpoints e Virtual Hosts
Alguns brokers suportam mountpoints ou mecanismos semelhantes: o broker adiciona silenciosamente um prefixo específico do tenant a cada topic que o cliente usa. O cliente publica em sensors/temp, e o broker armazena e roteia como tenant-42/sensors/temp. Os clientes nem conseguem expressar um topic fora do seu namespace, e uma assinatura em # só corresponde a topics dentro do espaço do tenant. Isso é mais forte que uma convenção, porque não depende do comportamento correto do cliente.
Brokers Lógicos Separados
O modelo lógico mais forte dá a cada tenant a sua própria identidade de instância de broker, com credenciais próprias, armazenamento de sessões próprio e retained messages próprias, mesmo que o cluster subjacente seja compartilhado. Uma assinatura com wildcard em um tenant nunca pode corresponder a um topic de outro, porque eles simplesmente não compartilham uma árvore de topics.
Bloco de Construção 2: Identidade e Credenciais
O isolamento começa no CONNECT. Um design robusto vincula cada credencial a exatamente um tenant e a verifica antes de aceitar qualquer operação em topics.
- Credenciais por tenant. Usuários e senhas, tokens ou certificados de cliente são emitidos por tenant e, idealmente, por dispositivo.
- Vinculação do client ID. Vincular o client ID à credencial emitida impede que um dispositivo se passe por outro e que sequestre a sessão de alguém, já que o MQTT desconecta a conexão mais antiga quando um client ID duplicado se conecta.
- Proteção contra força bruta. Uma infraestrutura compartilhada é um alvo maior. Limitar a taxa e bloquear endereços após repetidas falhas de login protege todos os tenants de uma vez.
- Rotação de segredos. Os tenants precisam de uma forma de rotacionar credenciais sem pedir ao operador que reinicie nada.
Bloco de Construção 3: Cotas de Recursos e Vizinhos Barulhentos
O problema do vizinho barulhento (noisy neighbor) é o risco clássico da infraestrutura compartilhada. Um bug de firmware de um tenant que reconecta em loop, ou um script que publica o mais rápido possível, pode consumir CPU, memória e banda de que outros tenants precisam. As cotas transformam esse risco em um problema limitado e restrito a cada tenant.
| Recurso | Por que limitar | Imposição típica |
|---|---|---|
| Conexões simultâneas | Memória e descritores de arquivo por conexão | Rejeitar CONNECT acima do limite |
| Taxa de mensagens | Custo de CPU e de fan-out | Limitar ou desconectar, com reason code do MQTT 5 |
| Tamanho máximo de mensagem | Picos de memória, banda | Rejeitar PUBLISH acima do tamanho |
| Assinaturas por cliente | Tamanho da tabela de roteamento | Rejeitar SUBSCRIBE acima do limite |
| Nível de QoS | Estado inflight e retentativas | Rebaixar ou rejeitar |
| Session expiry | Mensagens offline armazenadas | Limitar o intervalo de expiração |
| Retained messages | Armazenamento | Limites de quantidade e tamanho |
O MQTT 5 ajuda aqui porque o broker consegue se explicar. O reason code 0x97 (Quota exceeded) informa a um cliente bem escrito que ele atingiu um limite, em vez de deixá-lo adivinhando por que uma publicação foi descartada. Para o lado do cliente nos limites, veja cotas de conexão do broker MQTT.
Cluster Compartilhado ou Cluster Dedicado?
Multi-tenancy é um espectro. Em uma ponta, todos os tenants compartilham um cluster com isolamento lógico. Na outra, cada tenant recebe máquinas dedicadas. A tabela resume o trade-off.
| Aspecto | Cluster multi-tenant compartilhado | Cluster dedicado por tenant |
|---|---|---|
| Eficiência de custo | Alta, a capacidade é compartilhada | Menor, a capacidade é reservada |
| Isolamento | Lógico (identidade, namespace, cotas) | Físico |
| Exposição a vizinhos barulhentos | Limitada pelas cotas | Nenhuma vinda de outros tenants |
| Tempo de provisionamento | Segundos | Mais longo |
| Limites personalizados | Baseados no plano | Dimensionados para o tenant |
| Uso típico | Protótipos, frotas pequenas e médias | Frotas grandes, requisitos rigorosos |
A maioria dos provedores oferece as duas opções e permite que um tenant passe de uma para a outra conforme as necessidades crescem. A questão mais profunda de quão fortemente separar os clientes é abordada em isolamento de tenants MQTT.
Operando um Broker Multi-Tenant
Projetar o isolamento é metade do trabalho. Operá-lo é a outra metade:
- Observabilidade por tenant. As métricas precisam de uma dimensão de tenant: conexões, taxas de mensagens e rejeições por cota por tenant, não apenas totais do cluster.
- Upgrades justos. Reinicializações graduais devem distribuir a carga de reconexão, e os clientes precisam usar backoff aleatório para que milhares de dispositivos de muitos tenants não voltem no mesmo instante.
- Tratamento de abusos. A proteção contra flood deve agir sobre o tenant ou cliente causador, não sobre o cluster inteiro.
- Ciclo de vida dos tenants. Criar, suspender e excluir tenants precisa limpar completamente sessões, retained messages e credenciais.
Como o ConnectMQ Implementa Multi-Tenancy
O ConnectMQ foi construído como uma plataforma multi-tenant. Nos planos Serverless, muitos brokers compartilham um cluster, e cada broker fica isolado dos demais: ele tem usuário, senha e client ID próprios gerados, os client IDs ficam vinculados às credenciais emitidas, e cotas por plano limitam conexões, QoS e tamanho de mensagem. O plano Serverless gratuito permite até 25 conexões, QoS até 1 e mensagens de 256 KB; o plano Serverless pago eleva isso para até 1.000 conexões, QoS 2, mensagens de 1 MB e shared subscriptions.
A proteção contra flood e o bloqueio de IP após repetidas falhas de login protegem todos os tenants do cluster compartilhado. Quando um cliente ultrapassa seus limites, clientes MQTT 5 recebem o reason code 0x97, deixando a causa visível. Se o isolamento lógico não for suficiente, o plano Dedicated oferece um cluster isolado, e o BYOC roda o broker na sua própria conta de nuvem, ainda gerenciado pelo ConnectMQ.
Experimente um Layout de Topics com Escopo de Tenant
Mesmo dentro do seu próprio broker, um layout de topics consistente torna as aplicações multi-tenant mais fáceis de entender. Este exemplo com MQTT.js publica em um topic prefixado por tenant e site no servidor MQTT público; lembre-se de que ele serve apenas para testes e de que a área pública pode ser lida por qualquer pessoa.
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));
Em um broker privado do ConnectMQ, adicione username: "YOUR_USERNAME" e password: "YOUR_PASSWORD" e use o YOUR_CLIENT_ID fornecido no portal.
Comece com o ConnectMQ
Não perca tempo construindo o isolamento de tenants por conta própria. Crie um broker Serverless gratuito e isolado em app.connectmq.com, sem cartão de crédito, e escale para Dedicated ou BYOC quando precisar de uma separação mais forte. Saiba mais sobre o modelo de broker MQTT gerenciado ou veja o guia completo de broker MQTT na nuvem.
Perguntas frequentes
Um prefixo de topic basta para separar tenants?
Somente se o broker o impuser. Um prefixo sem imposição é uma convenção de nomenclatura; um cliente que assina # ainda veria as mensagens de outros tenants.
O que é o problema do vizinho barulhento no MQTT?
Acontece quando o tráfego intenso ou defeituoso de um tenant consome recursos compartilhados do broker e degrada o serviço para os demais. Cotas por tenant e proteção contra flood limitam o dano.
Um broker multi-tenant afeta o código do meu cliente?
Normalmente não. Os clientes usam MQTT padrão; a fronteira do tenant é definida pelas credenciais e pelo endpoint com os quais você se conecta.
Quando devo migrar de um broker compartilhado para um dedicado?
Migre quando precisar de capacidade previsível e não compartilhada, de limites acima das cotas dos planos compartilhados ou quando uma política exigir isolamento físico.
