Latencia na Nuvem: Por Que o Sistema Ficou Lento Depois da Migracao

Por que a lentidão aparece justamente depois da migração

É um dos cenários mais comuns em projetos de nuvem: a migração termina, os sistemas sobem, os testes funcionais passam — e na primeira semana de uso real os usuários começam a reclamar que "ficou tudo mais lento". O ERP demora para abrir telas, o sistema de gestão trava em consultas que antes eram instantâneas, e a impressão geral é de que a nuvem foi um retrocesso. Na maioria dos casos, o problema não está na nuvem em si, mas na forma como a arquitetura foi transportada para ela.

Quando o servidor ficava na sala ao lado, cada requisição percorria alguns metros de cabo de rede, com latência típica abaixo de 1 milissegundo. Depois da migração, essa mesma requisição atravessa o link de internet da empresa, passa por roteadores da operadora, chega ao data center do provedor e volta. Se a aplicação foi desenhada para fazer centenas de pequenas requisições por operação — algo irrelevante em rede local — cada uma dessas idas e vindas agora custa 20, 40, às vezes 80 milissegundos. Multiplicado por centenas de chamadas, o resultado é uma tela que levava 1 segundo passando a levar 15.

Entender essa mecânica é o primeiro passo do diagnóstico. Latência não é falta de banda: a empresa pode ter um link de 1 Gbps e ainda assim sofrer com lentidão, porque o problema não é o volume de dados transferido, e sim o tempo de ida e volta de cada pacote. Antes de culpar o provedor ou contratar mais banda, é preciso medir onde o tempo está sendo gasto.

Região do data center: o fator que ninguém verifica antes de migrar

A escolha da região é a decisão de maior impacto na latência — e frequentemente é feita por preço, não por proximidade. Hospedar em uma região dos Estados Unidos porque a instância custa 20% menos pode significar 120 a 180 milissegundos de latência adicional para usuários no Brasil, contra 5 a 20 milissegundos de uma região local. Para aplicações web modernas e bem otimizadas, isso pode ser tolerável; para sistemas cliente-servidor legados, protocolos de banco de dados expostos diretamente ou compartilhamento de arquivos via SMB, é fatal.

O teste é simples e deveria ser feito antes de qualquer migração: um ping e um traceroute do escritório até o endpoint da região candidata, em horário comercial, repetido ao longo de alguns dias. Valores de referência práticos:

• Até 20 ms: excelente — praticamente qualquer aplicação funciona bem, incluindo desktop remoto e sistemas legados.
• 20 a 60 ms: bom para aplicações web e desktop remoto; sistemas cliente-servidor "conversadores" já podem apresentar lentidão perceptível.
• 60 a 120 ms: aceitável apenas para aplicações web otimizadas; ERP legado e SMB tornam-se penosos.
• Acima de 120 ms: só para cargas que não têm interação direta com usuário, como backup, arquivamento e processamento em lote.

Se o sistema já foi migrado para uma região distante, nem tudo está perdido: a maioria dos provedores permite replicar ou mover cargas entre regiões, e o custo dessa correção costuma ser muito menor do que conviver com anos de produtividade perdida. Outra saída é mudar o modelo de acesso — em vez de trafegar o protocolo da aplicação pela WAN, publicar o sistema via desktop remoto ou VDI hospedado na mesma rede do servidor, de modo que entre aplicação e banco a latência volte a ser de rede local.

O link da empresa: banda, mas principalmente qualidade

Depois da região, o segundo suspeito é o circuito de internet do escritório. Aqui vale separar três características que costumam ser confundidas: banda (quantos megabits por segundo), latência (tempo de ida e volta) e jitter (variação dessa latência). Um link doméstico de 500 Mbps pode ter jitter alto e perda de pacotes nos horários de pico, enquanto um link dedicado de 100 Mbps entrega latência estável o dia inteiro — e para acesso a sistemas na nuvem, estabilidade vale mais que velocidade nominal.

A perda de pacotes é especialmente traiçoeira. Perdas de apenas 1% a 2% já degradam brutalmente conexões TCP de longa distância, porque cada pacote perdido dispara retransmissões e reduz a janela de transmissão. O usuário percebe isso como "travadas" intermitentes: o sistema funciona, engasga, volta a funcionar. Como o problema é intermitente, os testes rápidos feitos pelo suporte da operadora raramente o capturam.

Regra prática de diagnóstico: rode um monitoramento contínuo de latência e perda de pacotes (com ferramentas como mtr, SmokePing ou o monitoramento do próprio firewall) por pelo menos uma semana, cruzando os horários de degradação com os horários das reclamações dos usuários. Sem essa série histórica, a conversa com a operadora vira troca de opiniões.

Também merece atenção o equipamento de borda. Firewalls subdimensionados fazendo inspeção profunda de pacotes, VPNs site-to-site com criptografia processada em CPU fraca e regras de QoS mal configuradas adicionam milissegundos preciosos em cada pacote. Em migrações para nuvem, é comum o firewall que atendia bem o tráfego de navegação passar a ser o gargalo quando todo o tráfego de sistemas críticos começa a passar por ele.

