🥇Configurando e otimizando seu CDN

As redes de entrega de conteúdo (CDN) são usadas em sites e aplicativos principalmente para acelerar o carregamento de elementos estáticos. Isso ocorre através do cache de arquivos em servidores CDN localizados em diferentes regiões geográficas. Ao solicitar dados via CDN, o usuário os recebe do servidor mais próximo.

O princípio de funcionamento e funcionalidade de todas as redes de entrega de conteúdo é aproximadamente o mesmo. Ao receber um pedido de carregamento de arquivo, o servidor CDN pega-o uma única vez do servidor original e o entrega ao usuário, ao mesmo tempo em que faz o cache por um período determinado. Para todas as solicitações subsequentes, a resposta é fornecida a partir do cache. Todas as CDNs possuem opções de pré-carregamento de arquivos, limpeza de cache, configuração do prazo de armazenamento e muito mais.

Às vezes, por vários motivos, pode ser necessário organizar sua própria rede de entrega de conteúdo, e, então, que venha em nosso auxílio um guia para montar mais um projeto.

Fonte: Infographic vector created by pikisuperstar — www.freepik.com

Quando é necessário um CDN próprio

Vamos considerar os casos em que faz sentido lançar um CDN próprio:

quando há desejo de economizar, e as despesas atuais, mesmo ao utilizar CDNs baratos como BunnyCDN são de algumas centenas de dólares por mês
se desejamos obter cache constante ou cache sem vizinhos no servidor e na banda
não há pontos de presença de serviços CDN na região desejada
são necessárias configurações especiais para a entrega de conteúdo
queremos acelerar a entrega de conteúdo dinâmico, colocando os servidores de produção mais próximos dos usuários
tememos que um serviço CDN de terceiros possa coletar ou usar indevidamente informações sobre o comportamento dos usuários (olá serviços que não cumprem com a GDPR) ou realizar outras ações inadequadas

Na maioria dos outros casos, é mais sensato usar soluções prontas existentes.

O que é necessário para o lançamento

É ótimo se você tiver seu próprio sistema autônomo (AS). Com ele, é possível atribuir um IP idêntico a vários servidores e seguir este guia direcionar usuários para o mais próximo a nível de rede. Vale dizer que mesmo com um bloco de endereços /24, é possível construir uma rede de entrega de conteúdo. Alguns provedores de servidores permitem fazer um anúncio para uso em todas as regiões disponíveis para eles.

Se você não é o feliz proprietário de um bloco de endereços IP, precisará de alguns itens para iniciar um CDN simples:

um nome de domínio ou subdomínio
pelo menos dois servidores em diferentes regiões. O servidor pode ser dedicado ou virtual
uma ferramenta geoDNS. Com ela, o usuário, ao acessar o domínio, será direcionado para o servidor mais próximo

Registramos o domínio e pedimos os servidores

A registracão do domínio é simples — registramos em qualquer zona com qualquer registrador. Também é possível usar um subdomínio para o CDN, como algo do tipo cdn.seudomínio.com. De fato, neste exemplo, faremos exatamente isso.

Quanto à solicitação de servidores — é importante alugá-los nas regiões e países onde sua audiência está localizada. Se o projeto for intercontinental, é conveniente escolher provedores de hospedagem que oferecem servidores em todo o mundo. Exemplos: OVH, Leaseweb e 100Tb — para servidores dedicados, Vultr e DigitalOcean — para nuvem virtual*.

Para nosso CDN privado, vamos solicitar 3 servidores virtuais em diferentes continentes. Em Vultr cada servidor por $5/mês teremos 25GB SSD espaço e 1TB de tráfego. Ao instalar, escolheremos a versão mais recente do Debian. Nossos servidores:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Cingapura, ip: 157.230.240.216

* Vultr e DigitalOcean oferecem $100 de crédito para usuários que se registram através dos links do artigo, assim que o método de pagamento for adicionado. O autor também recebe uma pequena comissão, o que é bastante significativo para ele neste momento. Por favor, compreenda.

Configurando geoDNS

Para que o usuário, ao acessar o domínio ou subdomínio do CDN, seja direcionado para o servidor correto (mais próximo dele), precisamos de um servidor DNS com função geoDNS.

O princípio e a ordem de funcionamento do geoDNS são os seguintes:

Determina o IP do cliente que fez a consulta DNS, ou o IP do servidor DNS recursivo usado para processar a solicitação do cliente. Esses servidores recursivos geralmente são os DNS dos provedores.
Pelo IP do cliente, descobre seu país ou região. Para isso, são usadas bases de dados GeoIP, das quais existem muitas atualmente. Existem algumas opções gratuitas bastante boas.
Dependendo da localização do cliente, fornece o IP do servidor CDN mais próximo.

Um servidor DNS com função geoDNS pode compilado de forma independente, mas é melhor usar soluções prontas com uma rede de servidores DNS em todo o mundo e Anycast de forma simplificada:

ClouDNS de $9.95/mês, plano GeoDNS, que tem um DNS Failover por padrão
Zilore de $25/mês, inclui DNS Failover
Amazon Route 53 de R$35/mês para 50M de consultas geográficas. O DNS Failover é cobrado separadamente
DNS Made Easy de R$125/mês, com 10 DNS Failover
Cloudflare, a funcionalidade 'Geo Steering' está disponível nos planos Enterprise

Ao pedir geoDNS, é importante prestar atenção no número de consultas incluídas no plano e considerar que o número real de acessos ao domínio pode ser muito maior do que o esperado. Milhões de robôs, scanners, spammers e outras entidades estão sempre ativos.

Praticamente todos os serviços de DNS incluem um serviço essencial para a construção de CDN — DNS Failover. Com ele, é possível configurar a monitorização do funcionamento dos seus servidores e, caso não haja sinais de atividade, substituir automaticamente nos DNS responses o endereço do servidor inativo pelo reserva.

Para construir nossa CDN, utilizaremos ClouDNS, o plano GeoDNS.

Adicionaremos uma nova zona DNS no painel, especificando seu domínio. Se a CDN for construída em um subdomínio e o domínio principal já estiver em uso, não se esqueça de adicionar as entradas DNS existentes após adicionar a zona. O próximo passo é criar várias entradas A para o domínio/subdomínio da CDN, cada uma sendo aplicada para a região que definimos. Os regionais podem incluir continentes ou países, com sub-regiões disponíveis para os EUA e Canadá.

Neste caso, a CDN será criada no subdomínio cdn.sayt.in. Após adicionar a zona sayt.in, criaremos a primeira entrada A para o subdomínio e direcionaremos toda a América do Norte para o servidor em Chicago:

Repetiremos a ação para outras regiões, sem esquecer de criar uma entrada para as regiões padrão. Veja como ficará no final:

A última entrada padrão na captura de tela indica que todas as regiões não especificadas (como Europa, África, usuários de internet via satélite, etc.) serão direcionadas para o servidor em Frankfurt.

Com isso, a configuração básica do DNS está concluída. Agora, acesse o site do registrador de domínio e substitua os NS atuais do domínio pelos que foram fornecidos pelo ClouDNS. Enquanto os NS estão sendo atualizados, vamos preparar os servidores.

Instalação de certificados SSL

Nossa CDN funcionará via HTTPS, portanto, se você já possui certificados SSL para o domínio ou subdomínio, faça o upload deles em todos os servidores, por exemplo, no diretório /etc/ssl/вашдомен/

Se não houver certificados, você pode obter um gratuito do Let’s Encrypt. Para isso, um bom recurso é ACME Shell script. O cliente é conveniente e fácil de configurar, e o mais importante — permite a validação de domínio/subdomínio via DNS através da API da ClouDNS.

Instalaremos o acme.sh apenas em um dos servidores — o europeu 199.247.18.199, e dele os certificados serão copiados para os demais. Para a instalação, execute:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Durante a instalação do script, será criado um job CRON para a atualização automática dos certificados sem nossa intervenção.

A verificação do domínio ao emitir o certificado será realizada via DNS utilizando a API, portanto, no painel de controle da ClouDNS, no menu Reseller API, é necessário criar um novo usuário de API e definir uma senha para ele. O auth-id obtido com a senha será registrado no arquivo ~/ .acme.sh/dnsapi/dns_cloudns.sh (não confundir com o arquivo dns_clouddns.sh). Aqui estão as linhas que precisam ser descomentadas e editadas:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Agora vamos solicitar a obtenção do certificado SSL para cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

Nos parâmetros, para o futuro, especificamos o comando para recarregar automaticamente a configuração do servidor web após cada renovação do certificado.

Todo o processo de obtenção do certificado pode levar até 2 minutos, não interrompa-o. Se ocorrer um erro de validação do domínio, tente executar o comando novamente. No final, veremos onde os certificados foram armazenados:

Lembre-se desses caminhos, eles precisarão ser indicados ao copiar o certificado para outros servidores, assim como nas configurações do servidor web. Não se preocupe com o erro ao recarregar as configurações do Nginx, — em um servidor totalmente configurado, esse erro não aparecerá durante a atualização dos certificados.

Tudo o que nos resta para o SSL é copiar o certificado obtido para outros dois servidores, mantendo o caminho para os arquivos. Criaremos em cada um deles diretórios semelhantes e faremos a cópia:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Para que a atualização dos certificados seja regular, criaremos um job CRON diário em ambos os servidores com o comando:

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Nesse caso, o acesso ao servidor remoto de origem deve ser configurado por chave, ou seja, sem a necessidade de inserir a senha. Não se esqueça de fazer isso.

Instalação e configuração do Nginx

