Diretrizes do CDN

Porta da frente do Azure
Armazenamento do Azure
Armazenamento do Blobs do Azure

Uma CDN (rede de distribuição de conteúdo) é uma rede distribuída de servidores que pode fornecer conteúdo da Web para os usuários com eficiência. As CDNs armazenam conteúdo em cache em servidores de borda próximos aos usuários finais a fim de minimizar a latência.

As CDNs normalmente são usadas para fornecimento de conteúdo estático, como imagens, folhas de estilo, documentos, scripts do lado do cliente e páginas HTML. As principais vantagens de usar uma CDN são latência mais baixa e fornecimento mais rápido de conteúdo aos usuários, independentemente de sua localização geográfica em relação ao datacenter no qual o aplicativo está hospedado. As CDNs também podem ajudar a reduzir a carga em um aplicativo Web, pois o aplicativo não precisa atender solicitações para o conteúdo hospedado na CDN.

Diagrama da CDN

Em Azure, Azure Front Door é a solução de CDN global para fornecer conteúdo de alta largura de banda hospedado em Azure ou em qualquer outro local. Você pode configurar as camadas Azure Front Door Standard e Premium para armazenar conteúdo em cache na borda da rede. Você pode armazenar em cache objetos carregados de Armazenamento de Blobs do Azure, um aplicativo Web, uma máquina virtual ou até mesmo qualquer servidor Web acessível publicamente.

Este artigo descreve algumas práticas recomendadas gerais e considerações para quando você usa uma CDN. Para obter mais informações, consulte a documentação sobre armazenamento em cache com o Azure Front Door.

Como e por que a CDN é usada

Entre os usos comuns para a CDN estão:

  • Fornecer recursos estáticos para aplicativos cliente, geralmente por meio de um site. Esses recursos podem ser imagens, folhas de estilos, documentos, arquivos, scripts do lado do cliente, páginas HTML, fragmentos HTML ou qualquer outro conteúdo que o servidor não precise modificar para cada solicitação. O aplicativo pode criar itens em runtime e disponibilizá-los para a CDN (por exemplo, criando uma lista de manchetes de notícias atuais), mas não faz isso para cada solicitação.

  • Fornecimento de conteúdo estático e compartilhado público para dispositivos como telefones móveis e tablet PCs. O aplicativo em si é um serviço web que oferece uma API aos clientes que são executados em vários dispositivos. O CDN também pode fornecer conjuntos de dados estáticos (por meio do serviço web) para os clientes usarem, talvez para gerar a interface do usuário do cliente. Por exemplo, o CDN pode ser usado para distribuir documentos XML ou JSON.

  • Servir sites inteiros que consistem em apenas conteúdo estático público para os clientes, sem a necessidade de quaisquer recursos de computação dedicados.

  • Fazer o streaming de arquivos de vídeo ao cliente sob demanda. O vídeo se beneficia da baixa latência e da conectividade confiável oferecidas pelos datacenters globalmente localizados que fornecem conexões de CDN.

  • Geralmente aprimorar a experiência dos usuários, especialmente aqueles localizados longe o datacenter que hospeda o aplicativo. De outra forma, esses usuários podem ter maior latência. Geralmente, uma grande proporção do tamanho total do conteúdo em um aplicativo Web é estática, e usar a CDN pode ajudar a manter o desempenho e a experiência geral do usuário eliminando a necessidade de implantar o aplicativo em vários datacenters. Para obter uma lista de locais de borda do Azure Front Door, consulte Locais de POP do Azure Front Door por região.

  • Dando suporte a soluções de IoT (Internet das Coisas). O grande número de dispositivos e aplicativos envolvidos em uma solução de IoT pode sobrecarregar um aplicativo com facilidade, se ele precisasse distribuir atualizações de firmware diretamente para cada dispositivo.

  • Lidar com picos e aumentos repentinos na demanda sem exigir que o aplicativo seja dimensionado, evitando o consequente aumento dos custos de execução. Por exemplo, quando uma atualização para um sistema operacional é lançada para um dispositivo de hardware, como um modelo específico de roteador, ou para um dispositivo de consumidor, como uma smart TV, há um enorme pico de demanda, pois ela é baixada por milhões de usuários e dispositivos em um curto período.

Desafios

