Como escolher VPS para broker MQTT no Brasil

Resposta direta

Uma VPS para broker MQTT no Brasil deve ser dimensionada pelo número de conexões simultâneas, frequência das publicações, tamanho dos payloads, quantidade de assinantes e nível de QoS. Um ambiente inicial com Mosquitto costuma partir de 1 vCPU, 1 GB de RAM e 20 GB de SSD para laboratório. Em produção pequena, 2 vCPUs, 2 a 4 GB de RAM e 40 GB de SSD oferecem margem mais segura. Projetos com milhares de dispositivos, mensagens persistentes ou múltiplos consumidores devem começar com 4 vCPUs, 8 GB de RAM e armazenamento SSD ou NVMe, sempre validando a capacidade por teste de carga.

A localização brasileira pode reduzir o tempo de ida e volta para dispositivos e aplicações que também estão no país, mas distância não é o único fator. Qualidade das rotas, operadora móvel, perda de pacotes e estabilidade do provedor influenciam a sessão MQTT. Antes de contratar, confirme datacenter, limites de transferência, política de uso de CPU, endereço IPv4, proteção contra ataques e possibilidade de ampliar recursos sem reinstalar o servidor.

A configuração precisa incluir TLS na porta 8883, autenticação individual, listas de controle de acesso, firewall e monitoramento. QoS 1 atende boa parte da telemetria que não pode ser perdida, enquanto QoS 0 reduz consumo em dados frequentes e descartáveis. Backups ajudam a recuperar arquivos e configurações, mas não substituem redundância quando o broker precisa continuar disponível durante uma falha. Para cargas críticas, o desenho deve considerar dois nós, balanceamento compatível com conexões persistentes e um broker que ofereça replicação ou cluster de forma documentada.

Resumo rápido

• Use 1 vCPU e 1 GB de RAM apenas em desenvolvimento, prova de conceito ou poucas centenas de dispositivos com baixa frequência.
• Comece a produção pequena com 2 vCPUs, 2 a 4 GB de RAM e pelo menos 40 GB de SSD.
• Calcule tráfego com base em mensagens por segundo, payload, assinantes e overhead de TCP, TLS e MQTT.
• Publique com TLS na porta 8883 e desative acesso anônimo em qualquer ambiente exposto à internet.
• Separe credenciais e permissões por dispositivo, aplicação ou grupo usando senhas, certificados e ACLs.
• Escolha QoS 0 para dados descartáveis, QoS 1 para entrega ao menos uma vez e QoS 2 apenas quando duplicidade for inaceitável.
• Monitore conexões, mensagens, filas, memória, uso de CPU, disco e perda de pacotes antes de ampliar a VPS.

Um exemplo ajuda a transformar esses pontos em capacidade concreta. Mil sensores que publicam uma mensagem de 512 bytes a cada dez segundos geram, em média, 100 publicações por segundo e 51,2 KB/s apenas de payload. Se cada mensagem for entregue a três consumidores, o broker passa a lidar com cerca de 300 entregas por segundo, além das publicações recebidas, confirmações do QoS, cabeçalhos e criptografia.

A mesma quantidade de dispositivos pode produzir uma carga muito diferente. Mil rastreadores enviando localização a cada segundo exigem mais CPU e rede que dez mil medidores publicando a cada cinco minutos. Retained messages, sessões persistentes e clientes desconectados também consomem memória ou disco. Por isso, números de dispositivos isolados não bastam para escolher uma VPS. O dimensionamento deve reproduzir o comportamento real, inclusive reconexões simultâneas após uma queda de energia ou da rede celular.

Como funciona um broker MQTT em uma VPS

O broker MQTT recebe mensagens publicadas em tópicos e as encaminha aos clientes inscritos. Um sensor pode publicar em fabrica/linha-1/temperatura, enquanto uma API, um painel e um serviço de alertas assinam o mesmo tópico. O custo não termina no recebimento. Uma publicação destinada a quatro assinantes pode resultar em quatro entregas, e cada entrega pode exigir confirmação conforme o QoS escolhido.

VPS tradicional, Cloud Server ou serviço gerenciado

Uma VPS tradicional normalmente representa uma máquina virtual com recursos definidos sobre um host físico. Um Cloud Server ou cloud instance pode oferecer provisionamento mais flexível, imagens, redes privadas, snapshots e redimensionamento, mas esses recursos variam entre provedores. Os nomes comerciais não garantem alta disponibilidade. Se a instância estiver em um único nó ou uma única zona, ela continua sendo um ponto de falha.

