Sua loja aguenta a Black Friday? Prepare o cache antes do pico

Na Black Friday, o problema de uma loja raramente é falta de servidor, e sim a requisição que chega à origem sem precisar, pedindo uma página ou imagem que uma cópia em cache poderia entregar. Cada página servida do cache é uma requisição a menos no backend na hora do pico, e é por isso que preparar o cache na Black Friday costuma render mais do que adicionar máquinas à origem.

A seguir, veja como fazer essa preparação na Azion, do que vai para o cache ao plano de purge para quando o preço mudar.

Por que o pico da Black Friday chega à origem?

Duas situações explicam a maior parte desse tráfego. A primeira é o cache vazio à meia-noite, quando a campanha abre e os primeiros acessos de cada data center vão todos para o servidor de origem da loja. A segunda é o TTL curto demais, que faz a cópia expirar e obriga a Azion a buscar de novo um conteúdo que não mudou.

Quando as duas estão resolvidas, o resultado aparece no caso da Renner, que chegou a um pico de 899 mil requisições por segundo na Black Friday e, segundo o caso de sucesso, só um pequeno percentual delas acessou a infraestrutura de origem.

Cada ida à origem também soma tempo de resposta, e a latência no e-commerce derruba a conversão mesmo com a loja no ar. Parte desse tráfego nem vem de clientes, e sim de bots, que também vale filtrar antes do pico.

O que pode e o que não pode ir para o cache?

O critério é simples: vai para o cache o que é igual para todo mundo, e fica fora o que muda a cada visitante. Vitrine, categorias, páginas de produto, imagens, CSS, JavaScript e fontes são iguais para qualquer visitante e concentram o tráfego da campanha. Carrinho, checkout e login mudam a cada sessão e continuam indo para a origem, e o post sobre como evitar falhas no checkout em picos de tráfego mostra como proteger essa parte da jornada.

Na Azion, essa separação é segura por padrão, porque o Cache não guarda nada até que uma regra do Rules Engine aplique uma configuração de cache a um caminho. Você inclui o que pode ser compartilhado, caminho a caminho, e o que nenhuma regra cita continua indo para a origem.

Se a página de produto mostra preço ou estoque diferente por cookie, ela precisa variar o cache por esse cookie, o que exige o Application Accelerator, ou carregar essa parte por uma chamada separada que não passa pelo cache, como discute o post sobre por que o cache tradicional falha na hora da compra.

Qual TTL de cache usar na semana do evento?

O TTL é o tempo que a cópia fica guardada, e cada configuração de cache da Azion tem dois, um para o cache da Azion e outro para o navegador. Com a opção Honor cache policies, quem define o tempo de vida são os cabeçalhos de cache HTTP Cache-Control e Expires que a origem envia, e com Override cache behavior vale o Max Age que você definir, como explica a página de expiração e atualização.

Para a Black Friday, o Override é a escolha mais previsível, e ele também é obrigatório para ligar o Tiered Cache. Um ponto de partida para uma loja típica:

Nas páginas com preço, vale manter curto o TTL do navegador, para que quem volta à página não veja um valor antigo depois de um purge.

Sem o Application Accelerator, o Max Age mínimo é de 60 segundos. Com ele, dá para fazer micro caching de páginas que mudam muito, como uma vitrine de ofertas relâmpago com 10 segundos de TTL. E quando várias requisições pelo mesmo objeto chegam ao mesmo tempo sem cópia no cache, a Azion abre uma única conexão com a origem para todas elas.

Como o Tiered Cache reduz a carga na origem?

O Tiered Cache cria uma segunda camada de cache antes da origem, hospedada na região que a topologia do cache setting define. Quando um data center não tem o objeto, ele consulta essa camada antes de ir à origem, e um objeto buscado uma vez na origem passa a atender os outros data centers a partir dali, sem que o primeiro acesso em cada um vire uma requisição ao servidor da loja.

Para ligá-lo, a configuração de cache precisa usar Override cache behavior e ter um Max Age de pelo menos 3 segundos com o Application Accelerator, ou de 60 segundos sem ele, que é o piso de qualquer configuração de cache. Ele está incluído em todos os planos, ao custo de um salto a mais quando o primeiro nível não tem o objeto, e o artigo O que é Tiered Caching? explica essa arquitetura em mais detalhe.

O que acontece com o cache se a origem cair?

Com o Stale cache ligado, a Azion continua entregando a última cópia que tem quando a origem responde com erro 5xx, demora além do limite ou está fora do ar, e também enquanto busca uma versão nova, então o visitante continua vendo a vitrine em vez de uma página de erro.

Essa proteção tem uma janela de 300 segundos por padrão, ou o valor de stale-while-revalidate que a origem enviar quando a configuração usa Honor cache policies, e passada a janela as páginas expiradas voltam a depender da origem. Para quedas mais longas, a Azion permite distribuir o tráfego entre duas ou mais origens com o Load Balancer.

Confira se o Stale cache está ligado, porque configurações criadas pela API ou pela CLI começam com ele desligado. Nas respostas, o status STALE indica que a origem falhou e a cópia expirada foi entregue, e UPDATING, que uma versão nova está a caminho.

Como aquecer o cache antes do pico?

