A maioria das lojas virtuais concentra uma grande parte da receita anual em poucos dias. Um feriado prolongado, um lançamento de produto ou uma única promoção relâmpago podem trazer mais tráfego em uma hora do que uma semana normal.
A boa notícia é que os dias de pico são previsíveis. Você sabe a data, tem os números do ano anterior e controla as promoções que geram o pico.
Comece com uma estimativa de carga, não com um palpite
Extraia o pico do ano passado do seu analytics e dos logs dos servidores e olhe para o minuto mais movimentado, não para o dia mais movimentado. Os totais diários escondem o pico que de fato derruba os sistemas, que normalmente chega quando uma campanha de e-mail é disparada ou uma contagem regressiva termina.
Suponha que a hora mais movimentada do ano passado teve 60.000 sessões e que o marketing espera o dobro este ano. Com 120.000 sessões e uma média de 10 visualizações de página cada, a origem precisa servir cerca de 1,2 milhão de visualizações de página na hora, ou aproximadamente 330 por segundo em média. O tráfego dentro de uma hora não é uniforme, então multiplique por 2 a 3 para o minuto de pico e planeje para cerca de 1.000 requisições de páginas dinâmicas por segundo, mais as chamadas de API do carrinho e da busca.
A lei de Little transforma então taxa em concorrência: requisições em andamento equivalem à taxa de chegada multiplicada pelo tempo de resposta. Com 1.000 requisições por segundo e 300 ms por requisição, cerca de 300 requisições estão sendo processadas a qualquer momento. Se cada worker da aplicação atende uma requisição por vez, você precisa de pelo menos 300 workers no conjunto de servidores, e de mais alguns para ter folga para requisições lentas e para a falha de um nó.
- Pedidos. Com uma taxa de conversão de 3 por cento, 120.000 sessões geram cerca de 3.600 pedidos na hora. Isso dá uma média de um por segundo, mas planeje para 5 a 10 por segundo no minuto de pico.
- Banda. Uma porta de 1 Gbps transfere cerca de 125 MB por segundo. Se as páginas HTML sem cache têm em média 100 KB, 1.000 páginas por segundo já consomem a maior parte dessa porta antes de imagens e scripts.
- Folga. Dimensione para pelo menos 1,5 vez a estimativa. As previsões costumam errar para menos tráfego, e os bots acrescentam carga que o analytics nunca contabiliza.
Leve o máximo possível de tráfego para a borda
Uma rede de entrega de conteúdo deve servir todos os arquivos estáticos: imagens, CSS, JavaScript e fontes. Se a CDN servir todos eles a partir do cache, a carga na origem cai em uma ordem de grandeza.
Páginas de categoria, páginas de produto e a página inicial costumam ser idênticas para todos que não estão logados e têm o carrinho vazio. Armazená-las em cache na borda por apenas 30 a 60 segundos transforma milhares de requisições idênticas por minuto em uma única requisição à origem por página e por ponto de presença.
- Chaves de cache. Remova os parâmetros de rastreamento das URLs antes de armazenar em cache, ou cada clique de campanha se torna um cache miss.
- Estratégia de purge. Decida com antecedência como as mudanças de preço e de estoque chegam às páginas em cache: por TTLs curtos, purges direcionados ou ambos.
- Cache da aplicação. Dentro da origem, mantenha sessões, dados do carrinho e resultados de consultas caras em um armazenamento em memória como o Redis, para que o banco de dados não receba a mesma pergunta milhares de vezes.
- Busca. Sirva a busca e os filtros a partir de um índice de busca dedicado, e não de consultas SQL nas tabelas de produtos.
Dimensione o banco de dados para o caminho de escrita
O tráfego de leitura pode ser cacheado e replicado. As escritas não. Cada pedido envolve a tabela de pedidos, os itens, o estoque, os registros de pagamento, os dados do cliente e, muitas vezes, um log de auditoria, o que pode facilmente significar de 20 a 50 escritas por pedido.
Comece garantindo que o conjunto de dados ativo caiba na memória. Verifique o log de consultas lentas dos últimos dias de maior movimento e corrija agora os índices ausentes, porque uma consulta que leva 200 ms com tráfego normal pode bloquear tabelas por segundos no pico.
- Pool de conexões. Coloque um pooler à frente do banco de dados. Centenas de workers da aplicação abrindo suas próprias conexões vão esgotar o banco de dados antes que a CPU fique ocupada.
- Réplicas de leitura. Envie as leituras do catálogo, os relatórios e as consultas de back-office para réplicas, para que o primário cuide dos pedidos.
- Linhas quentes. Um único produto com desconto agressivo pode transformar uma linha de estoque em um ponto de contenção de locks. Reserve o estoque com um contador atômico em um armazenamento em memória e reconcilie com o banco de dados, ou divida o estoque em várias linhas.
- Jobs em segundo plano. Pause ou reagende trabalhos pesados em lote, exportações de feeds e jobs de analytics durante o evento.
Isole o checkout de todo o resto
Quando uma loja se degrada sob carga, o objetivo é continuar recebendo dinheiro. A navegação pode ficar lenta por alguns minutos. O checkout não.
Na prática, isso significa um pool separado de servidores de aplicação, ou pelo menos workers separados, para as rotas de carrinho e checkout, de modo que uma enxurrada de requisições às páginas de categoria não esgote os recursos das requisições de pagamento. Gateways de pagamento, cálculo de impostos, análise antifraude e serviços de cálculo de frete precisam de timeouts curtos, novas tentativas com limite e um fallback definido, como aceitar o pedido e executar a verificação antifraude de forma assíncrona.
- Feature flags. Prepare chaves que desliguem recomendações, avaliações, widgets personalizados e chat ao vivo. Cada uma reduz a carga sem um deploy.
- Scripts de terceiros. Audite o gerenciador de tags. Cada script de analytics e de marketing na página de checkout é uma dependência que você não controla.
- Sala de espera. Uma fila virtual que admite visitantes a uma taxa definida é melhor do que um site que falha para todos. Configure-a e teste-a antes de precisar dela.
- Controle de bots. Aplique rate limit por IP e por sessão nos endpoints de carrinho e login, e mantenha a mitigação de DDoS ativa. Bots de estoque e credential stuffing costumam chegar junto com a promoção.
Faça testes de carga do jeito que os clientes realmente compram
Compradores reais navegam por categorias, fazem buscas, abrem páginas de produtos, adicionam itens ao carrinho, e uma pequena parcela deles finaliza a compra. Monte o teste a partir dessas jornadas, com uma distribuição que corresponda ao seu analytics, por exemplo 70 por cento de navegação, 15 por cento de busca, 10 por cento de atividade no carrinho e 5 por cento de checkout.
Execute o teste de fora da sua rede, passando pela CDN, contra um ambiente equivalente ao de produção em tamanho e configuração. Avise seus provedores de CDN, hospedagem e mitigação de DDoS antes de começar, porque um teste grande pode parecer exatamente um ataque.
- Teste de rampa. Aumente a carga em degraus até 1,5 a 2 vezes a estimativa e anote onde a latência começa a subir. Esse ponto é a sua capacidade real.
- Teste de pico. Salte do tráfego normal para o pico em menos de um minuto, como acontece com uma campanha de e-mail. Um autoscaling que leva cinco minutos para adicionar capacidade não vai ajudar aqui.
- Teste de resistência. Mantenha a carga de pico por duas a quatro horas para expor vazamentos de memória, vazamentos de conexões e volumes de log que enchem os discos.
- Repita. Cada teste encontra o primeiro gargalo. Corrija-o, execute novamente e continue até que o limite fique confortavelmente acima da previsão.
Escreva o runbook e configure o monitoramento
Durante um incidente, as pessoas tomam decisões piores do que tomariam à mesa em uma tarde tranquila. Um runbook leva as decisões para a tarde tranquila. Ele deve nomear quem está no comando no dia, quem fala com o negócio e com os clientes, quem pode aprovar uma mudança e quais são as respostas acordadas para os problemas mais prováveis.
O monitoramento precisa de duas camadas. A camada técnica cobre latência, taxas de erro, saturação e tráfego de cada nível: taxa de acerto da CDN, tempo de resposta da aplicação, utilização dos workers, conexões ao banco de dados, atraso de replicação e profundidade de fila. A camada de negócio costuma ser mais útil: pedidos por minuto, taxa de sucesso do checkout, taxa de autorização de pagamentos e abandono de carrinho.
- Limites. Registre como é o comportamento normal de cada métrica no pico, com base nos testes de carga, para que a equipe consiga distinguir um sistema ocupado de um sistema falhando.
- Ações pré-acordadas. Por exemplo: se a latência p95 do checkout passar de 2 segundos por 3 minutos, desative as recomendações; se passar de 4 segundos, ative a sala de espera.
- Rollback. Documente como reverter o último deploy e quanto tempo isso leva. Teste uma vez.
- Contatos. Liste os contatos de escalonamento do provedor de hospedagem, da CDN, do gateway de pagamento e de qualquer outro fornecedor crítico, com seus canais e horários de suporte.
Na semana anterior: um checklist
Na última semana, o trabalho deve deixar de ser construir e passar a ser confirmar. Use o tempo para verificar se tudo o que foi preparado antes está no lugar e para eliminar surpresas.
- Congelamento de mudanças. Congele mudanças de código e de infraestrutura, exceto correções aprovadas pelo runbook.
- Certificados e domínios. Verifique as datas de expiração dos certificados TLS e dos domínios. Reduza os TTLs de DNS caso precise redirecionar o tráfego rapidamente.
- Capacidade. Confirme que os servidores adicionais estão provisionados ou reservados, não apenas planejados. Escalar do zero no próprio dia deixa você exposto aos limites de capacidade do provedor e ao tempo de aquecimento.
- Backups. Verifique o backup mais recente do banco de dados restaurando-o e confirme que a recuperação point-in-time funciona.
- Promoções. Teste em staging todos os cupons de desconto, regras de kits e alterações de preço com combinações reais de carrinho.
- Estoque e catálogo. Carregue com antecedência o estoque, as imagens e as descrições da promoção e aqueça os caches dos produtos principais.
- Pessoas. Publique a escala de plantão, o canal de comunicação e o processo da página de status. Garanta que as pessoas de plantão tenham os acessos de que precisam.
No dia
Aumente a capacidade horas antes do evento, não quando os gráficos começarem a subir. Aqueça os caches acessando as principais páginas de categoria e de produto.
Não altere nada que não esteja no runbook e registre cada decisão com o horário em que foi tomada. Se algo quebrar, o líder do incidente decide, a equipe executa a resposta combinada e o contato do negócio mantém marketing e atendimento ao cliente informados, para que possam pausar uma campanha ou atualizar os clientes. Em até uma semana, faça uma revisão enquanto os dados estão frescos e registre os números reais.
Como a Vonahost pode ajudar
A nuvem gerenciada da Vonahost roda em plataforma própria, na AWS e no Google Cloud, e inclui CDN, Redis, Elasticsearch, ambientes de staging, backups e monitoramento, o que cobre várias das camadas descritas acima. Para o banco de dados e outros componentes que se beneficiam de hardware single-tenant, os servidores dedicados da Vonahost oferecem processadores AMD EPYC, armazenamento NVMe local, porta dedicada de 1 Gbps com tráfego ilimitado e mitigação de DDoS Arbor, implantados na região que você escolher.
Se você está se preparando para um evento de pico, o primeiro passo útil é compartilhar sua estimativa de tráfego e a arquitetura atual. Toda proposta da Vonahost informa a configuração, a localização, as responsabilidades e o preço mensal em dólares americanos, e você escolhe o país onde cada servidor é executado.