Acelerar sites e APIs com uma CDN

A Azion serve como CDN para um site cujos visitantes em outros países ou regiões veem páginas lentas. Um time de engenharia ou de SRE executa esse site e as suas APIs em uma única origem, em uma região de nuvem ou em um data center, e os picos de tráfego a sobrecarregam. Arquivos estáticos e páginas são os mesmos para todos os visitantes, 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 visitantes distantes, 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 conta Azion. Se você ainda não tem uma, crie uma conta.
• 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 exige. Para ativá-lo, consulte Ative Application Accelerator.
• Acesso ao firewall na frente da sua origem, onde fica a allowlist.

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.

As setas contínuas levam a requisição, as setas pontilhadas levam a resposta, e as setas grossas levam o purge, que roda separado de qualquer requisição. Cada rótulo começa pelo número da etapa do fluxo de dados a que pertence.

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 pela aplicaçã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, na região que a topologia da cache setting seleciona. Uma cópia ali responde a requisição sem chegar à origem, e o Cache a guarda no caminho de volta.
4. Uma chamada de /api/ faz bypass do cache e chega à origem pelo connector site-origin, com todos os métodos HTTP, e a resposta dela não é guardada. Qualquer outro miss também chega à origem por site-origin. No caminho de volta, a camada do Tiered Cache mantém um arquivo estático, e o Cache guarda o arquivo ou a página 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.

Toda resposta volta pela aplicação, que a entrega ao usuário.

Recursos de Plataforma

• 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, com Application Accelerator ativo, 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.

Como o design funciona

Esta seção explica as quatro partes do design que são específicas deste site: o cache para arquivos estáticos e páginas, o repasse da API, Origin Shield no connector e o purge no deploy.

Cache para arquivos estáticos e páginas

Cada requisição chega ao data center da Azion com a melhor rota até o visitante, entre mais de 100 data centers. Um arquivo ou uma página em cache ali responde sem a ida e volta até a origem, e essa ida e volta é o tempo que um visitante distante economiza. A Azion informa uma latência mediana de 30 ms na sua rede; os tempos de cada site dependem de onde estão os seus visitantes e a sua origem.

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 no deploy 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, 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.

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 libera Bypass Cache.

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.

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 executadas 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.

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.

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.

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 Solucione 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. Para a diferença entre Bypass Cache e um Max Age de 0, 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