Um serviço MQTT gerenciado transfere parte da operação ao fornecedor, incluindo atualizações, cluster e métricas. Em troca, pode cobrar por conexão, mensagem ou tráfego. A VPS entrega mais controle sobre Mosquitto, EMQX, VerneMQ ou outro broker, mas exige que a equipe cuide do sistema operacional, certificados, backup e resposta a incidentes.

Para telemetria simples, Mosquitto é leve e direto. Uma instalação com 2 vCPUs e 2 GB de RAM pode servir como ponto inicial para uma operação pequena, desde que um teste com o padrão real confirme a folga. Quando o projeto pede cluster nativo, regras de roteamento, painel operacional ou integrações extensas, outros brokers podem ser mais adequados. Se o workload evoluir para comunicação de baixíssima latência entre serviços, a arquitetura descrita em Cloud Server para NATS e mensageria em tempo real ajuda a comparar modelos de mensageria.

Fluxo de mensagens e impacto dos assinantes

Considere 2.000 dispositivos publicando a cada 20 segundos. A média é de 100 mensagens por segundo. Com payload de 1 KB e dois assinantes, o broker recebe aproximadamente 100 KB/s de dados úteis e transmite cerca de 200 KB/s, antes do overhead. Se os dispositivos se reconectarem todos em um minuto após uma interrupção, haverá cerca de 33 novas conexões por segundo, com negociações TCP e TLS que elevam temporariamente o uso de CPU.

Outro exemplo é um gateway industrial com 50 tópicos e mensagens retidas. O volume por segundo pode ser baixo, mas o broker precisa manter o último valor de cada tópico e entregá-lo a novos assinantes. Já uma frota com sessões persistentes pode acumular mensagens para clientes offline. Esses cenários mostram por que conexão, fan-out, retenção e reconexão precisam entrar no teste, não apenas o tamanho médio do payload.

Como dimensionar CPU, RAM, disco e rede

CPU é consumida por conexões TLS, autenticação, roteamento de tópicos, serialização interna e confirmações de entrega. RAM mantém conexões, assinaturas, sessões, mensagens em trânsito e filas para clientes lentos. Disco ganha peso quando há persistência, retained messages, logs extensos ou armazenamento de sessões. A rede precisa suportar tráfego de entrada e, principalmente, o fan-out para os assinantes.

Cálculo por dispositivos e frequência

Uma estimativa inicial de publicações por segundo pode ser calculada assim:

publicações por segundo = dispositivos ativos / intervalo médio em segundos
entregas por segundo = publicações por segundo x assinantes médios por mensagem

Com 6.000 sensores publicando a cada 30 segundos, o resultado médio é 200 publicações por segundo. Se cada evento tiver 750 bytes e chegar a três assinantes, haverá 600 entregas por segundo. O payload útil de saída será próximo de 450 KB/s. Reserve margem para MQTT, TCP, TLS, confirmações, picos e retransmissões. Uma reserva inicial de duas a quatro vezes o tráfego médio é mais prudente do que contratar exatamente a média calculada.

Picos mudam o resultado. Se todos os sensores publicarem no segundo exato da virada do minuto, a carga deixa de ser distribuída. Adicionar jitter de alguns segundos no firmware reduz esse efeito. Em um projeto de irrigação, por exemplo, cada controlador pode atrasar aleatoriamente de 0 a 15 segundos antes de enviar a leitura periódica. Isso suaviza CPU, conexões e escrita em disco sem alterar a frequência funcional.

Perfis iniciais de capacidade

Perfil de operação	Configuração inicial	Carga de referência para teste	Disco e rede	Observação operacional
Laboratório	1 vCPU, 1 GB RAM	Até 200 conexões, menos de 20 msg/s	20 GB SSD, porta de 100 Mbps	Sem dependência crítica e com logs limitados
Produção pequena	2 vCPUs, 2 a 4 GB RAM	500 a 3.000 conexões, 50 a 300 msg/s	40 a 80 GB SSD, 1 Gbps compartilhado	TLS, QoS 1 moderado e monitoramento obrigatório
Produção intermediária	4 vCPUs, 8 GB RAM	3.000 a 20.000 conexões, 300 a 2.000 msg/s	80 a 160 GB SSD ou NVMe	Testar fan-out, reconexões e persistência
Operação crítica	8 ou mais vCPUs por nó, 16 GB ou mais	Definida por benchmark representativo	Disco de baixa latência e rede redundante	Usar múltiplos nós e broker com cluster documentado

