Varnish e backends com IPs dinâmicos

Até as versões atuais do Varnish, existe uma limitação na hora de especificar backends na configuração do VCL: não é possível usar IPs dinâmicos ao definir um backend. Em outras palavras, você não pode ter backends que você não saiba o IP. Em alguns casos, é necessário colocar na definição de backend um hostname, ao invés de um IP fixo. Se por acaso você mudar o IP deste hostname, o Varnish não vai ser atualizado com o novo IP, a não ser que você recompile o VCL (vcl.load e vcl.use).

Em tempos de cloud computing, isso é uma limitação bem forte. Serviços como a Amazon Web Services tem balanceadores de carga que mudam o IP frequentemente. Se você usa Amazon Elastic Load Balancing ou Amazon S3 por exemplo, não há como saber ao certo quais os IPs dos balanceadores e servidores de arquivos estáticos.

Ou se você quer fazer cache de itens de outros servidores na Internet que não são do seu controle, você nunca tem a garantia que o pessoal do outro lado vá mudar de repente o IP do domínio do serviço ou site.

Essa limitação tem uma explicação: desempenho. Quando fazemos uma configuração VCL e carregamos no Varnish, esta configuração na verdade é compilada em código binário para que o fluxo de suas regras seja feito sempre com desempenho bom, como é a característica de programas compilados feitos em C. Nessa compilação do VCL, um dos passos é resolver os nomes dos backends e deixar registrado apenas os IPs, ou seja, a resolução do hostname é feita apenas na compilação. Com isso, o próprio Varnish tem um desempenho melhor por não ter que ficar fazendo chamadas de sistema para resolver o hostname.

Deixar de resolver o hostname nas requisições aumenta o desempenho porque o próprio Varnish não precisa esperar por ninguém (processos externos de resolução, ou espera de rede, o que seja). Com todas as informações armazenadas internamente, as coisas ficam muito mais rápidas. Em um Varnish que serve milhares de requisições por segundo, essa economia que parecia pouca coisa começa a ficar bem significativa.

Existe uma discussão em torno do assunto, com os próprios desenvolvedores do Varnish:

• https://www.varnish-software.com/blog/truly-dynamic-backend-definition-varnish (em inglês)

No link, há uma discussão mais técnica de como isto poderia ser feito dentro do design do Varnish. Eles querem fazer isso (pois dá mais poder e flexibilidade ao programa), mas como costumam fazer, precisa ser com qualidade e não pode de maneira alguma impactar em desempenho (um dos principais diferenciais do Varnish).

Enquanto não resolvem internamente… uma solução

Se você não pode esperar esta funcionalidade ser implementada no Varnish, existe uma solução (um pouco gambiarra, mas funciona muito bem): implementar (mais) um intermediário entre o Varnish e o servidor backend. Uma sugestão minha é utilizar o nginx, que faz o papel de intermediador muito bem também.

Não vou entrar na parte de instalação e configuração básica do nginx. Considere este um pré-requisito para este artigo :)

A idéia é usar o nginx na mesma máquina que o Varnish, em uma porta interna, servindo apenas de proxy para o backend. No exemplo deste artigo, vamos imaginar que eu queira servir e fazer cache do conteúdo estático do servidor devin.s3.amazonaws.com. Esse IP, por ser da Amazon S3, é totalmente dinâmico e vai mudar constantemente. A configuração do nginx ficaria assim:

server {
  listen 31337;

  location / {
    proxy_pass http://devin.s3.amazonaws.com;
    #proxy_set_header Host devin.s3.amazonaws.com; # Não necessário, o nginx já busca com o cabeçalho host certo
  }
}

O nginx vai passar todas as requisições da porta 31337 para o devin.s3.amazonaws.com, pegar o item e entregar para o cliente. No nosso caso, o cliente é o Varnish, e a configuração do backend seria algo assim:

backend devin_s3 {
  .host = "127.0.0.1";
  .port = "31337";
    .probe = {
      .url = "/health_check.html";
      .interval = 5s;
      .timeout = 3s;
      .window = 8;
      .threshold = 3;
      .initial = 2;
  }
}

Pronto. Agora toda vez que você usar o backend devin_s3 no Varnish, ele estará usando o nginx, que por sua vez pega os itens do S3 (com IP dinâmico). O IP do nginx será sempre 127.0.0.1, então o problema com o IP dinâmico no Varnish não vai existir. Enquanto isso, o nginx já trata a resolução de IPs dinâmicos de forma satisfatória: chamadas de sistema, cache baseado no TTL, trata redirects, e por aí vai.

A solução pode gerar um pouco de delay na hora de buscar um ou outro item do backend, mas nada muito preocupante. Como o Varnish pode fazer cache dos itens, na prática o nginx vai precisar fazer pouquíssimas requisições de DNS. É uma troca justa :)

Mas tenham certeza, quando isso for implementado no Varnish, o desempenho será superior :)

Referências

• http://www.ducea.com/2009/08/04/using-varnish-in-front-of-your-amazon-s3-static-content/ (em inglês)
• https://www.varnish-cache.org/lists/pipermail/varnish-misc/2011-November/021374.html (em inglês)
• https://www.varnish-software.com/blog/truly-dynamic-backend-definition-varnish (em inglês)