Aquecer o cache, ou fazer o pre-warming de cache, é antecipar o primeiro acesso a cada página para que ele não fique com o visitante, e a Azion CLI tem um comando para isso, o azion warmup. Ele começa numa URL base, lê os links de cada página que recebe e requisita cada URL nova que encontra, até a fila esvaziar ou o comando atingir o limite de URLs.

Por padrão, o comando envia 2 requisições ao mesmo tempo, processa até 1.500 URLs e espera até 8 segundos por cada uma. A URL base pode trazer um caminho, para aquecer só a seção da campanha com limites ajustados a ela (o --timeout é contado em milissegundos):

No fim, um resumo conta as URLs que deram certo e as que falharam. Como cada página fora do cache vai à origem, rode o comando num horário de pouco tráfego e aumente o --max-concurrent aos poucos.

O aquecimento rende mais com o Tiered Cache ligado, porque um data center que não tem o objeto consulta essa camada antes de ir à origem, e uma página aquecida nela passa a ser entregue por ali aos outros data centers. O horário também precisa conversar com o TTL, e por isso o aquecimento da madrugada serve ao que fica muito tempo em cache, como imagens e estáticos, enquanto páginas de TTL curto pedem um aquecimento logo antes de a campanha abrir e depois de cada purge.

Como atualizar o preço sem esvaziar o cache inteiro?

Na Black Friday, o preço muda de hora em hora, e o Real-Time Purge remove objetos do cache por URL, por cache key ou por wildcard, pelo Console, pela API ou pela CLI. O mais seguro é deixá-lo pronto num script ou no pipeline que publica os preços.

Com o Tiered Cache ligado, limpe primeiro a camada do Tiered Cache, que só aceita purge por cache key, e depois o cache principal, porque na ordem inversa um data center pode buscar de volta a cópia velha que ainda estava no Tiered Cache:

A cache key de uma página aparece no cabeçalho x-cache-key da resposta quando a requisição é enviada com Pragma: azion-debug-cache, e é esse valor que o purge do Tiered Cache precisa receber. Na cache key padrão, o scheme, o host e o path aparecem juntos, sem separador, como no exemplo acima. Se a página varia por cookie, o purge por URL não alcança essas cópias, e é preciso purgar cada variação por cache key ou usar um wildcard terminado em @@*.

Um purge por URL ou cache key aceita até 50 objetos por requisição e 10.000 a cada 60 segundos, e o purge por wildcard aceita uma expressão por requisição e 2.000 requisições a cada 24 horas. Para uma troca de preço em massa, isso favorece limpar uma seção inteira por wildcard, como www.sualoja.com.br/ofertas/*, e reservar o purge por URL para produtos avulsos.

O purge entra numa fila e se propaga pela infraestrutura distribuída da Azion, e, depois dele, rodar o azion warmup na seção purgada ajuda a colocar a cópia nova no cache antes que o tráfego volte a pedi-la.

Como saber quanto do tráfego vem do cache?

O offload, a parte do tráfego entregue sem buscar na origem, é o número que resume essa preparação. No Real-Time Metrics, na aba Applications, filtre o painel pelo host da loja e acompanhe o gráfico Edge Offload e os totais de Saved Data e Missed Data. No painel Requests, os equivalentes são Requests Offloaded, Saved Requests e Missed Requests.

Durante o pico, o gráfico de Missed Requests mostra as requisições que o data center não respondeu do próprio cache. Um salto logo depois de um purge é esperado, enquanto um patamar alto e constante costuma apontar para um caminho sem regra de cache ou para uma página que varia por algo que o cache não considera. Com o Tiered Cache ligado, o que chega de fato à origem aparece na aba Tiered Cache.

Para testar essa configuração antes do pico, crie uma conta gratuita no plano Hobby e monte as regras de cache da sua aplicação, ou fale com um especialista da Azion para planejar o cache da sua loja para a Black Friday.

Perguntas frequentes

O que é aquecer o cache?

É requisitar as páginas antes que os visitantes cheguem, para que a primeira cópia já esteja guardada quando o pico começar. Na Azion, o azion warmup, da Azion CLI, faz isso a partir de uma URL base, seguindo os links de cada página.

Qual TTL usar para página de produto?

Minutos, na maioria das lojas, com purge sempre que o preço mudar e um TTL de navegador curto. Se a página precisa de um TTL abaixo de 60 segundos, isso exige o Application Accelerator.

O que acontece com o cache se a origem cair?

Com o Stale cache ligado, a Azion continua entregando a última cópia por até 300 segundos por padrão, ou pelo valor de stale-while-revalidate que a origem enviar.

Como atualizar o preço sem esvaziar o cache inteiro?

Use o Real-Time Purge por URL ou cache key para produtos avulsos, e por wildcard para uma seção inteira. Com o Tiered Cache ligado, limpe primeiro o Tiered Cache e depois o cache principal.

Como saber quanto do tráfego vem do cache?

No Real-Time Metrics, o gráfico Edge Offload da aba Applications mostra a parcela dos dados entregue a partir do cache, e Requests Offloaded mostra a parcela das requisições.

Como configurar o cache para a Black Friday na Azion?

A Azion é uma plataforma serverless que executa aplicações em uma infraestrutura distribuída de data centers. O cache é configurado com regras no Rules Engine, usando o comportamento Set Cache Policy, e o Tiered Cache e o Stale cache são ligados nas configurações de cache da aplicação.