Acelerar sites e APIs com uma CDN

Um time de engenharia ou de SRE executa um site e as suas APIs em uma origem que ele opera, em uma região de nuvem ou em um data center. Os usuários longe dessa origem veem páginas lentas, e os picos de tráfego a sobrecarregam. Arquivos estáticos e páginas são os mesmos para todos os usuários, enquanto as chamadas de API são diferentes para cada um e precisam sempre chegar à origem. Esta página configura uma aplicação na frente da origem que cacheia arquivos estáticos e páginas, com Tiered Cache para os arquivos estáticos, repassa as chamadas de API à origem e faz a origem aceitar conexões só da Azion. O resultado é medido pelo time to first byte e pelo tempo de carregamento de página para os usuários, pela parcela das requisições respondidas pelo cache e pela queda nas requisições e nos dados que chegam à origem.

Este caso de uso não cobre a saída do site da sua origem, o failover entre origens nem a otimização de imagens. Para failover, consulte Manter uma aplicação no ar quando uma origem falha. Para imagens, consulte Otimizar imagens para sites e aplicações móveis. Para um site de marketing em um CMS, consulte Criar e operar sites de marketing.

Pré-requisitos

• Uma aplicação que serve o seu site por meio de um connector e de um workload, com uma regra cujo behavior Set Connector envia todas as requisições ao connector. Para criá-los, consulte Primeiros passos com Applications.
• Application Accelerator nessa aplicação, que o behavior Bypass Cache e os métodos POST, PUT, PATCH, DELETE e OPTIONS da API exigem. Para ativá-lo, consulte Ative Application Accelerator.
• Um personal token, para os passos pela API e para os purges. Para criar um, consulte Gerencie personal tokens.
• Acesso ao firewall na frente da sua origem, onde fica a allowlist.
• Os caminhos do seu site. Esta página usa /static/ para os arquivos CSS, JavaScript, de fonte e de imagem que um deploy publica, /api/ para a API, todos os outros caminhos para páginas, site-origin para o connector da sua origem e www.example.com para o domínio. Substitua cada valor pelo seu em todos os passos.

Produtos necessários

Apontar o domínio para a Azion é igual para todos os sites, então não tem seção nesta página. Para criar o registro, consulte Aponte um domínio para um workload, e para o apex, Aponte um domínio raiz com ANAME.

Arquitetura de referência

Esta página constrói o Proxy reverso com cache na frente de uma origem: uma aplicação que responde do cache tudo o que pode e só chega à origem em um miss.

Leia o diagrama como uma cadeia de camadas que tentam responder, cada uma, antes que a seguinte seja consultada. O cache do data center responde primeiro, a camada do Tiered Cache responde os arquivos estáticos que o data center não tem, e só um miss em todas as camadas chega à origem pelo connector. As chamadas de API pulam as camadas e vão direto ao connector. A origem fica atrás de uma allowlist, então o connector é a única entrada. Real-Time Purge age no cache pelo lado, removendo o conteúdo que a origem mudou antes que o seu TTL termine.

Fluxo de dados

1. Edge DNS resolve www.example.com para o workload, e a requisição do usuário chega à aplicação em um data center próximo.
2. As regras da aplicação leem o caminho na Request Phase e aplicam uma cache setting: static-files a um arquivo de /static/, pages a uma página. Uma cópia válida no cache do data center responde a requisição, e a origem não é consultada.
3. Em um miss de um arquivo estático, o data center consulta a camada do Tiered Cache, que é compartilhada por todos os data centers e guarda objetos por mais tempo. Uma cópia ali responde a requisição sem chegar à origem.
4. Uma chamada de /api/ faz bypass do cache e chega à origem pelo connector site-origin, com todos os métodos HTTP. Qualquer outro miss também chega à origem por site-origin, e a resposta é guardada para a requisição seguinte.
5. O connector chega à origem a partir de um endereço da lista Azion Origin Shield, e o firewall da origem recusa todas as outras fontes.
6. Quando um deploy muda arquivos estáticos, um purge por cache key os remove antes que o seu TTL termine, primeiro da camada do Tiered Cache e depois do Cache, e a requisição seguinte busca a nova versão. Um purge por cache key é o único tipo que chega à camada do Tiered Cache.

Componentes