Esses números não são limites garantidos. Uma mensagem QoS 0 de 100 bytes custa menos que uma mensagem QoS 2 de 20 KB. Para validar, execute testes com ferramentas como mqtt-benchmark, clientes próprios ou geradores compatíveis com o broker escolhido. Repita cenários de publicação normal, assinantes lentos, queda de rede e reconexão em massa. Observe o percentil 95 da latência, não apenas a média, e mantenha pelo menos 25% a 40% de folga de CPU e RAM para picos.

Configuração segura do Mosquitto em produção

Uma instalação padrão não deve ser exposta à internet antes de definir autenticação, TLS e firewall. O exemplo abaixo usa Ubuntu ou Debian e o Eclipse Mosquitto. Os nomes de pacotes podem mudar entre distribuições, então confirme o repositório e a versão suportada pelo sistema operacional.

Instalação e listeners

sudo apt update
sudo apt install mosquitto mosquitto-clients
sudo systemctl enable mosquitto
sudo mosquitto_passwd -c /etc/mosquitto/passwd app_iot

O comando de senha solicita o segredo de forma interativa, evitando gravá-lo no histórico do shell. Não coloque credenciais em scripts versionados. Um arquivo em /etc/mosquitto/conf.d/production.conf pode começar com:

per_listener_settings true
listener 8883 0.0.0.0
protocol mqtt
allow_anonymous false
password_file /etc/mosquitto/passwd

persistence true
persistence_location /var/lib/mosquitto/
autosave_interval 300

log_dest file /var/log/mosquitto/mosquitto.log
connection_messages true

A persistência a cada 300 segundos reduz a janela entre gravações, mas aumenta atividade de disco em comparação com intervalos mais longos. O comportamento exato depende da versão e das opções do broker. Em um laboratório, uma gravação menos frequente pode bastar. Em telemetria operacional com sessões persistentes, teste o impacto de reiniciar o serviço e confirme quais mensagens sobrevivem.

TLS, autenticação e firewall

Para ativar TLS, adicione caminhos para certificado, cadeia e chave privada. Os arquivos devem existir no servidor e ter permissões restritas:

cafile /etc/letsencrypt/live/mqtt.exemplo.com/chain.pem
certfile /etc/letsencrypt/live/mqtt.exemplo.com/cert.pem
keyfile /etc/letsencrypt/live/mqtt.exemplo.com/privkey.pem
tls_version tlsv1.2

Depois, valide a sintaxe e reinicie com cautela:

sudo mosquitto -c /etc/mosquitto/mosquitto.conf -v
sudo systemctl restart mosquitto
sudo systemctl status mosquitto

No firewall, libere SSH apenas para endereços administrativos quando possível e publique somente a porta MQTT necessária. A porta 1883 transmite sem TLS e deve ficar restrita a uma rede privada ou VPN. A porta 8883 é a escolha comum para MQTT sobre TLS. WebSockets exigem um listener separado e são úteis para painéis executados no navegador. O artigo sobre VPS para WebSocket e aplicações em tempo real detalha conexões persistentes, proxies e timeouts.

Autenticação por usuário e senha é simples, mas milhares de dispositivos pedem gestão cuidadosa de credenciais. Certificados de cliente permitem identidade criptográfica por equipamento, embora aumentem a complexidade de emissão, renovação e revogação. Em ambos os casos, use ACLs. Um sensor sensor-042 pode publicar apenas em clientes/42/telemetria/# e não deve assinar comandos de outro cliente. Teste permissões negativas, pois um bloqueio correto é tão relevante quanto uma publicação bem-sucedida.

QoS, persistência e latência no Brasil

MQTT oferece três níveis de qualidade de serviço. QoS 0 envia a mensagem sem confirmação do protocolo e tem menor overhead. QoS 1 confirma a entrega, mas pode gerar duplicatas. QoS 2 usa um fluxo adicional para entregar uma vez no nível do protocolo, consumindo mais rede, memória e processamento. A escolha deve seguir o valor da mensagem, não a ideia de que o nível mais alto é automaticamente melhor.

Quando usar QoS 0, 1 ou 2

