A campanha foi planejada com três meses de antecedência. O time comercial ligou para os melhores clientes, o marketing preparou o disparo, a operação reforçou o estoque. Às nove da manhã do dia combinado, o e-mail saiu para toda a base. Às nove e quatro, o sistema parou de responder.
Quarenta minutos depois, com tudo de volta ao ar, veio a explicação técnica de sempre: um volume de acessos acima do esperado. Ninguém consegue dizer quanto era o esperado, porque esse número nunca foi definido. O prejuízo, esse, todo mundo consegue calcular.
A tese deste texto é que capacidade não é assunto de emergência: é assunto de planejamento, e um planejamento razoavelmente barato. Sistemas caem em datas importantes porque nunca foram medidos, não porque o volume era imprevisível. E medir custa uma fração do que custa uma manhã fora do ar no pior dia possível.
O que é capacidade de um sistema?
Capacidade é a quantidade de trabalho simultâneo que um sistema consegue atender mantendo tempo de resposta aceitável. Ela é expressa em números concretos, como pessoas usando ao mesmo tempo, pedidos por minuto ou consultas por segundo, sempre com um limite de tempo de resposta junto. Sem o tempo de resposta, o número não significa nada.
Essa última parte costuma passar batido. Um sistema que atende mil pessoas simultâneas levando dezoito segundos por página tecnicamente não caiu, mas comercialmente já morreu: o cliente desiste antes. Por isso a pergunta certa nunca é quantos usuários o sistema suporta, e sim quantos usuários ele atende em menos de dois segundos.
Vale distinguir capacidade de desempenho. Desempenho é o quão rápido o sistema responde com pouca gente usando. Capacidade é o quanto esse desempenho se degrada conforme a fila cresce. São problemas diferentes, com causas diferentes, e um sistema pode ser rápido no dia a dia e frágil no pico, o que engana bastante.
Por que o sistema cai justamente no dia mais importante?
Porque a curva de degradação não é suave. A intuição de quem gerencia diz que o dobro de acessos deveria significar o dobro de lentidão, mas não é assim que funciona. O sistema absorve o crescimento quase sem sinal até chegar a um ponto em que algum recurso satura, e a partir dali o colapso é rápido.
Esse ponto de saturação quase nunca está onde as pessoas procuram. Na maioria dos casos que analisamos, o gargalo não é a máquina do servidor: é o banco de dados, uma consulta específica que funciona bem com dez usuários e trava com quinhentos, ou uma integração com um sistema de terceiro que tem limite próprio e começa a recusar chamadas.
Some a isso a natureza dos picos de negócio. Eles não são graduais. Um disparo de e-mail, um anúncio no horário nobre ou o primeiro dia de uma promoção concentram em minutos um volume que normalmente levaria um dia. Sistemas dimensionados pela média são justamente os que quebram na hora em que a empresa mais precisa deles.
Como saber, antes, quanto o seu sistema aguenta?
Medindo, e não estimando. O caminho tem três etapas, e nenhuma exige que o gestor entenda de tecnologia.
A primeira é definir a meta em linguagem de negócio. Não peça ao time que o sistema aguente mais. Diga que no dia da campanha esperamos oito mil visitantes na primeira hora, com pico de mil e duzentos simultâneos, e que nenhuma página pode passar de dois segundos. Meta sem número não é meta, é desejo.
A segunda é reproduzir esse cenário em ambiente controlado, com um teste de carga. A terceira é observar o sistema com instrumentação adequada durante o teste, para descobrir qual peça satura primeiro, o que depende da mesma disciplina que tratamos ao falar de monitoramento de sistemas. Testar sem enxergar o interior mostra que o sistema caiu, mas não por quê, e aí o ensaio serviu de pouco.
O que é um teste de carga e o que ele responde?
Teste de carga é um ensaio em que um programa simula centenas ou milhares de pessoas usando o sistema ao mesmo tempo, reproduzindo o caminho real que elas percorreriam, enquanto se mede o tempo de resposta e o consumo de recursos.
A parte que separa um teste útil de um teste decorativo é o realismo do roteiro. Simular mil pessoas abrindo a página inicial não prova quase nada, porque a página inicial costuma ser a mais leve e a mais cacheada. O ensaio que vale reproduz a jornada completa: buscar um produto, abrir o detalhe, adicionar ao carrinho, aplicar cupom, pagar. É no cupom e no pagamento que os sistemas costumam morrer.
Um bom teste responde a quatro perguntas objetivas: quantos usuários simultâneos o sistema atende dentro da meta, em que ponto ele começa a degradar, qual componente satura primeiro, e o que acontece quando o limite é ultrapassado. Essa última é a mais negligenciada. Um sistema bem construído degrada com dignidade, colocando gente em fila com aviso, em vez de simplesmente cair para todo mundo.
O que fazer quando o teste mostra que não aguenta?
Boa notícia: descobrir isso em ensaio é exatamente o objetivo. As correções costumam seguir esta ordem de custo e benefício:
- Corrigir os gargalos pontuais. Normalmente duas ou três consultas ao banco de dados respondem pela maior parte do problema. É o ajuste mais barato e o de maior efeito, e às vezes multiplica a capacidade sem trocar nada de infraestrutura.
- Guardar em cache o que não muda. Catálogo, páginas institucionais e listagens raramente precisam ser recalculados a cada acesso. Cache bem aplicado tira carga sem alterar a experiência.
- Separar o que é urgente do que pode esperar. Enviar e-mail de confirmação, gerar nota e atualizar relatório não precisam acontecer enquanto o cliente espera a tela. Empurrar isso para uma fila libera o caminho crítico.
- Aumentar a infraestrutura. É o mais rápido de executar e o mais caro de manter. Funciona, mas trata o sintoma, e a fatura permanece depois que o pico passa, assunto que detalhamos ao falar de custo de nuvem.
- Repensar a arquitetura. Último recurso, para quando o limite é estrutural. Aqui a decisão se aproxima do dilema que discutimos em otimizar ou reescrever um sistema lento.
Escalar automaticamente na nuvem resolve o problema?
Ajuda bastante, mas não é a solução mágica que costumam vender. Vale entender os três limites.
O primeiro é o tempo de reação. Criar novas máquinas leva minutos, e um pico causado por disparo de e-mail acontece em segundos. Quando a capacidade extra sobe, o pior momento já passou. Por isso, para eventos com data marcada, a prática correta é aumentar a capacidade antes, de forma programada, e deixar o automático apenas como rede de segurança.
O segundo é que nem tudo escala. Servidores de aplicação se multiplicam com facilidade; o banco de dados central, não. Se o gargalo está nele, adicionar dez máquinas na frente apenas faz a fila chegar mais rápido ao mesmo funil.
O terceiro é o custo. Escalonamento automático sem limite superior definido já produziu faturas memoráveis, especialmente quando o pico veio de robô e não de cliente. Configure teto e alerta, como parte da higiene básica de quem usa nuvem para empresas.
Como se preparar para uma data de pico em oito semanas?
Um cronograma realista, contando de trás para frente a partir do dia grande. Oito semanas antes, defina a meta numérica com o time comercial, porque é ele que sabe quantas pessoas serão impactadas. Seis semanas antes, faça o primeiro teste de carga e aceite que o resultado vai ser ruim: essa é a função dele.
Quatro semanas antes, corrija os gargalos encontrados e teste de novo, agora com meta de bater o número. Duas semanas antes, congele mudanças que não sejam correção e faça o ensaio final, incluindo o teste do plano de emergência, que precisa ter sido escrito nesse meio tempo.
Na semana do evento, aumente a capacidade de forma programada, combine quem fica de plantão e defina antes qual funcionalidade pode ser desligada para salvar a operação principal. Ter essa lista pronta, decidida com cabeça fria, é o que separa uma degradação controlada de uma queda total. Vale lembrar que velocidade percebida também depende do que roda no navegador, tema que tratamos em velocidade do site.
Capacidade se descobre em ensaio, nunca em produção
Toda empresa que já perdeu uma data importante por indisponibilidade tinha, no fundo, a mesma informação faltando: ninguém sabia o número. Não havia meta, não havia medição e não havia plano para o momento em que o limite fosse ultrapassado. O time não foi incompetente: ele foi surpreendido por algo que dava para ensaiar.
O investimento em um ciclo de teste de carga é modesto e concentrado em poucas semanas. Comparado ao faturamento de um único dia de campanha grande, costuma ser irrelevante. E o subproduto é permanente: os gargalos corrigidos continuam corrigidos, e o sistema fica mais rápido no dia comum também.
Na DevCore, preparamos sistemas para datas de pico dentro dos nossos serviços de DevOps, do teste de carga ao plano de contingência do dia. Se a sua empresa tem uma data marcada no calendário e ninguém sabe dizer quanto o sistema aguenta, fale com o nosso time enquanto ainda dá tempo de ensaiar.
Perguntas frequentes sobre pico de acesso
Quanto tempo antes da data devo começar a preparação?
Oito semanas é uma folga confortável para um sistema de porte médio, porque permite dois ciclos de teste e correção. Com quatro semanas ainda dá para fazer um teste e corrigir o mais crítico. Com menos de duas, o realista é apenas aumentar a capacidade de forma preventiva e preparar o plano de contingência.
Teste de carga pode derrubar o meu sistema de verdade?
Pode, e é por isso que ele é feito em ambiente de homologação equivalente ao de produção, fora do horário comercial e com aviso a todos os envolvidos, incluindo fornecedores de integrações que também recebem carga. Testar direto em produção só se justifica em casos específicos, com salvaguardas combinadas e um botão de parada imediata.
Meu sistema tem poucos usuários. Ainda preciso pensar nisso?
Se o seu volume é estável e previsível, não é prioridade. Passa a ser no momento em que existir um evento concentrado, como uma campanha, uma integração com parceiro grande, uma migração de clientes ou uma obrigação com data legal. O risco não vem do tamanho da base, vem da concentração no tempo.