• Edge DNS: resolve o domínio para o workload. Um subdomínio como www.example.com aponta para o domínio do workload com um registro CNAME, e o apex com um registro ANAME.
• aplicação: o Platform Resource que guarda as cache settings static-files e pages e as regras que as aplicam, caminho por caminho, ao lado da regra que faz bypass do cache em /api/.
• Application Accelerator: o Product que o behavior Bypass Cache exige, para que a aplicação envie cada chamada em /api/ à origem sem guardar a resposta.
• Cache: guarda as respostas no data center que as buscou e responde às requisições repetidas com a cópia, pelo TTL da cache setting.
• Tiered Cache: a Feature que adiciona uma segunda camada de cache entre o Cache e a origem, na região que a sua topologia nomeia. Ela exige Override cache behavior e um Max Age de pelo menos 3 segundos, e nesta página cobre só os arquivos estáticos.
• connector: o Platform Resource que chega à origem em um miss em todas as camadas de cache e em todas as chamadas de API. Nesta página, é site-origin.
• Origin Shield: com Origin IP ACL no connector, o próprio firewall da origem permite os prefixos da lista Azion Origin Shield e recusa todas as outras fontes.
• Real-Time Purge: o Platform Resource que remove do cache o conteúdo alterado antes que o seu TTL termine.
• Real-Time Metrics: mostra a parcela das requisições e dos dados respondidos pelo cache, o que chegou à origem e o que a camada do Tiered Cache absorveu.

Outros designs para este caso de uso

• Proxy reverso de aceleração para APIs dinâmicas: para times cujas respostas são personalizadas ou transacionais e não podem ser cacheadas. Toda requisição em um caminho dinâmico vai até a origem, então o tempo de resposta da origem sempre faz parte do tempo de resposta, e as decisões são o tratamento das conexões e o bypass de cache em vez de TTLs e purge.

Configure o cache para arquivos estáticos e páginas

O cache deste site são duas cache settings, uma por tipo de conteúdo, cada uma aplicada pela sua própria regra. Os arquivos estáticos só mudam quando você faz deploy, então ficam em cache por muito tempo e passam pelo Tiered Cache. As páginas mudam entre deploys, então ficam em cache por pouco tempo.

A setting static-files usa Override cache behavior com um Max Age de 86400 segundos, um dia. O purge configurado abaixo remove um arquivo alterado no momento do deploy, então o dia só limita quanto tempo um arquivo fica desatualizado quando um purge não é enviado. Tiered Cache fica ativo, com a região mais próxima como topologia: o Tiered Cache foi projetado para objetos que ficam em cache por muito tempo, e exige Override cache behavior. O cache do navegador respeita o Cache-Control que a origem envia para cada arquivo.

A setting pages usa um Max Age de 300 segundos, então uma página editada na origem chega aos usuários em até cinco minutos sem purge. O cache do navegador dela é sobrescrito para 0 segundos, porque uma cópia no navegador do usuário não pode ser purgada. Ela não tem Tiered Cache, porque um objeto de cinco minutos ganha pouco com uma segunda camada.

As duas settings mantêm Stale cache ativo, como o Azion Console o define para uma nova setting. Uma cópia expirada então responde por até 300 segundos quando a origem retorna um erro 5xx ou excede o tempo limite.

Crie as duas cache settings como Crie um cache setting descreve, com estes valores, e guarde o id de cada uma para a sua regra:

Aplique cada setting com uma regra na Request Phase, como o mesmo guia descreve, com estes valores:

Pela API, os dois critérios da regra cdn - pages ficam em um grupo unido por and, então uma requisição só corresponde quando o seu caminho não é nem um arquivo estático nem uma chamada de API:

Os arquivos estáticos ficam em cache por um dia nas duas camadas de cache, e as páginas por cinco minutos. Uma nova regra leva alguns minutos para se propagar.

Configure o repasse da API

As respostas da API são diferentes para cada chamador, então o caminho da API faz bypass do cache e todas as chamadas chegam à origem. A regra corresponde a /api/ e carrega Bypass Cache. Application Accelerator, já ativo na aplicação, é o que faz a aplicação aceitar as chamadas POST, PUT, PATCH, DELETE e OPTIONS da API, além de GET e HEAD. Uma requisição com bypass mantém as otimizações de protocolo e, quando possível, uma conexão keep-alive com a origem, então cada chamada evita abrir uma nova conexão.

Todas as chamadas de /api/ chegam à origem, e a Azion não guarda nenhuma das suas respostas. O caminho da API não tem cache setting com Tiered Cache, então nenhuma resposta dele vai parar na camada do Tiered Cache: Bypass Cache age no cache da Azion, e não nessa camada.

Configure Origin Shield no connector

Origin IP ACL faz a origem aceitar conexões só da Azion, então um cliente que descobre o endereço da origem não consegue alcançá-la contornando a aplicação. A verificação tem duas metades. O connector ativa Origin IP ACL, o que disponibiliza a lista de rede Azion Origin Shield para a sua conta. O firewall da sua origem então permite os prefixos dessa lista e nega todas as outras fontes. A Azion não aplica a allowlist: o seu firewall aplica.

As duas metades são o procedimento que Restrinja uma origem à Azion com Origin IP ACL descreve, executado em site-origin e no firewall na frente da sua origem. A allowlist guarda os prefixos IPv4 e IPv6 da lista, e a regra de negação só vem depois que todos os prefixos são permitidos.

