Por Que Testes de Carga Realistas Exigem Múltiplos Endereços IP

Por que um Teste de um Único IP Parece Bom, mas Não É

Um teste de carga de um único IP pode parecer bem-sucedido no papel. O script é executado, os painéis são preenchidos e a latência se mantém dentro da faixa alvo. O problema é que os resultados muitas vezes refletem mais a configuração do teste do que o tráfego real de produção.

O tráfego de produção não chega de um único endereço. Um endpoint voltado para o consumidor vê tráfego de milhares de provedores residenciais, operadoras móveis, NATs corporativos e proxies de data center. Cada requisição chega a um nó de borda diferente da CDN, atravessa um middlebox diferente e atinge um fragmento diferente da piscina de conexões. Quando você junta toda essa diversidade em um único IP de origem, toda camada que utiliza o IP de origem como chaveo vestido começa a se comportar de maneiras que não têm equivalente no mundo real.

O resultado são dados de desempenho enganosos que não refletem o comportamento real da produção.

Sete Modos Específicos de Falha em Testes de Carga com IP Único

Testes de carga com IP único podem distorcer ou perder completamente vários comportamentos do mundo real.

1. Limitadores de Taxa Retornam o Número Errado

Limitadores de taxa modernos operam por identificador de origem, e o identificador mais comum é o IP de origem. Algoritmos de bucket de tokens, janela fixa e janela deslizante compartilham essa propriedade. Mesmo equipes que também definem limites com base em tokens de autenticação ou IDs de usuário quase sempre sobrepõem limites por IP; a camada de IP é o que protege a aplicação contra abusos não autenticados. Quando uma carga pesada de usuários virtuais direciona todo o seu tráfego de um único IP, o limitador vê essa carga como um cliente e começa a rejeitar solicitações bem antes da aplicação sentir o estresse. A aplicação parece rápida porque o limitador absorveu a carga. Na produção, a mesma taxa total de solicitações chegaria de milhares de IPs de origem distintos e o limitador permitiria a passagem.

A imagem espelhada também é verdadeira. Se o limitador tem um orçamento generoso por IP, um teste com IP único nunca chega perto do limite agregado no balanceador de carga. A aplicação é sobrecarregada e o limitador nunca entra em ação, ocultando o fato de que o tráfego de produção seria parcialmente descartado.

2. WAFs e Detecção de Bots São Acionados pela Plataforma

Um WAF observando padrões de solicitação uniformes e em rajada de um único IP está fazendo exatamente o trabalho para o qual foi projetado. Ele vê o teste de carga, identifica o tráfego e aplica limitação de taxa, desafios ou bloqueios. Algumas equipes descobrem isso somente quando o teste estabiliza em um número de throughput suspeitosamente arredondado que acaba sendo o limite do WAF. Testes que exercitam caminhos de proteção contra DDoS precisam de fontes diversas por essa mesma razão — essas defesas geralmente são separadas do WAF e ainda mais dependentes da diversidade de IPs de origem para agir realisticamente.

Desabilitar o WAF para o teste “resolve” o sintoma e cria um problema pior: o caminho de teste deixa de corresponder ao caminho de produção. Tráfego de muitos IPs é a única forma de validar que a aplicação funciona enquanto o WAF está ativo nos limites de produção.

3. Seleção de Edge CDN Colapsa para um Nó

CDNs roteiam solicitações para o edge mais próximo do cliente. Com um IP, o tráfego cai em um único POP de edge. O cache se enche ali, todas as solicitações subsequentes atingem o armazenamento aquecido e o teste reporta latência de cache-hit durante toda a execução. Enquanto isso, a longa cauda de edges frios em outras regiões nunca é exercitada. Qualquer um lendo orientações sobre testes de carga em sites com CDN sesim, isso foi destacado: o comportamento do cache é uma função da distribuição da origem, não apenas da taxa de requisição.

O caso oposto também importa. O comportamento de proteção de origem em falha de cache, onde um CDN consolida falhas simultâneas em uma única busca na origem, é invisível a partir de um único IP. Você não pode validar a proteção da origem sem tráfego que o CDN trate como independente.

