Teste de carga com k6 em Cloud Server sem riscos

Resposta direta

Para fazer teste de carga com k6 em Cloud Server, use um servidor separado da aplicação, instale o k6 pelo repositório oficial e crie um script que represente jornadas reais. Comece com poucos usuários virtuais, valide autenticação e respostas, depois aumente a carga em rampas controladas. Defina thresholds para taxa de erro e latência, como http_req_failed < 1% e p(95) < 500 ms. Durante a execução, acompanhe CPU, memória, disco, rede, banco de dados e serviços externos. Nunca inicie um teste intenso contra produção sem autorização, janela definida, limites de tráfego e plano de interrupção. O resultado útil não é o maior número de requisições, mas a capacidade sustentável antes de erros e latência ultrapassarem os objetivos do serviço.

Resumo rápido

• Execute o k6 em um Cloud Server separado do sistema que será testado.
• Comece com 1 a 5 usuários virtuais e aumente a carga em etapas previsíveis.
• Use cenários para modelar carga constante, rampas, picos e taxa de chegada.
• Defina thresholds antes do teste, não depois de observar os resultados.
• Monitore CPU, RAM, conexões, disco, rede e banco durante toda a execução.
• Evite dados reais, credenciais pessoais e endpoints destrutivos nos scripts.
• Interrompa o teste se erros, filas ou latência ameaçarem usuários reais.

Planeje o teste sem colocar a produção em risco

Um teste de carga começa antes da instalação do k6. Primeiro, transforme a dúvida da equipe em uma hipótese mensurável. Em vez de perguntar se a API aguenta bastante tráfego, defina algo como: sustentar 120 requisições por segundo durante 15 minutos, com menos de 1% de erros e latência p95 abaixo de 500 ms. Esse objetivo orienta o script, o volume de usuários virtuais e os critérios de aprovação.

Separe gerador e sistema testado

O Cloud Server que executa o k6 não deve hospedar a aplicação testada. Se ambos compartilharem CPU, rede ou disco, o gerador poderá competir com o sistema e distorcer o resultado. Para uma API pequena, um gerador com 2 vCPUs, 4 GB de RAM e rede de 1 Gbps costuma ser um ponto inicial razoável. Isso não garante uma taxa específica, pois TLS, tamanho das respostas, lógica JavaScript e número de conexões alteram o consumo.

A localização também muda o que está sendo medido. Um gerador em São Paulo contra uma API no mesmo estado ajuda a observar a capacidade do serviço com baixa latência. Um segundo teste a partir dos Estados Unidos mede uma experiência diferente, que inclui distância, trânsito entre operadoras e possíveis rotas internacionais. Quem ainda está definindo a arquitetura pode consultar a análise sobre Cloud Server para APIs e automações antes de escolher onde posicionar aplicação, banco e gerador.

Defina limites antes da primeira execução

Crie uma ficha com ambiente, horário, responsáveis, duração, taxa máxima e comando de interrupção. Em produção, combine um limite automático, por exemplo, abortar se a taxa de falhas superar 5% por 30 segundos ou se o banco atingir 85% de CPU de forma sustentada. Reserve contas de teste, use dados sintéticos e bloqueie rotas como exclusão de usuário, envio de e-mail e cobrança.

Três ensaios ajudam a reduzir riscos. Faça um smoke test com 1 usuário por 1 minuto, um teste intermediário com 20 usuários por 5 minutos e somente então avance para a carga planejada. Também confirme se CDN, WAF, rate limiting e cache fazem parte do escopo. Desativá-los pode facilitar o diagnóstico, mas cria um experimento diferente daquele enfrentado pelos usuários.

Instale o k6 e prepare o Cloud Server

O k6 pode ser instalado em distribuições Linux, executado em contêiner ou incorporado a um pipeline de integração contínua. Em um Cloud Server Ubuntu ou Debian, prefira o repositório oficial. Pacotes copiados de fontes desconhecidas aumentam o risco de executar binários adulterados com acesso à rede interna e às variáveis do ambiente.

Instalação no Ubuntu ou Debian

Uma instalação típica usa os comandos abaixo. Consulte a documentação oficial caso a distribuição ou a forma de assinatura do repositório tenha mudado.

sudo apt-get update
sudo apt-get install -y gpg ca-certificates curl
curl -s https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main' | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install -y k6
k6 version

