Projetar uma CDN

01 · CONTEXTO E REQUISITOS

O problema que uma CDN resolve

Uma CDN é uma rede de servidores espalhados pelo mundo cuja tarefa é entregar conteúdo da web por HTTP e HTTPS com eficiência, levando o que as pessoas consomem para perto de onde elas estão. Quem pede uma imagem, um script ou um trecho de vídeo é atendido por um servidor próximo, e não pelo servidor de origem do site.

Para desenhar uma, comece pelos requisitos. Do lado funcional, ela precisa servir objetos a partir de pontos de presença próximos, buscar na origem o que não tiver e permitir que um objeto alterado deixe de ser servido. Do lado não funcional, importam a latência baixa, uma alta proporção de pedidos atendidos sem tocar a origem, a proteção da origem contra picos e a continuidade do serviço quando um ponto de presença falha. Cada um desses requisitos vira uma decisão nas seções seguintes.

02 · CHEGAR À BORDA

Como o cliente encontra o POP certo

Antes de qualquer cache, é preciso levar o cliente a um ponto de presença próximo. Uma das formas é usar o DNS: ao resolver o nome do site, a resposta aponta para o POP que melhor atende aquele cliente, tipicamente o mais próximo em latência.

A segunda forma é o anycast, em que várias máquinas compartilham o mesmo endereço IP e os roteadores enviam o tráfego para a mais próxima. O benefício vai além da velocidade: como o endereço é o mesmo em todo lugar, um data center inteiro pode ser retirado do ar e o tráfego passa a fluir para o próximo mais próximo. Em compensação, o anycast não é trivial de implementar.

1. Três POPs anunciam o mesmo endereço. Para o cliente, existe um único endereço da CDN.

2. Os roteadores enviam o pedido do navegador para o POP mais próximo na rede.

3. O POP próximo sai do ar. Ele deixa de atender e o pedido seguinte do navegador precisa de outro destino.

4. A própria rede passa a levar o navegador ao próximo POP mais próximo, sem mudar o endereço que o cliente usa.

Existe ainda uma terceira família de soluções, usada por quem controla o que cada servidor guarda. O serviço de direcionamento da Netflix escolhe os appliances e gera as URLs que o cliente vai usar, considerando a disponibilidade dos arquivos, a saúde dos servidores e a proximidade de rede com o cliente.

03 · O CAMINHO DE UM PEDIDO

Acerto, falha e as camadas de cache

1. O navegador resolve o nome e o DNS da CDN indica o POP mais adequado para ele.

2. O navegador pede o objeto ao POP. Se ele estiver no cache, a CDN o devolve ali mesmo e o pedido termina na borda.

3. Se o POP não tem o objeto, ele pergunta à camada de cima, o cache regional, antes de ir à origem.

4. Se nenhuma camada tem o objeto, o pedido chega à origem, que busca o arquivo original no armazenamento.

5. O objeto volta pelo mesmo caminho e cada camada o guarda para o próximo pedido.

O cache regional existe porque o espaço de um POP é limitado. Ele é maior e mantém os objetos por mais tempo, e os POPs de uma região o compartilham, o que elimina pedidos repetidos à origem. Esse cache funciona como camada intermediária e consolida os pedidos que chegam à origem. O efeito é que a origem passa a ver poucas conexões, vindas de poucos lugares.

Há um segundo efeito de proteção: quando pedidos idênticos chegam ao mesmo tempo a um cache compartilhado, ele encaminha uma única requisição à origem e reaproveita a resposta para todos os clientes. Isso se chama colapso de requisições, e é o que impede um objeto popular recém-expirado de gerar uma enxurrada de pedidos à origem.

04 · FRESCOR DOS DADOS

Por quanto tempo guardar e como atualizar

Guardar é fácil; difícil é saber até quando. Cada resposta no cache tem uma idade, o tempo desde que foi gerada, e o tempo máximo de validade funciona como o TTL de outros caches. Passado esse tempo, a resposta fica vencida, mas ela pode ser revalidada perguntando à origem se continua valendo, em vez de ser baixada de novo por inteiro.

Para o que nunca muda, a prática é dar uma vida longa ao objeto e colocar a versão ou um hash na URL: quando o conteúdo muda, a URL muda. Já quando a resposta varia conforme o idioma, por exemplo, o cabeçalho Vary faz a chave do cache combinar a URL com o cabeçalho da requisição, e cada variante é guardada separadamente.

Se for preciso trocar um arquivo antes de ele vencer, há duas saídas: invalidar o objeto nas bordas ou publicar uma nova versão com outro nome. Quem atualiza arquivos com frequência deve preferir os nomes versionados.

05 · PUXAR OU PRÉ-POSICIONAR

Cache por demanda e preenchimento proativo

Tudo até aqui é o modelo por demanda: o objeto só chega à borda depois que alguém o pede. A Netflix partiu de outra premissa para a sua rede: desenhou uma solução proativa e dirigida, considerada por ela muito mais eficiente que a CDN tradicional por demanda. Os appliances informam ao plano de controle sua saúde e quais arquivos têm em disco, e a maior parte das atualizações de conteúdo é levada a eles em janelas fora do pico.

1. Os appliances relatam ao plano de controle sua saúde e os arquivos que têm em disco.

2. Em janelas fora do pico, o acervo preenche os appliances com o conteúdo que o plano de controle decidiu posicionar.

3. Quando alguém pede a reprodução de um título, o pedido passa pelo plano de controle.

4. O plano de controle considera disponibilidade dos arquivos, saúde e proximidade e gera a URL do appliance escolhido.

5. O aparelho baixa o vídeo direto do appliance, sem passar pela origem.

A escolha entre os dois modelos é uma troca. O cache por demanda é simples e serve qualquer conteúdo, mas o primeiro pedido de cada objeto paga o caminho até a origem. O preenchimento proativo evita esse primeiro pedido, porém exige prever o que será assistido e quando, o que só funciona para conteúdo previsível, como um catálogo de vídeos.