Broker MQTT Dedicado: Quando Você Supera o Serverless

Um broker MQTT dedicado oferece a um único cliente um cluster de broker isolado, em vez de uma fatia de um cluster compartilhado, de modo que desempenho e capacidade ficam reservados somente para a sua frota. Este guia explica o que o isolamento traz, os sinais de que você superou um nível serverless, como planejar a capacidade antes da troca e um checklist prático para migrar do Serverless para o Dedicated da ConnectMQ.

O Que É um Broker MQTT Dedicado

Em um nível serverless, muitos tenants compartilham um cluster e ficam separados logicamente por credenciais, namespaces de topics e cotas. Uma implantação dedicada elimina o compartilhamento: o provedor opera um cluster de broker que atende somente a sua organização. Você continua sem gerenciar servidores, sistemas operacionais ou certificados, porque ainda se trata de um broker MQTT gerenciado, mas a computação, a memória e a rede por trás do seu endpoint não são compartilhadas com mais ninguém.

Essa distinção importa menos do que se imagina para frotas pequenas e muito mais do que se imagina para frotas grandes ou sensíveis à latência. Se você ainda está decidindo entre modelos de hospedagem em alto nível, o guia principal de broker MQTT na nuvem explica todo o panorama.

O Que o Isolamento Traz

Desempenho Previsível

Em um cluster compartilhado, as cotas impedem que um único tenant monopolize os recursos, mas o seu tráfego ainda corre ao lado do tráfego de todos os outros. Com um broker MQTT dedicado, um pico de outra empresa simplesmente não consegue afetar você. Latência e vazão dependem da sua própria carga de trabalho, o que torna o comportamento mais fácil de entender e de testar.

Folga de Capacidade Que Você Pode Planejar

Níveis compartilhados têm cotas fixas por plano. Um cluster dedicado é dimensionado para a carga esperada, então você planeja a folga de forma deliberada em vez de esbarrar em um teto pensado para o tenant médio.

Uma Narrativa de Segurança e Compliance Mais Simples

Algumas revisões de segurança fazem uma pergunta simples: o tráfego de algum outro cliente passa pelo mesmo processo de broker? Com hospedagem dedicada, a resposta é não. Isso costuma encurtar as conversas de compras, mesmo quando o nível compartilhado já era tecnicamente bem isolado.

Menos Restrições de Design

Fan-out amplo, muitos consumidores de backend em shared subscriptions, payloads maiores e fluxos QoS 2 são mais fáceis de acomodar quando o cluster é seu.

Sinais de Que Você Superou o Serverless

Fique atento a estes sinais. Um sozinho não é necessariamente motivo para migrar; vários juntos geralmente são.

Sinal	O que você observa	Por que importa
Teto de conexões	Conexões recusadas, reason code 0x97	Os dispositivos não conseguem ficar online
Taxa de mensagens alta e constante	Vazão constante o dia inteiro	Você paga por capacidade compartilhada que, na prática, usa o tempo todo
Sensibilidade à latência	Malhas de controle, alarmes, interfaces de operador	A variação prejudica mais do que a média
Requisitos de compras	Perguntas sobre infraestrutura compartilhada	O isolamento simplifica a resposta
Plano de crescimento da frota	Milhares de dispositivos no roadmap	Melhor migrar antes da correria
Muitos consumidores de backend	Vários serviços assinando os mesmos fluxos	O fan-out multiplica a carga

O plano Serverless (Paid) da ConnectMQ suporta até 1.000 conexões, QoS 2, mensagens de 1 MB e shared subscriptions, o que é suficiente para muitos produtos. O Dedicated é para quando você quer o seu próprio cluster isolado, e não cotas maiores em um cluster compartilhado.

Planejamento de Capacidade para uma Implantação Dedicada

Um bom planejamento de capacidade parte dos seus dispositivos, não de benchmarks de broker. Levante estes números e anote-os; são eles que você vai discutir ao dimensionar o cluster.

Pico de conexões simultâneas. Dispositivos, gateways, serviços de backend, dashboards e ferramentas de teste, todos contam. Inclua o cenário de tempestade de reconexão: após uma queda de rede, todos os dispositivos reconectam em uma janela curta.
Mensagens por segundo, entrada. Multiplique os dispositivos pela taxa de publicação. 2.000 medidores de uma rede de saneamento com uma mensagem a cada 10 segundos dão, em média, 200 mensagens por segundo, mas o alinhamento (dispositivos reportando na virada do minuto) cria picos.
Fan-out, saída. Cada mensagem publicada é entregue uma vez por assinatura correspondente. Uma mensagem lida por um dashboard, um historiador e um serviço de alertas representa três entregas.
Tamanho do payload. Médio e máximo. Payloads JSON compactos ou binários reduzem a banda e a memória do broker.
Mix de QoS. QoS 1 e 2 adicionam tráfego de confirmação e estado em trânsito em comparação com QoS 0. Veja níveis de QoS no MQTT explicados.
Estado de sessão. Sessões persistentes com mensagens enfileiradas para clientes offline consomem memória. Defina a expiração de sessão para que sessões abandonadas não se acumulem.
Retained messages. Uma mensagem retida por topic de estado é barata; milhões de topics retidos obsoletos não são.
Crescimento. Planeje para os próximos 12 a 18 meses de crescimento da frota, e não para a contagem de hoje.