Depois da instalação, crie um usuário sem privilégios administrativos para executar os testes. Salve scripts em um diretório versionado e forneça tokens por variável de ambiente, nunca dentro do arquivo JavaScript. Um teste pode receber a URL com k6 run -e BASE_URL=https://staging.exemplo.com smoke.js. Segredos podem vir de um cofre ou do mecanismo protegido do pipeline, sem aparecer no histórico do Git.

Dimensionamento do gerador de carga

O consumo do k6 depende mais da quantidade de iterações, conexões e processamento do script do que do número isolado de usuários virtuais. Um cenário de 100 usuários que aguarda dois segundos entre ações pode ser mais leve que outro com 20 usuários em loop contínuo. Comece com 2 vCPUs e 4 GB de RAM para testes pequenos, acompanhe o processo com top, vmstat 1 e ss -s, depois aumente para 4 vCPUs e 8 GB se o gerador chegar perto de 80% de CPU ou começar a usar swap.

Confira também limites de arquivos e portas efêmeras. ulimit -n mostra quantos descritores o processo pode abrir. Milhares de conexões curtas podem esgotar portas locais ou elevar o número de sockets em TIME_WAIT. Antes de alterar parâmetros do kernel, confirme se conexões persistentes e tempos de espera do script representam o cliente real. Ajustar o servidor para esconder um modelo de tráfego incorreto produz um número bonito, mas pouco útil.

Crie scripts e cenários de carga realistas

Um bom script não tenta reproduzir cada detalhe da interface. Ele representa as operações que consomem recursos relevantes, preservando a proporção entre leitura, escrita, autenticação e espera humana. Se 70% do tráfego consulta produtos, 20% abre detalhes e 10% cria pedidos, não faz sentido executar apenas o endpoint mais simples em um loop sem pausa.

Comece com uma jornada simples

O exemplo abaixo valida status, conteúdo e tempo de resposta. A variável BASE_URL mantém o mesmo script utilizável em homologação e produção autorizada.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 5,
  duration: '2m',
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const baseUrl = __ENV.BASE_URL;
  const response = http.get(`${baseUrl}/api/products?limit=20`, {
    tags: { endpoint: 'list_products' },
  });

  check(response, {
    'status 200': (r) => r.status === 200,
    'retorna produtos': (r) => r.json('items.length') > 0,
  });

  sleep(1);
}

Execute primeiro contra homologação com k6 run -e BASE_URL=https://staging.exemplo.com products.js. O check informa se a resposta atende às condições funcionais, enquanto o threshold decide se o teste como um todo passou. Eles não são equivalentes. Um check pode falhar em algumas iterações sem interromper o processo, e um threshold pode encerrar a execução com código de saída diferente de zero.

Modele rampas, carga constante e picos

Para observar aquecimento de cache e saturação gradual, use o executor ramping-vus. Um desenho prático sobe de 0 para 20 usuários em 2 minutos, mantém 20 por 5 minutos, sobe para 60 em mais 3 minutos e reduz a zero em 2 minutos. Já constant-arrival-rate é mais adequado quando o objetivo é manter 100 iterações por segundo, mesmo que a latência aumente.

export const options = {
  scenarios: {
    api_flow: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 20 },
        { duration: '5m', target: 20 },
        { duration: '3m', target: 60 },
        { duration: '2m', target: 0 },
      ],
      gracefulRampDown: '30s',
    },
  },
};

Em microsserviços, distribua tags por rota e operação para não misturar uma consulta de 30 ms com um relatório de 2 segundos. A discussão sobre VPS para APIs e microsserviços no Brasil ajuda a relacionar latência, localização e separação de componentes ao desenho do cenário.

Execute o teste e controle a geração de tráfego

Executar o comando é a parte simples. O trabalho está em garantir que o tráfego enviado corresponda ao cenário aprovado e possa ser interrompido rapidamente. Antes de começar, registre a versão da aplicação, configuração do banco, quantidade de réplicas, estado do cache e versão do script. Sem isso, duas execuções com o mesmo número de usuários podem medir ambientes diferentes.

Faça uma sequência de validação