Para a entrega de conteúdo estático, utilizaremos o Nginx configurado em modo de proxy cache. Vamos atualizar as listas de pacotes e instalá-lo em todos os três servidores:

root@cdn:~# apt update
root@cdn:~# apt install nginx

Em vez da configuração padrão, usaremos a configuração do spoiler abaixo:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  } 
}

No arquivo de configuração, vamos editar:

max_size — o tamanho do cache, não excedendo o espaço disponível em disco
inactive — o tempo de armazenamento dos dados em cache que não foram acessados
ssl_certificate e ssl_certificate_key — caminhos para os arquivos do certificado SSL e da chave
proxy_cache_valid — o tempo de armazenamento dos dados em cache
proxy_pass — o endereço do servidor original, de onde o CDN solicitará os arquivos para cache. No nosso exemplo, é sayt.in

Como podemos ver, tudo é simples. A complexidade pode surgir na configuração do tempo de cache devido à semelhança das diretivas inactive e proxy_cache_valid. Vamos analisá-las no nosso exemplo. Aqui está o que acontece com inactive=7d e proxy_cache_valid 90d:

se a solicitação não se repetir dentro de 7 dias, os dados serão removidos do cache após esse período
se a solicitação ocorrer pelo menos uma vez a cada 7 dias, os dados em cache serão considerados desatualizados após 90 dias e, na próxima solicitação, o Nginx os atualizará, pegando do servidor original

Depois de terminar de editar nginx.conf, reiniciaremos a configuração:

root@cdn:~# service nginx reload

Nosso CDN está completamente pronto. Por $15/mês, nós obtivemos pontos de presença em três continentes e 3 TB de tráfego: 1 TB em cada localização.

Verificando o funcionamento do CDN

Vamos observar os pings para o nosso CDN a partir de diferentes localizações geográficas. Qualquer serviço de ping servirá.

Ponto de partida
Host
IP
Tempo médio, ms

Alemanha, Berlim
cdn.sayt.in
199.247.18.199
9.6

Países Baixos, Amsterdã
cdn.sayt.in
199.247.18.199
10.1

França, Paris
cdn.sayt.in
199.247.18.199
16.3

Reino Unido, Londres
cdn.sayt.in
199.247.18.199
14.9

Canadá, Toronto
cdn.sayt.in
149.28.121.123
16.2

EUA, São Francisco
cdn.sayt.in
149.28.121.123
52.7

EUA, Dallas
cdn.sayt.in
149.28.121.123
23.1

EUA, Chicago
cdn.sayt.in
149.28.121.123
2.6

EUA, Nova York
cdn.sayt.in
149.28.121.123
19.8

Cingapura
cdn.sayt.in
157.230.240.216
1.7

Japão, Tóquio
cdn.sayt.in
157.230.240.216
74.8

Austrália, Sydney
cdn.sayt.in
157.230.240.216
95.9

Os resultados estão bons. Agora vamos colocar uma imagem teste na raiz do site principal test.jpg e verificar a velocidade de carregamento através do CDN. Disse-se, — feito. O conteúdo é entregue rapidamente.

Vamos escrever um pequeno script caso queiramos limpar o cache no ponto do CDN.
purge.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

Para remover todo o cache, basta executá-lo; um arquivo separado pode ser limpo assim:

root@cdn:~# ./purge.sh /test.jpg

Em vez das saídas

Por fim, quero dar algumas dicas úteis para que você possa evitar os mesmos erros que me causaram dor de cabeça no passado:

Para aumentar a resiliência do CDN, é recomendado configurar o DNS Failover, que ajuda a mudar rapidamente o registro A em caso de falha do servidor. Isso é feito no painel de controle dos registros DNS do domínio
Sites com ampla cobertura geográfica definitivamente exigem um grande número de pontos de CDN, mas vamos com calma. Provavelmente, o usuário não notará uma diferença significativa em comparação ao CDN pago, se você colocar servidores em 6-7 locais: Europa, América do Norte (leste), América do Norte (oeste), Singapura, Austrália, Hong Kong ou Japão
Às vezes, os provedores de hospedagem não permitem o uso de servidores alugados para fins de CDN. Portanto, se você decidir implantar uma rede de entrega de conteúdo como serviço, não se esqueça de ler as regras do provedor de hospedagem específico com antecedência
Estude o mapa de comunicações submarinas, para entender como os continentes estão interconectados e considerar isso ao construir a rede de entrega de conteúdo
Tente verificar os pings de diferentes locais para seus servidores. Assim, é possível ver as regiões mais próximas aos pontos do CDN e configurar melhor o GeoDNS
Dependendo das tarefas, pode ser útil ajustar o Nginx para demandas específicas de cache e levando em conta a carga no servidor. Isso me ajudou muito, com artigos sobre cache do Nginx — aqui e aceleração de desempenho sob alta carga: aqui e aqui