Há vários desafios a serem considerados ao planejar o uso de uma CDN.

  • Implantação. Decida a origem da qual a CDN busca o conteúdo e se é necessário implantar o conteúdo em mais de um sistema de armazenamento. Considere o processo de implantação de conteúdo estático e recursos. Por exemplo, talvez seja necessário implementar uma etapa separada para carregar conteúdo em Armazenamento de Blobs do Azure. Para origens com suporte de armazenamento, consulte o padrão Hospedagem de conteúdo estático.

  • Controle de versão e controle de cache. Considere como você atualiza o conteúdo estático e implanta novas versões. Entenda como a CDN realiza cache e TTL (time-to-live). Para o Azure Front Door, consulte Cache com o Azure Front Door.

  • Testes. Pode ser difícil executar teste local de suas configurações de CDN ao desenvolver e testar um aplicativo localmente ou em um ambiente de preparo.

  • SEO (otimização do mecanismo de pesquisa). Conteúdo como imagens e documentos são atendidos de um domínio diferente quando você usa CDN. Isso pode afetar a SEO para esse conteúdo.

  • Segurança de conteúdo. Nem todas as CDNs fornecem controle de acesso baseado em identidade para conteúdo. O WAF do Azure Front Door protege os aplicativos contra explorações comuns e a segurança de origem impede que o tráfego ignore o Front Door. Esses recursos não substituem a autorização no nível do aplicativo para conteúdo privado. Para mais informações, consulte Firewall de Aplicativo Web no Azure Front Door e Proteger o tráfego para origens do Azure Front Door.

  • Segurança do cliente. Os clientes podem se conectar a partir de um ambiente que não permite o acesso aos recursos na CDN. Isso pode ser um ambiente restrito de segurança que limita o acesso a apenas um conjunto de fontes conhecidas ou que impede o carregamento de recursos por meio de qualquer coisa que não seja a origem da página. Uma implementação de fallback é necessária para lidar com esses casos.

  • Resiliência. O CDN é um ponto único de falha em potencial de um aplicativo.

Os cenários em que uma CDN pode ser menos útil incluem:

  • Se o conteúdo tiver uma taxa de ocorrência baixa, ele poderá ser acessado apenas algumas vezes enquanto for válido (determinado por sua configuração de vida útil).

  • Se os dados forem particulares, como para empresas de grande porte ou ecossistemas de cadeia de suprimentos.

Diretrizes gerais e práticas recomendadas

O uso de uma CDN é uma boa maneira de minimizar a carga no aplicativo e maximizar a disponibilidade e o desempenho. Leve em consideração a adoção dessa estratégia para todos os recursos e conteúdos apropriados que o seu aplicativo usa. Considere os pontos nas seções a seguir ao projetar sua estratégia para usar uma CDN.

Implantação

O conteúdo estático pode precisar ser provisionado e implantado independentemente do aplicativo se você não incluí-lo no pacote ou processo de implantação do aplicativo. Considere como isso afeta a abordagem de controle de versão que você usa para gerenciar os componentes do aplicativo e o conteúdo do recurso estático.

Considere o uso de técnicas de agrupamento e minificação para reduzir os tempos de carregamento para clientes. O agrupamento combina vários arquivos em um único arquivo. A minificação remove caracteres desnecessários de scripts e arquivos CSS sem alterar a funcionalidade.

Se você precisar implantar o conteúdo em outro local, essa será uma etapa extra no processo de implantação. Se o aplicativo atualizar o conteúdo da CDN, talvez em intervalos regulares ou em resposta a um evento, ele deverá armazenar o conteúdo atualizado em qualquer outro local, bem como o ponto de extremidade da CDN.

Considere como você lida com o desenvolvimento local e o teste quando espera-se que algum conteúdo estático seja fornecido de uma CDN. Por exemplo, você pode pré-implantar o conteúdo na CDN como parte do script de build. Como alternativa, use as diretivas de compilação ou sinalizadores para controlar como o aplicativo carrega os recursos. Por exemplo, no modo de depuração, o aplicativo pôde carregar recursos estáticos de uma pasta local. No modo de versão, o aplicativo usará a CDN.

Considere as opções de compactação de arquivo, como gzip (GNU zip). A compactação pode ser executada no servidor de origem pela hospedagem do aplicativo Web ou diretamente nos servidores de borda pela CDN. Para obter mais informações, consulte Melhorar o desempenho compactando arquivos em Azure Front Door.