Comece com uma chamada manual usando curl e confirme DNS, certificado TLS, cabeçalhos e autenticação. Depois rode k6 run --vus 1 --duration 30s script.js. Se a taxa de erro não for zero nessa etapa, aumentar usuários só multiplica um defeito de configuração. Um token expirado, uma URL errada ou um payload inválido pode parecer indisponibilidade da aplicação.

Na segunda execução, use 5 a 10 usuários durante 2 minutos. Observe se a taxa de requisições condiz com os tempos de espera. Dez usuários, respostas de 200 ms e sleep(1) não produzem 50 requisições por segundo, pois cada iteração leva aproximadamente 1,2 segundo, além do processamento local. Se a meta exige uma taxa fixa, use um executor baseado em chegada e configure preAllocatedVUs suficientes.

Uma execução controlada pode usar:

BASE_URL=https://staging.exemplo.com k6 run \
  --summary-export=resultados.json \
  api-flow.js

O arquivo de resumo facilita comparar execuções, mas não substitui séries temporais completas. Para testes longos, envie métricas a uma plataforma compatível ou armazene a saída em um sistema de observabilidade.

Proteja APIs, bancos e serviços dependentes

Mapeie dependências que não devem receber carga. Um fluxo de cadastro pode disparar e-mails, SMS, webhooks e antifraude. Em homologação, substitua esses serviços por mocks ou contas de teste. Em produção, limite as operações a endpoints seguros e tenha uma lista clara de rotas proibidas.

Defina uma pessoa com autoridade para interromper o teste. Ctrl+C inicia a finalização local, mas a equipe também precisa observar filas, réplicas e banco por alguns minutos após a parada. Mensagens assíncronas continuam sendo processadas. Se a API responder rápido enquanto acumula 200 mil eventos em uma fila, o teste não demonstrou capacidade sustentável.

Interprete métricas, thresholds e gargalos

A saída padrão do k6 apresenta duração das requisições, falhas, quantidade de iterações, dados transferidos e tempos de cada etapa da conexão. Não reduza a análise à média. Uma média de 180 ms pode esconder 5% das respostas acima de 2 segundos, justamente a parcela percebida como lentidão pelos usuários.

Leia percentis em vez de olhar apenas a média

Use p90, p95 e p99 de acordo com o objetivo do serviço. Se o p95 foi 480 ms, isso significa que 95% das observações ficaram em até 480 ms e 5% levaram mais tempo. Não significa que todos os usuários receberam resposta em 480 ms. Para uma API interna, um threshold possível é p(95)<500. Para checkout ou autenticação, a equipe pode exigir outro limite conforme o contrato do produto.

Analise http_req_waiting, que representa principalmente o tempo até o primeiro byte, junto de http_req_connecting e http_req_tls_handshaking. Conexão e TLS elevados podem indicar ausência de reutilização, proxy sobrecarregado ou distância de rede. Espera elevada com conexão estável costuma apontar para aplicação, fila, banco ou serviço externo. http_req_failed precisa ser segmentado por status e endpoint, pois respostas 429 indicam rate limiting, enquanto 500 e 503 sugerem falhas diferentes.

Uma configuração mais completa pode exigir p95 abaixo de 500 ms, p99 abaixo de 1,2 segundo e menos de 1% de falhas:

thresholds: {
  http_req_failed: ['rate<0.01'],
  http_req_duration: ['p(95)<500', 'p(99)<1200'],
  checks: ['rate>0.99'],
}

Relacione resultados com a infraestrutura

Compare a linha temporal do k6 com CPU, memória, garbage collection, conexões de banco, cache hit ratio, filas e IOPS. Um painel com Prometheus e Grafana permite enxergar se o p95 aumentou no mesmo instante em que o pool de conexões chegou ao limite. O conteúdo sobre VPS para monitoramento com Grafana e Prometheus explica como separar coleta, retenção e visualização.

Considere três exemplos. CPU em 95% e fila crescente sugere saturação de processamento. CPU em 40%, mas pool de banco totalmente ocupado, aponta para concorrência ou consultas lentas. CPU e banco folgados com tráfego limitado a 1.000 requisições por segundo podem indicar gargalo no balanceador, firewall ou rede. O k6 mostra o sintoma externo. O diagnóstico exige telemetria do sistema testado.

Resolva erros comuns e melhore o experimento