A Azion muda a lista de tempos em tempos e envia um email para a sua conta a cada vez. Os servidores atrás de um prefixo adicionado entram em produção 7 dias depois que a Azion publica a mudança, então um job que lê a lista com uma frequência menor que 7 dias mantém a sua allowlist atualizada.

Configure o purge no deploy

Um deploy que muda arquivos estáticos envia um purge, para que os usuários recebam os novos arquivos sem esperar o Max Age de um dia. A setting static-files tem o Tiered Cache ativo, e um purge por cache key é o único tipo que chega à camada do Tiered Cache. Por isso, o deploy purga cada arquivo alterado por cache key, primeiro na camada do Tiered Cache e depois no Cache, para que a primeira camada não se reabasteça com uma cópia desatualizada do Tiered Cache.

1. O deploy publica os novos arquivos na origem.
2. Ele envia um purge por cache key para cada arquivo alterado, com layer igual a tiered_cache.
3. Ele envia o mesmo purge com layer igual a cache.
4. A requisição seguinte por cada arquivo tem miss nas duas camadas, chega à origem e guarda a nova versão.

Uma cache key é o esquema, o host e o caminho, sem separador entre eles. Para o arquivo https://www.example.com/static/app.css, o corpo de POST /v4/workspace/purge/cachekey para a camada do Tiered Cache é:

e para o Cache:

Cada chamada responde 201 com state igual a executed. Um purge por cache key aceita até 50 chaves por requisição, então um deploy que muda mais arquivos os divide em várias requisições. Uma página que muda sem deploy não precisa de purge: o seu Max Age de cinco minutos a atualiza. Para os outros tipos de purge e para confirmar que um purge terminou, consulte Purgue páginas quando a origem publica uma mudança.

Verifique a configuração

Cada verificação envia uma requisição com o header Pragma: azion-debug-cache, que faz a resposta carregar os headers x-cache e x-cache-key. Para saber como lê-los, consulte Verifique o status de cache de uma resposta.

• O domínio resolve para a Azion. Consulte o hostname:

  dig +short www.example.com

  A resposta lista o domínio do workload, no formato <id>.map.azionedge.net.

• Os arquivos estáticos respondem do cache. Solicite um arquivo estático duas vezes:

  curl -sI -H "Pragma: azion-debug-cache" https://www.example.com/static/app.css

  A segunda resposta carrega x-cache: HIT. A primeira pode carregar MISS, enquanto a Azion busca o arquivo.

• As páginas respondem do cache. Solicite a página inicial duas vezes da mesma forma. A segunda resposta carrega x-cache: HIT.

• As chamadas de API chegam à origem. Solicite um caminho da API:

  curl -sI -H "Pragma: azion-debug-cache" https://www.example.com/api/status

  A resposta carrega x-cache: BYPASS.

• A origem recusa conexões de qualquer outro lugar. A partir da sua própria máquina, envie uma requisição direto para o endereço da origem. O firewall da origem recusa a conexão ou a deixa exceder o tempo limite, enquanto as requisições por www.example.com continuam respondendo.

• Um purge chega às duas camadas. Depois de um deploy e dos seus purges, solicite um arquivo alterado. A resposta carrega x-cache: MISS, e a requisição seguinte carrega HIT com o novo conteúdo.

Uma regra que parece não ter efeito ainda pode estar se propagando. Quando isso persiste depois de alguns minutos, ative Debug Rules para ver quais regras rodaram na requisição.

Medindo resultados

Boas práticas

• Mantenha o Tiered Cache desligado em qualquer caminho com bypass. Bypass Cache age no cache da Azion, e não na camada do Tiered Cache, então um caminho cuja cache setting tem o Tiered Cache ativo continua respondendo dessa camada. Nesta página, o caminho /api/ com bypass não tem nenhuma cache setting. Para o sintoma, consulte Solucionar problemas de Applications.
• Purgue no deploy em vez de encurtar o Max Age. Um Max Age curto envia mais requisições à origem e ainda deixa uma janela de conteúdo desatualizado. O deploy sabe quais arquivos mudaram, então ele os purga, e o Max Age fica como um limite de segurança.
• Use Bypass Cache para a API, e não um Max Age de 0. Um Max Age de 0 junta requisições simultâneas para um caminho em uma única requisição à origem, e dois chamadores de uma API precisam de duas respostas. Para a diferença, consulte Variação de cache.
• Permita as duas famílias de endereços na origem. A lista Azion Origin Shield traz prefixos IPv6 ao lado dos seus prefixos IPv4, e a Azion se conecta às origens pelas duas. Uma allowlist só com os prefixos IPv4 recusa as conexões que a Azion abre por IPv6.

Guias deste caso de uso