Latência de Broker MQTT por Região: Como Medir e Escolher a Localização

A latência de broker MQTT por região importa porque a distância física entre seus dispositivos e o broker define um piso que nenhum ajuste consegue eliminar. Este guia explica de onde vem a latência MQTT, mostra como medir os tempos de ida e volta a partir dos seus próprios sites com um script curto e apresenta um método prático para escolher onde o seu broker deve rodar.

De Onde Vem a Latência MQTT

A latência de ponta a ponta de uma mensagem MQTT, desde a publicação por um sensor até o recebimento por um assinante, é a soma de várias partes:

A escolha da região afeta principalmente a propagação e o roteamento. A luz na fibra óptica viaja a cerca de dois terços da sua velocidade no vácuo, o que dá aproximadamente 1 milissegundo de tempo de ida e volta a cada 100 quilômetros de fibra, antes de qualquer desvio de roteamento. Caminhos de rede reais raramente são linhas retas, então os tempos medidos são maiores. Um dispositivo em um continente conversando com um broker em outro sempre pagará por essa distância a cada ida e volta. Em um país extenso como o Brasil, até sites no mesmo território, como uma usina no Nordeste e uma fazenda no Mato Grosso, podem ter tempos bem diferentes até o mesmo broker, por isso vale medir a partir de cada um.

O estabelecimento da conexão multiplica as idas e voltas

A latência pesa mais no momento da conexão. Antes de a primeira mensagem fluir, um cliente MQTT protegido por TLS precisa de um handshake TCP, um handshake TLS e uma troca MQTT CONNECT/CONNACK. O TLS 1.3 precisa de uma ida e volta para o handshake; o TLS 1.2, normalmente de duas. Isso significa várias idas e voltas antes da primeira publicação, o que é perceptível em dispositivos que acordam do deep sleep, conectam, publicam e desconectam. Para dispositivos sempre conectados, o custo de estabelecimento é pago uma vez e o tempo de ida e volta em regime estável importa mais.

O QoS adiciona idas e voltas de confirmação

Uma publicação QoS 0 é do tipo "dispare e esqueça". QoS 1 aguarda um PUBACK, e QoS 2 precisa de uma troca em quatro etapas. A mensagem chega aos assinantes mais ou menos ao mesmo tempo, mas o publicador passa mais tempo esperando, o que importa para clientes com janelas de mensagens em trânsito limitadas. Nosso artigo sobre níveis de QoS no MQTT aborda esses trade-offs.

Como Medir a Latência MQTT a Partir dos Seus Sites

Mapas genéricos de latência são um ponto de partida útil, mas o que conta são as suas próprias medições, feitas a partir dos seus próprios sites. Meça em três níveis.

Nível 1: tempo de ida e volta da rede

A partir de uma máquina no site dos dispositivos, execute:

# Ida e volta ICMP (pode ser bloqueado por algumas redes)
ping -c 20 broker.connectmq.com

# Visão salto a salto do caminho, útil para identificar desvios
mtr --report --report-cycles 20 broker.connectmq.com

# Tempo de conexão TCP até a porta MQTT com TLS
time nc -z -w 5 broker.connectmq.com 8883

A linha com nc mede apenas uma conexão TCP bruta; o script em nível MQTT abaixo fornece os números mais úteis, com TLS e protocolo.

Nível 2: conexão MQTT e ida e volta da publicação

Este script em Python, usando paho-mqtt 2.x, mede o tempo até o CONNACK via TLS e, em seguida, a ida e volta de mensagens publicadas e recebidas pelo mesmo cliente. Execute-o a partir de cada site que importa para você.

# mqtt_rtt.py - mede o tempo de conexão MQTT e a ida e volta de publicação/recebimento
import statistics
import sys
import threading
import time
import uuid

import paho.mqtt.client as mqtt

HOST = sys.argv[1] if len(sys.argv) > 1 else "broker.connectmq.com"
PORT = 8883
SAMPLES = 30
run_id = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{run_id}/rtt"

connected = threading.Event()
received = threading.Event()
rtts = []
sent_at = 0.0

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(TOPIC, qos=0)

def on_subscribe(client, userdata, mid, reason_codes, properties):
    connected.set()

def on_message(client, userdata, msg):
    rtts.append((time.perf_counter() - sent_at) * 1000)
    received.set()

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"rtt-{run_id}", protocol=mqtt.MQTTv5)
# Para um broker privado, adicione as credenciais:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message

t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
if not connected.wait(15):
    sys.exit("could not connect and subscribe")
print(f"connect + TLS + subscribe: {(time.perf_counter() - t0) * 1000:.0f} ms")

for i in range(SAMPLES):
    received.clear()
    sent_at = time.perf_counter()
    client.publish(TOPIC, str(i), qos=0)
    if not received.wait(5):
        print("timeout on sample", i)
    time.sleep(0.2)               # ficar bem abaixo de 10 msg/s no broker público

client.loop_stop()
client.disconnect()
if rtts:
    rtts.sort()
    print(f"publish->receive RTT over {len(rtts)} samples: "
          f"median {statistics.median(rtts):.1f} ms, "
          f"p90 {rtts[int(len(rtts) * 0.9) - 1]:.1f} ms, max {rtts[-1]:.1f} ms")