4. Decisões de Roteamento Anycast e GeoDNS Nunca Disparam

IPs Anycast roteiam pacotes para o data center topologicamente mais próximo. GeoDNS resolve um nome de host para diferentes IPs dependendo da localização do resolvedor. Ambas as decisões ocorrem antes da requisição chegar à sua aplicação. De uma única fonte de teste, você só vê o data center onde o executor do teste está localizado. O roteamento entre regiões, caminhos de failover e latência para regiões distantes permanecem sem teste.

Isso pode ser um ponto cego caro. O teste em uma única região passa, a aplicação é lançada globalmente, e usuários em regiões que o teste nunca cobriu experimentam latência que os painéis nunca mostraram. Testes de carga geo-distribuídos existem precisamente para fechar essa lacuna.

5. Reuso de Pool de Conexões e Coalescência HTTP/2 Distorcem a Taxa de Transferência

Clientes HTTP/2 e HTTP/3 abrem uma conexão por origem e multiplexam requisições nela. De um único IP com um único cliente, a aplicação vê uma conexão de longa duração carregando milhares de streams. A contabilidade por conexão do servidor, janelas de controle de fluxo e comportamento de bloqueio de cabeçalho (head-of-line blocking) refletem essa única conexão. Em produção, você tem milhares de conexões, cada uma com sua própria janela de controle de fluxo, cada uma contribuindo de forma independente para a pressão do escalonador.

O mesmo efeito aparece no balanceador de carga. Métricas por conexão, reaproveitamento por tempo ocioso e comportamento de drenagem em reinício gracioso se comportam de maneira diferente com uma conexão grande versus milhares de conexões pequenas. Você só vê a distribuição real de conexões em produção quando gera carga de muitos clientes distintos através de muitos IPs; um teste que não gera essa distribuição não pode validar nenhum desses aspectos.

6. Exaustão de Porta Efêmera e Source-NAT no Gerador

A faixa de portas efêmeras no Linux fornece a um único IP de origem apenas algumas dezenas de milhares de portas por tupla de destino. Um gerador de carga que empurra altas taxas de conexão a partir de um único IP esgota as portas em segundos, e o teste atinge um platô no equipamento de teste em vez do sistema sob teste. Ambientes em nuvem pioram isso: uma instância EC2 atrás de um gateway NAT compartilha uma pool ainda menor com todo o tráfego que sai pelo mesmo gateway. Praticantes que já enfrentaram isso conhecem como a “parede do teste não conseguir ir mais alto”, e está documentado em extensos artigos sobre exaustão de portas TCP em testes com IP único.

A solução não é apenas geradores mais potentes. É mais carregadores de carga com seus próprios IPs de saída, para que o pool de portas seja replicado em vez de compartilhado.

7. A Observabilidade Colapsa em um Único Balde

Muitos painéis de produção agrupam o tráfego por IP de origem, ASN ou região geográfica. Um teste com IP único cria um único balde, e todo alerta, percentil e métrica de saturação colapsa nesse único balde. Os engenheiros que revisam o teste não conseguem determinar se a latência que veem é uniforme em todas as regiões ou concentrada em uma. Eles também não conseguem reproduzir a segmentação que usam em um incidente real, onde o primeiro instinto é “mostre-me o p99 por região” ou “mostre-me a taxa de erro por ASN.” Tratar métricas de teste de carga da mesma forma que métricas de produção exige diversidade de origem na entrada.

A Armadilha do Egresso na Nuvem

A maioria das equipes que tentam distribuir o teste de carga por várias máquinas executa essas máquinas em uma conta na nuvem, em uma região, atrás de um gateway NAT. O resultado é tecnicamente multi-IP e praticamente uma única fonte. Cada pacote sai com um IP de origem do mesmo ASN conhecido do provedor de nuvem. WAFs, fornecedores de detecção de bots e provedores de borda mantêm dados de reputação em faixas de egresso de nuvem; muitos tratam o tráfego dessas faixas com escrutínio extra por padrão.