Resultados inconsistentes não significam necessariamente que o k6 falhou. Cache frio, autoscaling, tarefas agendadas, variação de rede e dados diferentes podem alterar cada rodada. Repita o cenário pelo menos três vezes em condições documentadas e compare percentis, erros e taxa efetiva. Descarte uma execução apenas quando houver uma razão registrada, como deploy durante o teste ou indisponibilidade de um serviço externo.

Descubra se o gargalo está no gerador

Monitore o próprio Cloud Server do k6. Se a CPU ficar acima de 90%, houver swap ou o processo não conseguir sustentar a taxa configurada, você pode estar medindo o gerador. Em cenários de taxa de chegada, observe mensagens sobre iterações descartadas. Elas indicam que não havia usuários virtuais disponíveis para iniciar novas iterações no ritmo definido.

A primeira correção é simplificar o script. Evite gerar payloads grandes, fazer criptografia desnecessária ou processar respostas completas quando basta validar dois campos. A segunda é aumentar preAllocatedVUs, desde que CPU e memória comportem a mudança. A terceira é distribuir a carga entre múltiplos geradores. Nesse caso, sincronize relógios com NTP, use o mesmo script e agregue resultados sem somar percentis diretamente.

Erros como connection reset by peer, timeout e 429 precisam de contexto. Um reset pode vir do proxy, do servidor ou de um equipamento intermediário. Timeout pode refletir limite do cliente menor que o tempo real da operação. Resposta 429 pode ser o comportamento correto do rate limiter. Examine logs e identificadores de requisição antes de classificar tudo como falha de capacidade.

Torne os resultados reproduzíveis

Versione script, massa de dados e parâmetros. Salve a saída com data, commit da aplicação, região do gerador e configuração do sistema testado. Para um ensaio de 30 minutos, registre também os cinco minutos anteriores e os dez posteriores. Assim, filas e processos assíncronos não desaparecem do relatório.

Mude uma variável por rodada. Se a equipe aumentar CPU, réplicas, cache e pool de banco ao mesmo tempo, o ganho não poderá ser atribuído a uma decisão específica. Um ciclo melhor testa a linha de base, ajusta o pool de 20 para 40 conexões, repete o cenário e compara p95, throughput, erros e carga do banco. Essa disciplina transforma teste de carga em ferramenta de engenharia de capacidade.

Recomendações por perfil

Dev solo e ambiente de desenvolvimento

Para um projeto individual, comece com um Cloud Server de 2 vCPUs e 4 GB de RAM dedicado ao k6. Use homologação com dados sintéticos e scripts curtos de 2 a 5 minutos. Faça um smoke test com 1 usuário, depois execute 10 e 25 usuários em rampas. Defina ao menos dois thresholds: falhas abaixo de 1% e p95 adequado à aplicação, como 500 ou 800 ms. Salve scripts no Git, mas forneça URL e token por variável de ambiente. O objetivo inicial é detectar regressões claras, não descobrir um limite absoluto com precisão de laboratório.

Equipe de produto ou plataforma

Uma equipe que publica APIs semanalmente deve integrar testes pequenos ao pipeline e reservar testes maiores para um ambiente controlado. Um gerador com 4 vCPUs e 8 GB oferece margem para cenários moderados, desde que seu uso seja monitorado. Modele jornadas separadas para leitura, escrita e autenticação, com tags por endpoint. Exporte métricas para a plataforma de observabilidade e associe cada execução ao commit implantado. Thresholds podem bloquear uma entrega quando p95 ou erro ultrapassarem o orçamento acordado. Testes contra produção precisam de aprovação, janela, comunicação e rollback operacional.

Produção crítica e testes recorrentes

Para serviços críticos, trate o teste como mudança operacional. Use múltiplos geradores quando uma única máquina não sustentar a taxa, valide sincronização de relógio e mantenha observabilidade sobre aplicação, banco, filas e balanceadores. Faça ensaios de capacidade sustentada por 30 a 60 minutos, além de picos curtos e testes de recuperação. Defina limites de interrupção independentes dos thresholds finais, como banco acima de 85% de CPU, fila acima de 50 mil mensagens ou erro superior a 5% por 30 segundos. Registre responsáveis, dependências externas e impacto esperado. A aprovação deve considerar estabilidade depois do teste, não apenas o throughput máximo alcançado.