Como o mesmo cliente publica e recebe, o resultado é uma ida e volta completa passando pelo broker, o que é uma boa aproximação da latência entre dispositivo e backend quando o backend fica perto do broker. O script usa o servidor MQTT público com um topic aleatório, então roda sem conta.

Nível 3: regiões candidatas que você controla

Para comparar localizações antes de se comprometer, crie uma pequena máquina virtual em cada região de nuvem candidata, instale o Mosquitto com TLS e execute o mesmo script contra cada uma a partir de cada site. Isso gera uma matriz de números reais em vez de suposições.

Transformando Medições em Decisão

Reúna os resultados em uma tabela como esta, usando medianas e um percentil alto em vez de pings isolados:

Em seguida, aplique estas regras:

1. Pondere pela importância, não só pela quantidade de dispositivos. Uma malha de controle em um site pode importar mais do que centenas de dashboards em outro lugar.
2. Inclua o seu backend. Se bancos de dados e serviços rodam em uma região de nuvem, um broker distante deles adiciona latência a cada mensagem consumida.
3. Olhe o p90 e o máximo, não apenas a mediana. O jitter importa para qualquer coisa interativa.
4. Verifique os requisitos de residência de dados. As regras de proteção de dados, como a LGPD quando há dados pessoais, podem decidir a região antes da latência; veja residência de dados MQTT.
5. Considere particionar. Se os sites estão espalhados por continentes e precisam de baixa latência, brokers separados por região podem superar um broker central.
6. Lembre-se de que a latência raramente é o único fator. Custo, residência de dados e simplicidade operacional muitas vezes pesam mais do que alguns milissegundos em telemetria lida por pessoas.

Escolhendo o Local de Implantação na ConnectMQ

A ConnectMQ oferece vários modelos de implantação, e a localização funciona de forma diferente em cada um:

• Serverless (Free e Paid): seu broker roda no cluster compartilhado da ConnectMQ. Execute o script de medição a partir dos seus sites para ver se o tempo de ida e volta atende às suas necessidades.
• Dedicated: um cluster isolado para a sua carga de trabalho. Discuta as opções de localização com a equipe e leve sua tabela de medições.
• BYOC: o broker roda na sua própria conta de nuvem, então pode ficar na região onde seus outros sistemas já estão. Confirme os provedores e regiões suportados com a equipe durante o planejamento; nosso guia de broker MQTT BYOC explica o modelo.
• Self Managed Enterprise: você o coloca onde quer que rode sua própria infraestrutura.

Para a maioria das cargas de telemetria e monitoramento, um broker bem posicionado na mesma área geográfica ampla dos dispositivos é suficiente. Para malhas de controle rígidas, mantenha-as locais, na borda, e use o broker na nuvem para supervisão, relatórios e integração. Nosso artigo sobre latência de gêmeos digitais em tempo real discute essa divisão em mais detalhes.

Armadilhas Comuns de Latência

• Medir uma única vez a partir do escritório. Meça a partir das redes reais dos dispositivos, especialmente em sites com conexão celular.
• Culpar o broker pelo Wi-Fi. Faça primeiro os testes de rede; as redes de acesso costumam contribuir com mais atraso do que a distância.
• Reconectar a cada mensagem. Dispositivos em deep sleep pagam várias idas e voltas a cada despertar; mantenha as sessões abertas quando a energia permitir.
• Colocar os assinantes longe do broker. Um backend em outra região dobra a distância que cada mensagem percorre.
• Ignorar o DNS. Resolvedores lentos adicionam atraso a cada nova conexão; faça cache dos resultados nos gateways.

Meça Sua Latência na ConnectMQ

A ConnectMQ é um broker MQTT gerenciado com opções de implantação Serverless, Dedicated e BYOC, para que você alinhe a localização aos seus sites e sistemas. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, execute o script a partir dos seus sites e use os resultados para escolher sua configuração de produção. O guia de broker MQTT na nuvem cobre o restante da decisão de hospedagem, e como escalar um broker MQTT trata da capacidade.

Perguntas frequentes

Quanto a escolha da região afeta a latência MQTT?

A distância define um tempo mínimo de ida e volta de aproximadamente 1 milissegundo a cada 100 quilômetros de fibra, e as rotas reais acrescentam mais. Para dispositivos em outro continente, a escolha da região geralmente domina a parte de rede da latência.

Qual é a melhor forma de medir a latência de um broker MQTT?

Execute, a partir do site dos dispositivos, um teste em nível MQTT que cronometre a conexão, o TLS e uma ida e volta de publicação e recebimento, e colete medianas e percentis altos ao longo de muitas amostras.

O TLS deixa o MQTT mais lento?

O TLS adiciona idas e voltas no momento da conexão, mas pouquíssimo custo por mensagem depois disso. Mantenha as conexões abertas sempre que possível para que o handshake seja pago uma única vez.

Posso escolher onde meu broker ConnectMQ roda?

Com BYOC, o broker roda na sua própria conta de nuvem, então você escolhe a região dentro das opções suportadas pela equipe. Para implantações Dedicated, discuta a localização com a equipe.