Isso importa em duas direções. Primeiro, a aplicação vê o teste como tráfego de data center, que é roteado de forma diferente do tráfego residencial em cada CDN e em muitas implementações de anycast. Segundo, seus testes rodam na mesma vizinhança de rede que cargas de trabalho concorrentes, o que torna a latência base barulhenta e a reprodutibilidade pior. Configurações genéricas de teste de carga AWS podem resolver a escala, mas não a diversidade da fonte.

O realismo exige que a rede de injeção de carga abranja mais de uma nuvem, múltiplas regiões e idealmente uma mistura de saída de data center e qualidade residencial (por exemplo, combinando dois provedores de nuvem com uma rede de saída residencial ou de operadora móvel) para que a mistura de IP/geolocalização que sua aplicação vê durante o teste se assemelhe àquela que ela vê em produção.

Como Realmente é a Distribuição Realista de IPs

“Muitos IPs” não é um alvo. O alvo é uma distribuição que corresponda à produção. Três propriedades importam.

Distribuição geográfica. Se 30% dos usuários estão na EMEA, 30% na APAC, e 40% nas Américas, o teste precisa injetar em proporções aproximadas. Isso é o que torna o roteamento anycast realista e a seleção da borda do CDN. Também evidencia as caudas lentas que um teste em região única oculta.

Diversidade de rede. Misturar ISPs residenciais, operadoras móveis e redes de data center expõe a aplicação a toda a gama de comportamentos de MTU, perda de pacotes e middlebox que a produção vê. Um teste que roda inteiramente em redes de data center não percebe como redes móveis renegociam TLS ou como NAT de nível operadora agrupa conexões.

Volume por IP que se assemelha a um usuário real. Um IP realista não gera mil requisições por segundo. Ele gera a taxa de requisições de alguns usuários reais atrás de um NAT, mais um lote ocasional de um usuário avançado. Simulação de usuário virtual que respeita o volume por IP mantém o limite de taxa e as interações com WAF do lado correto do realismo.

IP Único vs IP Distribuído: Quando Cada Um é Adequado

Cenários do Mundo Real

Cenário 1: um Checkout de Ecommerce que “Passa” até a Black Friday

Considere um padrão comum. Um varejista de roupas realiza um teste de carga com muitos usuários virtuais a partir de uma única região de nuvem. A latência p95 do checkout retorna confortavelmente dentro do SLO. Na Black Friday, o p95 salta para a faixa de segundos múltiplos e o abandono do carrinho aumenta.

Duass coisas tendem a surgir nesse tipo de análise pós-incidente. O CDN serviu a maior parte do tráfego de teste de um único POPque permaneceu aquecido durante toda a execução. Em produção, o tráfego se espalhou por vários POPs, vários dos quais iniciaram a frio durante o pico. O segundo problema geralmente é o limite de taxa por IP em um serviço downstream. O teste atingiu o teto para um IP instantaneamente e permaneceu abaixo dele durante toda a execução, o que mascarou um caminho de crescimento ilimitado no cache subjacente. Concurrent HTTP versus concurrent browsers explica por que a forma do conjunto é tão importante quanto o número de usuários.

Cenário 2: uma API Fintech que Falha na Auditoria de Segurança

Considere uma equipe de API de pagamentos que realiza testes de carga em seu endpoint de autorização a partir de um pequeno conjunto de executores de testes na nuvem. O endpoint mantém o RPS alvo com latência previsível. Semanas depois, uma auditoria externa de segurança atinge o mesmo endpoint a partir de um padrão de origem distribuída e dispara uma regra de “fan-out anômalo” no WAF. O throughput colapsa e os logs da auditoria mostram pausas de bloqueio que o teste de carga nunca exibiu.

A equipe estava testando a aplicação através do WAF, mas nunca com um formato de tráfego que o WAF considerasse suspeito. A auditoria foi a primeira vez que o WAF realmente foi ativado. Migrar para um teste de carga multi-IP, multi-ASN reproduz a lentidão em pré-produção, onde a regra pode ser ajustada antes do lançamento. Este é também o modo de falha por trás de grande parte das orientações sobre por que o teste de carga HTTP tradicional não é suficiente para stacks modernos.