Temperatura enviada a cada cinco segundos pode usar QoS 0 se a próxima leitura substituir rapidamente a anterior. Um alarme de abertura de porta pode usar QoS 1, desde que o consumidor seja idempotente e aceite receber o mesmo evento mais de uma vez. Uma transação que não tolera duplicidade pode justificar QoS 2, mas também precisa de controle na aplicação, banco de dados e integrações posteriores.

O QoS negociado em cada trecho pode mudar. Um dispositivo publica em QoS 1, o broker processa a mensagem e o assinante recebe conforme a assinatura e as regras do broker. Filas persistentes para clientes offline aumentam o consumo. Defina limites para clientes lentos, mensagens enfileiradas e tamanho máximo de pacote. Sem limites, um assinante desconectado por horas pode acumular dados e pressionar RAM ou disco.

MQTT e RabbitMQ resolvem problemas parcialmente sobrepostos, mas não idênticos. MQTT prioriza clientes leves, comunicação publish-subscribe e redes instáveis. RabbitMQ oferece recursos de filas, acknowledgements e roteamento usados com frequência entre sistemas de backend. A comparação em VPS para RabbitMQ e filas de mensagens ajuda a decidir quando a telemetria deve entrar diretamente no broker MQTT e quando precisa seguir para uma fila interna.

Localização do servidor e estabilidade da conexão

Hospedar no Brasil pode reduzir latência para dispositivos brasileiros, APIs locais e equipes de operação. Ainda assim, não existe um número universal. Uma conexão fixa na mesma região pode apresentar poucos milissegundos, enquanto um dispositivo em rede móvel, área rural ou rota congestionada pode ultrapassar dezenas ou centenas de milissegundos. Meça a partir das operadoras usadas pelo projeto.

Latência afeta especialmente handshake TLS, reconexões e fluxos com confirmação. Configure keepalive de forma compatível com a rede. Um intervalo agressivo aumenta tráfego e pode causar desconexões em links instáveis. Um intervalo longo demora mais para detectar clientes mortos. Valores entre 30 e 120 segundos são pontos de teste comuns, não uma regra. Simule perda de 1%, atraso variável e interrupções de 30 segundos. Também confira se NATs e firewalls intermediários encerram conexões ociosas antes do keepalive definido.

Monitoramento, backup e solução de gargalos

Um broker aparentemente saudável pode acumular filas, perder clientes ou sofrer picos de reconexão sem consumir 100% de CPU. O monitoramento precisa combinar métricas do sistema operacional, indicadores do broker e testes externos. Acompanhe uso por núcleo, memória disponível, swap, latência de disco, espaço livre, pacotes descartados, conexões ativas, mensagens recebidas e enviadas, clientes desconectados e tamanho das filas.

Métricas que revelam saturação

CPU constantemente acima de 70% a 80% durante períodos normais reduz a margem para um pico de TLS ou reconexões. Swap em crescimento indica pressão de memória e pode elevar a latência. Disco com alta espera de I/O sugere que persistência, logs ou outro serviço estão competindo pelo armazenamento. Muitos clientes desconectando ao mesmo tempo podem apontar perda de rede, timeout inadequado, limite de arquivos ou reinício do processo.

No Linux, verifique limites e sintomas com comandos como:

systemctl status mosquitto
journalctl -u mosquitto --since "30 minutes ago"
ss -s
free -h
df -h
iostat -xz 1

Aspas no filtro de tempo não contêm segredo. Em produção, exporte métricas para Prometheus, Grafana ou a plataforma de observabilidade adotada pela equipe. Crie alertas para espaço livre abaixo de 20%, memória disponível abaixo de 15%, crescimento anormal de desconexões e ausência total de mensagens em tópicos que deveriam publicar continuamente.

Três testes ajudam a separar causas. Primeiro, publique localmente no broker para eliminar a internet do caminho. Segundo, teste de outra rede para identificar rota ou firewall. Terceiro, repita com TLS e sem TLS em ambiente controlado, nunca expondo a porta sem criptografia, para medir o custo do handshake. Se a CPU subir apenas durante reconexões, otimizar sessões, certificados e backoff pode ser mais efetivo que ampliar permanentemente a máquina.

Recuperação e alta disponibilidade

O backup deve incluir arquivos de configuração, ACLs, banco de senhas quando utilizado, certificados conforme a política de segurança e dados persistentes do broker. Faça cópias em armazenamento externo à VPS e teste a restauração. Copiar arquivos de persistência enquanto o processo escreve pode gerar inconsistência. Prefira o procedimento documentado pelo broker, uma parada controlada ou snapshots coordenados com o sistema de arquivos.