DNS e resolução de nomes: o vilão silencioso

Poucos administradores incluem o DNS na investigação de lentidão, e ele é responsável por uma fatia surpreendente dos casos. Depois de uma migração, é frequente sobrarem resquícios da rede antiga: estações que ainda apontam para o servidor DNS interno desligado, registros que resolvem para IPs antigos, sufixos de pesquisa que forçam tentativas de resolução que expiram por timeout antes de tentar o nome correto.

O sintoma clássico é a "primeira vez lenta": abrir o sistema demora 10 ou 15 segundos, mas depois de aberto tudo flui normalmente. Isso acontece porque a resolução inicial do nome está esperando o timeout de um servidor DNS inalcançável (tipicamente 5 segundos por tentativa) antes de consultar o servidor correto. Em ambientes com Active Directory, o problema se agrava: autenticação Kerberos, mapeamento de unidades de rede e aplicação de políticas de grupo dependem de resolução rápida e correta dos registros do domínio.

1. Verifique em cada estação quais servidores DNS estão configurados e se todos respondem — nslookup apontando explicitamente para cada servidor da lista.
2. Meça o tempo de resolução dos nomes usados pelos sistemas migrados; acima de 100 ms de forma consistente, há problema.
3. Procure registros obsoletos apontando para IPs da rede antiga, inclusive em arquivos hosts locais esquecidos de testes da migração.
4. Confirme se o encaminhamento de DNS entre a rede local e a rede da nuvem (via VPN ou link dedicado) está resolvendo as zonas privadas corretamente nos dois sentidos.

A correção costuma ser barata — ajustar escopos de DHCP, limpar zonas, remover encaminhadores mortos — e o ganho percebido pelos usuários é imediato, justamente porque o DNS afeta o início de cada sessão, o momento em que a impressão de lentidão se forma.

Arquitetura da aplicação: quando o problema não é a rede

Há casos em que região, link e DNS estão impecáveis e o sistema continua lento. Aqui o diagnóstico precisa subir de camada: a aplicação foi migrada, mas a arquitetura não foi adaptada. O padrão mais comum é a separação acidental de componentes que precisam estar próximos — o servidor de aplicação ficou na nuvem e o banco de dados ficou no escritório (ou vice-versa), transformando cada consulta SQL em uma viagem pela WAN. Aplicações fazem milhares de consultas por minuto; nenhum link salva essa topologia.

Outro padrão é o dimensionamento por equivalência ingênua: a VM na nuvem foi criada com "os mesmos" vCPUs e memória do servidor físico antigo, ignorando que o servidor tinha discos SSD locais dedicados e a VM recebeu um disco padrão com limite baixo de IOPS. Bancos de dados são sensíveis a isso: um disco que entrega 500 IOPS onde antes havia 20.000 gera lentidão generalizada que parece problema de rede, mas é armazenamento. Métricas de fila de disco e latência de I/O no sistema operacional revelam o gargalo em minutos.

Vale a pena estabelecer uma medição objetiva de ponta a ponta antes de mexer em qualquer coisa: tempo de resposta da aplicação (do clique à tela), tempo de rede (ida e volta até o servidor), tempo de banco (duração das consultas) e tempo de disco. Com esses quatro números, a conversa deixa de ser "está lento" e passa a ser "84% do tempo está sendo gasto em consultas ao banco, que estão lentas por limite de IOPS". Diagnóstico dirigido por medição evita a armadilha mais cara desse cenário: aumentar o tamanho da VM — e a fatura mensal — sem atacar a causa real.

Como transformar diagnóstico em plano de correção

O caminho estruturado para resolver lentidão pós-migração segue uma ordem lógica, do mais barato ao mais invasivo: primeiro medir latência e perda até a região (corrigindo região ou modelo de acesso se necessário), depois validar a qualidade do link e do equipamento de borda, em seguida sanear o DNS, e por fim analisar arquitetura, armazenamento e dimensionamento da aplicação. Pular etapas costuma sair caro — a tentação de "aumentar a máquina" resolve apenas os casos em que o gargalo é realmente CPU ou memória, que são minoria.

Igualmente importante é institucionalizar a medição. Ambientes que saem de uma crise de lentidão sem implantar monitoramento contínuo de latência, perda de pacotes e tempos de resposta voltam a ela meses depois, sem histórico para comparar. Uma linha de base registrada em operação normal transforma o próximo incidente em uma comparação objetiva, e não em um novo mistério.

Esse tipo de diagnóstico é rotina para a Duk Informática & Cloud, que há mais de 18 anos planeja, executa e sustenta ambientes de nuvem para mais de 550 empresas. Como Microsoft Gold Partner e operando data center próprio em Alphaville — com latência de rede local para empresas da região de São Paulo —, a Duk desenha migrações que consideram região, conectividade, DNS e arquitetura antes da virada, e não depois das reclamações. Se o seu sistema ficou lento depois de ir para a nuvem, uma avaliação técnica estruturada identifica a causa em dias, não em meses de tentativa e erro.