Cenário 3: um Aplicativo SaaS com uma Configuração Anycast Silenciosa e Incorreta

Considere uma empresa SaaS B2B que move uma API pública para trás de um balanceador de carga anycast e executa a lista de verificação padrão para preparação de testes de carga. Testes de uma região passam sem problemas. Após o lançamento, clientes em uma região distante reportam latência mediana uma ordem de magnitude maior do que o esperado. A configuração do anúncio anycast revelou-se incorreta, e o tráfego daquela região está sendo roteado para um POP distante ao invés do mais próximo. Nenhum teste de região única poderia ter detectado isso porque a configuração incorreta só importava quando o resolvedor estava fora da região de origem do teste.

Este é o caso canônico para testes geograficamente distribuídos. A correção da camada de roteamento não é visível a partir de uma única fonte.

Como o LoadView Lida com Testes de Carga Multi-IP

O LoadView foi construído em torno deste problema. A rede de injeção de carga geo-distribuída da plataforma abrange dezenas de locais na América do Norte, EMEA, APAC e América do Sul. Cada local é uma região de nuvem separada com seu próprio espaço de IPs de saída, então quando um teste é executado em todos eles, a distribuição da fonte at a aplicação alvo reflete a forma geográfica e de rede dos usuários reais em vez de um agrupamento de endereços de saída na nuvem.

Duas escolhas de design são importantes para os modos de falha acima. Primeiro, o LoadView executa testes de carga de aplicação web em navegadores reais, então a contagem de conexões, o comportamento de coalescência do HTTP/2 e a contabilização por conexão no servidor parecem usuários reais em vez de um cliente de protocolo simplificado. Segundo, os injetores de carga são gerenciados do lado da nuvem, o que significa que não há um ambiente para a equipe provisionar, nem um pool de portas de gateway NAT para supervisionar, e nenhuma tentação de rodar todos os geradores em uma região só porque o orçamento permitia isso.

A combinação importa mais do que qualquer peça isolada. Navegadores reais de um único IP ainda disparariam o limite de taxa e as distorções do WAF descritas acima. Muitos IPs rodando clientes só de protocolo ainda representariam mal o pool de conexões e o comportamento do HTTP/2. Navegadores reais conduzindo testes de carga a partir de múltiplos endereços IP em várias regiões reproduzem tanto a forma da rede quanto a forma do cliente que a produção vê.

Uma ressalva para ajustar as expectativas corretamente: a rede geodistribuída do LoadView é construída com base em regiões de nuvem, o que oferece grande alcance geográfico e diversificação de ASN, mas não saída residencial ou de operadoras móveis imediatamente disponível. Para cargas de trabalho onde uma parte significativa do tráfego de produção vem dessas redes (aplicativos consumidores com grande uso móvel, por exemplo), o padrão correto é combinar os injetores em nuvem regionais do LoadView com uma fonte residencial ou de operadora que você controle separadamente. A seção anterior sobre distribuição realista de IP trata a diversidade de rede como uma propriedade do plano de teste, não de uma ferramenta única.

Lista de Verificação para Implementação

Antes do próximo teste significativo, siga os passos abaixo. O primeiro passo conecta esta lista à discussão sobre distribuição de fontes acima — a forma de produção que você mapear aí é o alvo contra o qual todo passo seguinte será dimensionado.

Mapeie a distribuição das fontes de produção. Extraia uma semana de logs de acesso e categorize as requisições por região, ASN e densidade de prefixo de IP. Uma linha simples como awk '{print $1}' access.log | sort -u | wc -l te dá a contagem de IPs únicos a partir de um log combinado do NGINX ou do Apache; passe isso por uma consulta GeoIP/ASN para obter as divisões regionais e de ASN. A forma dessa distribuição é o alvo que seu teste deve replicar. Se você já tem dados de teste de usuários concorrentes, use-os como base.

Identifique os limites de IP por stack. Rate limiters na borda, o gateway da API, a aplicação e quaisquer APIs de terceiros. Observe o orçamento em cada um. Qualquer teste que não exceda o orçamento mais baixo em pelo menos um IP não está validando esse limite.