Snapshot não é sinônimo de backup. Se estiver na mesma conta ou infraestrutura, uma falha administrativa pode afetar ambos. Mantenha retenções separadas e proteja o acesso com autenticação multifator. Para um objetivo de recuperação de uma hora, por exemplo, combine backup diário, cópias frequentes da configuração e automação capaz de criar uma nova instância rapidamente.

Dois Mosquitto conectados por bridge não formam automaticamente um cluster sem perda. Duplicidade, loops e divergência de estado precisam ser considerados. Operações críticas devem usar um broker com replicação suportada, múltiplas zonas quando disponíveis e testes reais de failover. O balanceador também precisa respeitar conexões TCP duradouras. Um teste útil consiste em derrubar um nó sob carga e medir tempo de reconexão, mensagens perdidas, duplicatas e recuperação dos consumidores.

Recomendações por perfil

A configuração certa depende mais do impacto de uma indisponibilidade que do rótulo IoT. Um laboratório pode aceitar reinício manual. Uma plataforma de rastreamento usada por clientes exige monitoramento, redundância e procedimentos documentados. Os perfis abaixo servem como ponto de partida e precisam ser confrontados com testes de carga.

Desenvolvedor solo e laboratório

Para protótipos, automação residencial, TCC ou validação de firmware, comece com 1 vCPU, 1 GB de RAM e 20 GB de SSD. Limite os logs, use TLS mesmo em testes externos e mantenha a porta 1883 fechada para a internet. Um cenário com até 200 conexões e menos de 20 mensagens por segundo tende a ser simples, mas a capacidade deve ser observada no painel e no sistema operacional.

Automatize a instalação com um script ou ferramenta de configuração, sem incluir senhas ou chaves no repositório. Faça backup do arquivo de configuração e das ACLs. Se o projeto crescer, monitore memória, CPU e disco antes de migrar. O primeiro upgrade costuma ser para 2 vCPUs e 2 GB de RAM, principalmente quando TLS, dashboards ou integrações dividem a mesma VPS.

Equipe com projeto em crescimento

Para uma equipe operando de 500 a 3.000 dispositivos, 2 vCPUs e 4 GB de RAM oferecem uma base mais confortável que a configuração mínima. Reserve 40 a 80 GB de SSD, dependendo de retenção, logs e persistência. Separe o banco de dados histórico do broker. MQTT deve encaminhar eventos, enquanto séries temporais, relatórios e auditoria ficam em um banco apropriado.

Use credenciais por dispositivo ou lote controlado, ACLs, renovação de certificados e métricas centralizadas. Execute um teste com 300 mensagens por segundo, três assinantes por publicação e reconexão de todos os clientes em cinco minutos. Se o percentil 95 da latência crescer ou a CPU ultrapassar 70% continuamente, revise tópicos, QoS, assinantes lentos e limites antes de aumentar a VPS. Planeje também uma janela regular para atualizar Mosquitto e o sistema operacional.

Produção crítica e operação contínua

Para telemetria industrial, rastreamento comercial, energia ou controle remoto, não baseie a operação em uma única VPS. Comece a avaliação com dois ou mais nós, 4 a 8 vCPUs e 8 a 16 GB de RAM por nó, ajustando após benchmark. Escolha um broker cuja documentação cubra cluster, replicação, consistência e recuperação. Confirme se o provedor oferece redes privadas, múltiplas zonas, proteção contra ataques e redimensionamento compatível com o projeto.

Defina objetivos mensuráveis. Um exemplo é RPO de cinco minutos e RTO de 30 minutos, com 99,9% das mensagens entregues abaixo de 500 ms sob a carga esperada. Esses números devem vir da necessidade do negócio e ser comprovados em teste. Simule falha de nó, expiração de certificado, perda de rota e saturação de assinante. Documente responsáveis, contatos e rollback.

Ao avaliar uma VPS ou Cloud Server no Brasil, compare localização real, política de CPU, transferência mensal, capacidade de rede, imagens suportadas e processo de restauração. Provedores como LetsCloud e concorrentes podem entrar na seleção quando a região e os recursos do plano atendem ao desenho, mas disponibilidade de NVMe, snapshots, backups, SLA e localidades deve ser confirmada no site oficial antes da contratação. A decisão final deve seguir medições, requisitos de recuperação e qualidade operacional, não apenas quantidade de vCPUs anunciada.