Roteamento e controle de versão

Talvez seja necessário fornecer versões diferentes do conteúdo em vários momentos. Por exemplo, ao implantar uma nova versão do aplicativo, convém fornecer um novo conteúdo e manter o conteúdo antigo (em um formato mais antigo) para versões anteriores. Se você usar Armazenamento de Blobs do Azure como a origem do conteúdo, poderá armazenar cada versão em um contêiner de armazenamento de blobs separado. Uma origem Azure Front Door identifica um host de conta de armazenamento, não um contêiner individual. Para veicular conteúdo de uma conta de armazenamento diferente, aponte a origem para ela. Para fornecer conteúdo de um contêiner diferente na mesma conta, defina o caminho de origem da rota ou adicione uma regra de reescrita de URL direcionada ao contêiner.

Implantar novas versões do conteúdo estático quando você atualiza um aplicativo pode ser um desafio se os recursos anteriores forem armazenados em cache no CDN. Para obter mais informações, consulte a seção a seguir sobre o controle de cache.

Considere restringir o acesso ao conteúdo da CDN por país ou região. Azure Front Door usa o WAF para filtrar solicitações com base no país ou região de onde vem uma solicitação e restringir o conteúdo que ele fornece. Para mais informações, consulte Filtragem geográfica em um domínio do Azure Front Door.

Mantenha as URLs públicas estáveis quando apenas o local de armazenamento for alterado. Use uma reescrita de URL para mapear uma URL existente para um novo caminho de origem sem redirecionar o cliente. Se a URL pública precisar ser alterada, prefira retornar um redirecionamento de uma CDN ou proxy reverso existente em vez de invocar o aplicativo. O Azure Front Door Standard e Premium oferece suporte a redirecionamentos de URL por meio de conjuntos de regras.

Se o nome do host for alterado, mantenha o nome do host antigo roteável enquanto forem necessários redirecionamentos. Mantenha o DNS apontando para o ponto de extremidade de serviço de redirecionamento, mantenha o domínio personalizado e as associações de rota do nome do host antigo e mantenha um certificado TLS válido para HTTPS. Sem essas dependências, os clientes não podem receber o redirecionamento.

controle de cache

Considere como gerenciar o caching dentro do sistema. Por exemplo, em Azure Front Door, você pode definir regras de cache no mecanismo de regras e aplicar o comportamento de cache personalizado a rotas específicas. Você também pode controlar como o cache é executado em uma CDN pelo envio de cabeçalhos de diretiva de cache na origem.

Para obter mais informações, confira Cache com o Azure Front Door.

Para impedir que os objetos fiquem disponíveis na CDN, você pode excluí-los da origem, apagar ou remover o ponto de extremidade da CDN ou, no caso de armazenamento de blobs, tornar o contêiner ou blob privado. No entanto, os itens não são removidos da CDN até que o tempo de vida útil expire. Você também pode excluir manualmente um ponto de extremidade da CDN.

Segurança

Azure Front Door pode fornecer conteúdo por HTTPS usando um certificado TLS gerenciado por Microsoft ou seu próprio certificado. Para evitar avisos do navegador sobre conteúdo misto, use HTTPS para solicitar conteúdo estático que aparece em páginas carregadas por meio de HTTPS. Para obter mais informações, consulte TLS de ponta a ponta com o Azure Front Door.

Se você entregar ativos estáticos (como arquivos de fonte) usando a CDN, talvez encontre problemas de política de mesma origem se usar uma chamada XMLHttpRequest para solicitar esses recursos de um domínio diferente. Muitos navegadores da web impedem o compartilhamento de recursos de origens cruzadas (CORS), a menos que o servidor Web esteja configurado para definir os cabeçalhos de resposta apropriada. É possível configurar a CDN para dar suporte ao CORS usando um dos seguintes métodos:

Fallback de CDN

Considere como seu aplicativo lida com uma falha ou indisponibilidade temporária da CDN. Os aplicativos cliente podem ser capazes de usar cópias dos recursos que foram armazenados em cache localmente (no cliente) durante solicitações anteriores ou você pode incluir código que detecta falha e, em vez disso, solicita recursos da origem (a pasta do aplicativo ou Armazenamento de Blobs do Azure contêiner que contém os recursos) se a CDN não estiver disponível.