Escolha regiões de injeção para corresponder ao peso da produção. Se 60 por cento do tráfego vem da América do Norte, 60 por cento dos geradores pertencem a essa região. Não faça uma rotação excessiva para “testar todas as regiões igualmente” se a produção for desequilibrada.

Confirme a diversidade de ASN de saída. Se todo gerador estiver em uma nuvem, o teste ainda apresenta o problema de saída na nuvem. No mínimo, misture regiões; melhor ainda, misture provedores (por exemplo, combine dois provedores de nuvem com uma rede de saída residencial ou de operadora móvel).

Divida o relatório por origem. Latência, taxa de erro e throughput devem ser detalhados por região e ASN. Se a divisão colapsar para um único grupo, o teste foi efetivamente de fonte única.

Reproduza uma regra WAF conhecida disparando. Execute um pequeno teste projetado para acionar uma regra WAF que você entenda, e confirme que ela é disparada. Se não for, o tráfego de teste não se assemelha ao de produção para o seu WAF, e o restante dos resultados é duvidoso.

FAQ

Por que testes de carga a partir de um único IP produzem números errados?

O tráfego de produção chega de muitos IPs em diversas redes. Limitadores de taxa, WAFs, bordas de CDN, roteadores anycast e pools de conexão todos se comportam de forma diferente quando o tráfego compartilha uma única fonte. Um teste com IP único estressa caminhos que usuários reais nunca acessam e pula caminhos que usuários reais acessam sempre, então os números de latência e throughput refletem a configuração do teste em vez do sistema.

IP Spoofing no JMeter é a mesma coisa que Teste de Carga Multi-IP?

Não exatamente. O IP spoofing do JMeter rotaciona o IP de origem no nível do sistema operacional, mas os pacotes ainda saem de uma máquina com uma rota padrão, um ASN e uma localização geográfica únicos. CDNs, roteadores anycast e muitos WAFs se baseiam no caminho da rede e ASN, não apenas no endereço de origem da camada 3. O verdadeiro teste de carga multi-IP distribui os geradores por redes e regiões separadas.

Quantos IPs são necessários para um teste de carga realista?

Não existe um número único. O alvo correto é ter diversidade suficiente de IPs e geográfica para que nenhum IP de origem individual exceda o limite de taxa por IP que você deseja validar, e que a borda da CDN e a distribuição de roteamento correspondam aproximadamente à mistura de tráfego da produção. Para a maioria dos aplicativos voltados para consumidores, isso significa dezenas a centenas de IPs de origem distintos em várias regiões.

Quando o teste de carga com IP único é aceitável?

O teste com IP único é adequado para verificações a nível de componente: um serviço backend por trás de um balanceador de carga interno sem limites por IP, um benchmark de driver de banco de dados ou um teste básico onde você só se importa se a resposta está correta. Em quase todos os casos, não é suficiente para validação de desempenho ponta a ponta de um endpoint acessível pela internet.

O NAT significa que um único IPpode representar muitos usuários?

NAT e CGNAT comprimem muitos usuários reais atrás de um endereço, então os limites de taxa por IP em produção já consideram algum agrupamento. O problema com testes de IP único não é que um IP não possa representar muitos usuários, mas que um IP não pode representar a distribuição de usuários que você realmente tem. O tráfego real abrange milhares de egressos NAT, não apenas um.

Planeje um Teste de Carga que Retorne Números que Você Possa Defender

Se o tráfego do teste não corresponder ao formato de origem da produção, os resultados do teste não descrevem a produção. Testes de carga distribuídos por IPs em várias regiões não são apenas desejáveis para planejamento de capacidade, validação de segurança ou correção de roteamento de borda. Testes de carga distribuídos ajudam a garantir que seus testes reflitam como os usuários reais acessam sua aplicação. Comece com a lista de verificação acima, divida cada relatório por origem e valide suas suposições sobre o comportamento do WAF e limites de taxa antes do próximo lançamento, e não durante ele.