A RFC (rede de fornecimento de conteúdo) da Cloud usa a rede de limite global da Google para fornecer conteúdo mais próximo dos utilizadores, o que acelera os seus Websites e aplicações.
O Cloud CDN funciona com o Application Load Balancer externo global ou o Application Load Balancer clássico para fornecer conteúdo aos seus utilizadores. O Application Load Balancer externo fornece os endereços IP e as portas de front-end que recebem pedidos e os back-ends que respondem aos pedidos.
O conteúdo da RFC na nuvem pode ser proveniente de vários tipos de back-ends.
No Cloud CDN, estes back-ends também são denominados servidores de origem. A Figura 1 ilustra como as respostas dos servidores de origem que são executados em instâncias de máquinas virtuais (VM) fluem através de um equilibrador de carga de aplicações externo antes de serem fornecidas pela RFC do Google Cloud. Nesta situação, o front-end da Google (GFE) compreende o Cloud CDN e o Application Load Balancer externo.
Como funciona o Cloud CDN
Quando um utilizador pede conteúdo a um Application Load Balancer externo, o pedido chega a um GFE que está no limite da rede da Google o mais próximo possível do utilizador.
Se o mapa de URL do balanceador de carga encaminhar o tráfego para um serviço de back-end ou um contentor de back-end com o Cloud CDN configurado, o GFE usa o Cloud CDN.
Resultados da cache e resultados em falta na cache
Uma cache é um grupo de servidores que armazena e gere conteúdo para que os pedidos futuros desse conteúdo possam ser processados mais rapidamente. O conteúdo em cache é uma cópia do conteúdo memorizável em cache que é armazenado em servidores de origem.
Se o GFE procurar na cache da CDN na nuvem e encontrar uma resposta em cache ao pedido do utilizador, o GFE envia a resposta em cache ao utilizador. Isto chama-se resultado da cache. Quando ocorre um acerto da cache, o GFE procura o conteúdo pela respetiva chave da cache e responde diretamente ao utilizador, o que reduz o tempo de ida e volta e evita que o servidor de origem tenha de processar o pedido.
Um resultado parcial ocorre quando um pedido é fornecido parcialmente a partir da cache e parcialmente a partir de um back-end. Isto pode acontecer se apenas parte do conteúdo pedido estiver armazenada numa cache da RFC de multimédia na nuvem, conforme descrito no artigo Suporte para pedidos de intervalo de bytes.
Na primeira vez que um conteúdo é pedido, o GFE determina que não pode satisfazer o pedido a partir da cache. Isto denomina-se falha de cache. Quando ocorre uma falha de cache, o GFE encaminha o pedido para o Application Load Balancer externo. Em seguida, o balanceador de carga encaminha o pedido para um dos seus servidores de origem. Quando a cache recebe o conteúdo, o GFE encaminha o conteúdo para o utilizador.
Se a resposta do servidor de origem a este pedido for colocável em cache, a RFC na nuvem armazena a resposta na cache da RFC na nuvem para pedidos futuros. A transferência de dados de uma cache para um cliente denomina-se saída da cache. A transferência de dados para uma cache é denominada preenchimento da cache.
A Figura 2 mostra um acerto de cache e uma cache em falta:
- Os servidores de origem executados em instâncias de VM enviam respostas HTTP(S).
- O balanceador de carga de aplicações externo distribui as respostas para o Cloud CDN.
- O Cloud CDN envia as respostas aos utilizadores finais.
Para custos relacionados com acertos e falhas de cache, consulte a secção Preços.
Relação de resultados da cache
A relação de resultados da cache é a percentagem de vezes que um objeto pedido é apresentado a partir da cache. Se a taxa de acertos da cache for de 60%, significa que o objeto pedido é apresentado a partir da cache 60% das vezes e tem de ser obtido a partir da origem 40% das vezes.
Para ver informações sobre como as chaves de cache podem afetar a taxa de acertos da cache, consulte o artigo Usar chaves de cache. Para informações de resolução de problemas, consulte o artigo A taxa de acertos da cache é baixa.
Veja a relação de resultados da cache para um pequeno período
Para ver a taxa de acertos da cache para um pequeno período (os últimos minutos):
Na Google Cloud consola, aceda à página Cloud CDN.
Para cada origem, consulte a coluna Rácio de acertos da cache.
n/a significa que o conteúdo com balanceamento de carga não está em cache ou não foi pedido recentemente.
Veja a relação de resultados da cache durante um período mais longo
Para ver a relação de resultados da cache para um período de 1 hora a 30 dias:
- Na Google Cloud consola, aceda à página Cloud CDN.
- Na coluna Nome de origem, clique no nome de origem.
- Clique no separador Monitorização.
- Opcional: selecione um back-end específico.
A taxa de acertos da RFC é um dos gráficos de monitorização disponíveis. Um gráfico que apresenta n/a significa que o conteúdo não está em cache ou não foi pedido no intervalo de tempo apresentado.
Pode ajustar o período selecionando um intervalo de tempo diferente. A imagem seguinte é um exemplo de intervalos de tempo que pode selecionar:
Inserir conteúdo na cache
O armazenamento em cache é reativo, pois um objeto é armazenado numa cache específica se um pedido passar por essa cache e se a resposta for armazenável em cache. Um objeto armazenado numa cache não é replicado automaticamente noutras caches. O preenchimento da cache ocorre apenas em resposta a um pedido iniciado pelo cliente. Não pode pré-carregar caches, exceto fazendo com que as caches individuais respondam a pedidos.
Quando o servidor de origem suporta pedidos de intervalo de bytes, a CDN da Google Cloud pode iniciar vários pedidos de preenchimento da cache em reação a um único pedido do cliente.
Publicar conteúdo a partir de uma cache
Depois de ativar a CDN na nuvem, o armazenamento em cache ocorre automaticamente para todo o conteúdo armazenável em cache. O seu servidor de origem usa cabeçalhos HTTP para indicar que respostas são colocadas em cache. Também pode controlar a capacidade de colocação em cache através dos modos de cache.
Quando usa um contentor de back-end, o servidor de origem é o Cloud Storage. Quando usa instâncias de VM, o servidor de origem é o software de servidor Web que executa nessas instâncias.
O Cloud CDN usa caches em várias localizações em todo o mundo. Devido à natureza das caches, é impossível prever se um pedido específico é apresentado a partir de uma cache. No entanto, pode esperar que os pedidos populares de conteúdo memorizável em cache sejam servidos a partir de uma cache na maioria das vezes, o que resulta em latências significativamente reduzidas, custos reduzidos e carga reduzida nos seus servidores de origem.
Para mais informações sobre o que o Cloud CDN coloca em cache e durante quanto tempo, consulte a vista geral da colocação em cache.
Para ver o que o Cloud CDN está a publicar a partir de uma cache, pode ver registos.
Remover conteúdo da cache
Para remover um item de uma cache, pode invalidar o conteúdo em cache. Para mais informações, consulte:
Ignorar a cache
Para ignorar a CDN da nuvem, pode pedir um objeto diretamente a partir de um contentor do Cloud Storage ou de uma VM do Compute Engine. Por exemplo, um URL para um objeto de contentor do Cloud Storage tem o seguinte aspeto:
https://storage.googleapis.com/STORAGE_BUCKET/FILENAME
Despejo e expiração
Para que o conteúdo seja publicado a partir de uma cache, tem de ter sido inserido na cache, não pode ter sido removido e não pode ter expirado.
A remoção e a expiração são dois conceitos diferentes. Ambas afetam o que é publicado, mas não se afetam diretamente entre si.
Despejo
Se estiver a testar o armazenamento em cache de conteúdo com um pequeno número de pedidos, pode notar que o conteúdo é removido.
Cada cache tem um limite para a quantidade de dados que pode armazenar. No entanto, a RFC na nuvem adiciona conteúdo às caches, mesmo depois de estarem cheias. Para inserir conteúdo numa cache cheia, a cache remove primeiro outra coisa para criar espaço. A isto chama-se remoção. Normalmente, as caches estão cheias, pelo que estão constantemente a remover conteúdo. Geralmente, remove conteúdo ao qual não se acede recentemente, independentemente do tempo de expiração do conteúdo. O conteúdo removido pode ter expirado ou não. A definição de um tempo de expiração não afeta a remoção.
Conteúdo impopular refere-se a conteúdo que não é acedido há algum tempo. A while e unpopular são ambos relativos à maioria dos outros itens na cache. Vários Google Cloud projetos partilham um conjunto comum de espaço de cache porque os projetos são publicados a partir do mesmo conjunto de GFEs. A popularidade relativa do conteúdo é comparada em vários projetos e não apenas num único projeto.
À medida que as caches recebem mais tráfego, também removem mais conteúdo em cache.
Tal como acontece com todas as caches de grande escala, o conteúdo pode ser removido de forma imprevisível, pelo que não é garantido que um pedido específico seja publicado a partir da cache.
Expiração
O conteúdo nas caches HTTP(S) pode ter um tempo de expiração configurável. O tempo de expiração informa a cache para não publicar conteúdo antigo, mesmo que o conteúdo não tenha sido removido.
Por exemplo, considere um URL de imagem da hora. As respetivas respostas devem expirar em menos de uma hora. Caso contrário, o conteúdo publicado pode ser uma imagem antiga de uma cache.
Para obter informações sobre o ajuste preciso dos prazos de validade, consulte o artigo Usar definições e substituições de TTL.
Pedidos iniciados pelo Cloud CDN
Quando o servidor de origem suporta pedidos de intervalo de bytes, o Cloud CDN pode enviar vários pedidos ao servidor de origem em reação a um único pedido do cliente. Conforme descrito em Suporte para pedidos de intervalo de bytes, a RFC na nuvem pode iniciar dois tipos de pedidos: pedidos de validação e pedidos de intervalo de bytes.
Definições de localização de dados de outros serviços da Cloud Platform
A utilização do Cloud CDN significa que os dados podem ser armazenados em localizações de publicação fora da região ou da zona do seu servidor de origem. Isto é normal e é assim que a colocação em cache HTTP funciona na Internet. Ao abrigo dos Termos Específicos do Serviço dos Termos de Utilização da Google Cloud Platform, a Definição de Localização de Dados disponível para determinados Serviços da Cloud Platform não se aplica aos Dados de Clientes Principais do respetivo Serviço da Cloud Platform quando usado com outros produtos e serviços Google (neste caso, o serviço Cloud CDN). Se não quiser este resultado, não use o serviço Cloud CDN.
Suporte para certificados SSL geridos pela Google
Pode usar certificados geridos pela Google quando o Cloud CDN está ativado.
Integração com o Google Cloud Armor
O Google Cloud Armor com o Cloud CDN inclui dois tipos de políticas de segurança:
- Políticas de segurança de Edge. Estas políticas podem ser aplicadas aos seus servidores de origem com o Cloud CDN ativado. Aplicam-se a todo o tráfego antes da pesquisa da RFC.
- Políticas de segurança do back-end. Estas políticas são aplicadas apenas a pedidos de conteúdo dinâmico, falhas de cache ou outros pedidos destinados ao seu servidor de origem.
Para mais informações, consulte a documentação do Cloud Armor.
Integração com extensões de serviços
O Cloud CDN permite-lhe adicionar código personalizado ao caminho de processamento de pedidos dos balanceadores de carga de aplicações externos globais através de extensões de limite de extensões de serviços. Estas extensões ajudam a implementar personalizações no caminho do pedido de pré-cache e influenciam a forma como o conteúdo é colocado em cache na RFC na nuvem. Esta funcionalidade está em (pré-visualização).
Para mais informações, consulte o artigo Use extensões de serviços para computação de limite.
O que se segue?
- Para ativar o Cloud CDN para as instâncias com balanceamento de carga de HTTP(S) e os contentores de armazenamento, consulte o artigo Usar o Cloud CDN.
- Para usar o Cloud CDN com o Google Kubernetes Engine, consulte o artigo Configurar o Cloud CDN através do Ingress.
- Para encontrar pontos de presença da GFE, consulte o artigo Localizações da cache.