Uma planilha simples de dimensionamento em texto puro ajuda a alinhar a equipe:

Peak devices online ............ 3,000
Backend/dashboard clients ...... 40
Reconnect storm window ......... 120 s
Avg publish interval ........... 15 s   -> ~200 msg/s inbound
Avg subscribers per message .... 2      -> ~400 msg/s outbound
Avg payload .................... 350 bytes
QoS ............................ 1 (telemetry), 2 (commands)
Retained topics ................ ~3,000 (one status topic per device)
Session expiry ................. 1 hour
Growth target (18 months) ...... 3x

Meça Antes de Migrar

Antes da troca, colete números reais do seu broker serverless. Um pequeno assinante em Python que conta as mensagens por topic de primeiro nível fornece uma linha de base rápida.

import collections
import ssl
import time

import paho.mqtt.client as mqtt

counts = collections.Counter()
start = time.time()


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe("#", qos=0)


def on_message(client, userdata, msg):
    counts[msg.topic.split("/")[0]] += 1
    elapsed = time.time() - start
    if elapsed >= 60:
        for prefix, n in counts.most_common():
            print(f"{prefix:20s} {n / elapsed:8.2f} msg/s")
        counts.clear()
        globals()["start"] = time.time()


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(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Combine isso com o dashboard do portal e com o topic $SYS/broker/connection/{clientId}/state, que mostra se um determinado cliente está conectado, para entender tanto o tráfego quanto o comportamento das conexões.

Checklist de Migração: do Serverless para o Dedicated

Como um broker MQTT dedicado fala o mesmo protocolo MQTT 3.1.1 e 5.0 nas mesmas portas (1883, 8883, 8083 e 8084 com /mqtt), a migração é basicamente um exercício de configuração.

Torne o endpoint configurável. Se hostname, porta, username, senha e client ID estão compilados no firmware, corrija isso primeiro. Armazene-os em NVS, em um arquivo de configuração ou nos dados de provisionamento.
Solicite e provisione o broker dedicado. Obtenha novas credenciais no portal para o ambiente dedicado.
Migre primeiro os consumidores do backend. Aponte uma cópia de cada serviço de backend para o novo broker e verifique se ela recebe o tráfego de teste.
Faça uma ponte durante a transição com a sua própria ferramenta. Se os dispositivos forem migrar ao longo de dias ou semanas, execute um pequeno relay (Node-RED ou um script Python curto) que assina no broker antigo e republica no novo. A ConnectMQ não oferece bridges nativas, então isso é feito com um cliente MQTT externo.
Migre os dispositivos em ondas. Atualize uma pequena porcentagem, acompanhe o estado das conexões e os logs de erro e, então, continue.
Republique o estado retido. Retained messages não são migradas automaticamente; faça os dispositivos publicarem seu status atual ao conectar.
Desative o broker antigo. Quando o antigo não mostrar mais conexões de dispositivos, pare o relay e desative-o.

Armadilhas comuns: esquecer dashboards e scripts que ainda apontam para o hostname antigo, client IDs fixos no código que colidem entre ambientes e estado retido ausente após a virada. Vale ler ao mesmo tempo nosso guia de boas práticas de segurança MQTT, já que migrações são um momento natural para rotacionar credenciais.

Dedicated, BYOC ou Enterprise?

O Dedicated não é a única opção isolada. Se a sua organização precisa que o broker rode na própria conta de nuvem, o BYOC o implanta ali enquanto a ConnectMQ o gerencia. Se você precisa operar tudo por conta própria, o Self Managed Enterprise cobre esse caso. O guia de broker MQTT empresarial compara esses modelos com os requisitos corporativos típicos.

Migre para um Broker Dedicado com a ConnectMQ

A maioria das equipes testa os primeiros clientes no servidor MQTT público (gratuito, só para testes, sem dados de produção), começa no plano Serverless gratuito em app.connectmq.com (sem cartão de crédito), mede o tráfego real e migra para um cluster Dedicated quando isolamento e folga se tornam prioridades. A ConnectMQ mantém os mesmos protocolos, portas e ferramentas de portal em todos os planos, então seus dispositivos, o explorador de topics, os dashboards e as regras de alerta continuam funcionando do mesmo jeito após a troca.

Perguntas frequentes

Um broker MQTT dedicado é mais rápido que o serverless?

Não necessariamente em média, mas é mais previsível, porque nenhum outro tenant compartilha o cluster. O benefício aparece mais sob carga contínua e durante picos.

Preciso reescrever o firmware dos dispositivos para migrar para o dedicado?

Não, se as configurações de conexão forem configuráveis. O protocolo e as portas continuam os mesmos, então só mudam o hostname e as credenciais.

Posso manter um broker serverless depois de migrar para o dedicado?

Sim. Muitas equipes mantêm um broker serverless gratuito para desenvolvimento e testes e rodam a produção no cluster dedicado.

Um broker dedicado inclui replicação entre regiões?

Não presuma isso. Pergunte sobre a implantação específica e projete os dispositivos para reconectar com backoff e republicar o estado, para que se recuperem de forma limpa de qualquer reinício do broker.