Logo do NGINX

NGINX: Utilizando cache em uma CDN [parte 2] — Invalidação de cache

Um outro caso que ocorre em uma CDN é que dependendo da regra de uso a informação precisa ser buscada no servidor de origem, exemplo: Uma folha de estilo CSS, não é algo que atualizamos com frequência, então poderíamos deixá-la na nossa memória em cache. Mas e se eu preciso invalidar devido a uma atualização na minha folha de estilo?

A maneira de fazer essa invalidação é por meio do purge, porém ele só está disponível no NGINX Plus (versão paga). Na versão gratuita podemos fazer um bypass, uma condição na requisição que faz a chamada ir até o servidor de origem ou algumas configurações como tempo de vida.

O projeto de demonstração completo desse artigo e da parte 1 está no meu github, você consegue acessar com o link abaixo para modificar alguns parâmetros e brincar ^^

https://github.com/lalizita/nginx-cache

Tempo de vida

Como vimos no artigo anterior, o cache no NGINX nada mais é do que arquivos com as respostas do servidor de origem que ficam armazenados no diretório que foi definido na propriedade proxy_cache_path.

Esses arquivos são monitorados por um processo chamado cache manager, o qual verifica os parâmetros max_size e min_free (espaço livre) para quando o espaço ou tempo de vida forem excedidos os dados mais antigos sejam removidos.

print da tela exibindo o diretório com os arquivos de cache e o conteúdo de um deles

Quando a regra de negócio exige que tenhamos uma invalidação de cache, a primeira coisa que devemos pensar é colocar um tempo limite para a sua existência. Com NGINX conseguimos definir esse tempo por meio do parâmetro inactive na diretiva proxy_cache_path.

proxy_cache_path /etc/nginx/cache keys_zone=mycache:10m inactive=10s;

inactive: (seu valor default é 10m). Define um tempo limite para a existência do arquivo de cache, no exemplo acima caso não seja utilizado em 10 segundos ele será removido pelo cache manager.

Bypass (versão gratuita)

Bypass é uma regra definida na diretiva proxy_cache_bypass para que a resposta não venha do cache forçando a chamada ir até o servidor de origem a partir de alguns argumentos como o ?nocache=true. A chamada também irá atualizar o X-Cache-Status para BYPASS.

location / {
    proxy_pass http://server:8082;
#   [...]
    proxy_cache_bypass $arg_nocache;
}

Script para teste

curl -X GET 'http://localhost:8081?nocache=true'

Significado das siglas no x-cache-status:

• HIT: A resposta é do cache.
• MISS: A resposta é do servidor de origem.
• BYPASS: A resposta é do servidor de origem devido ao parâmetro nocache=true que foi configurado na diretiva proxy_cache_bypass.

Veja no GIF abaixo o status do cache no header da resposta:

gif da requisição para a location configurada exibindo o cache status no header da resposta.

Configuração completa no nginx.conf

Purge (NGINX Plus)

Existe uma definição na área de programação chamada Data Purging que significa a remoção permanente de dados obsoletos de um armazenamento específico, o que para nós significaria a invalidação dos dados em cache.

O NGINX Plus (versão paga) disponibiliza uma configuração para que o purge dos seus dados possa ser feito por meio de um método HTTP especial no qual fará o seu servidor buscar a resposta da requisição no servidor de origem.

Com essa configuração do proxy_cache_purge, pode ser definido um servidor específico para fazer essa request e algumas outras configurações de segurança que são descritas aqui na documentação:

NGINX Content Caching

Veja como fica a configuração do proxy_cache_purge:

http {
    # ...
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=mycache:10m purger=on;

    map $request_method $purge_method {
        PURGE 1;
        default 0;
    }

    server {
        listen      80;
        server_name www.example.com;

        location / {
            proxy_pass        https://localhost:8002;
            proxy_cache       mycache;
            proxy_cache_purge $purge_method;
        }
    }

    geo $purge_allowed {
       default         0;
       10.0.0.1        1;
       192.168.0.0/24  1;
    }

    map $request_method $purge_method {
       PURGE   $purge_allowed;
       default 0;
    }
}

Request com o método HTTP Purge

$ curl -X PURGE -D – "https://www.example.com/*"

Não tenho projeto completo do purge para que você possa testar alterando alguns parâmetros, porém você já sabe da existência dele caso a sua empresa queira investir e passar a utilizar o NGINX Plus recomendo muito pois é uma maneira bem mais simples de resolver a invalidação e ainda tem configurações de segurança mais simples de serem feitas.

Finalizando

NGINX ainda tem muitas funcionalidades que podem nos ajudar quanto a servidor e nesses 2 artigos exploramos as possibilidades de cache sem utilizar nenhum módulo.

Configurar cache em algumas partes do seu sistema te previne de muitos problemas como derrubar alguma aplicação por excesso de processos abertos, diminuição de custos e ainda melhora performance para o cliente com acesso rápido à informação requisitada. Espero que essa leitura tenha servido de base para você conseguir se aprofundar mais e saber lidar quando necessário.

Veja o projeto completo: https://github.com/lalizita/nginx-cache