Varnish cache

Varnish CacheImplementação no clicRBS

Agenda

O projeto Varnish Cache

A implementação no clicRBS

Configuração

Alta disponibilidade e performance

Monitoramento

Logs

Extensões via VMODs

O Projeto Varnish Cache

O Projeto Varnish Cache

Iniciado por Poul-Henning Kamp, desenvolvedor líder no tabloide norueguês Verdens Gang. Teve a primeira versão publicada em 2006.

Criado na linguagem C sob a licença BSD (Bekerley Software Distribution).

Está na versão 4.0, no clicRBS usamos a versão 3.0.4 (em Maio/2014).

Utilizado por grandes empresas de conteúdo, dentre elas BBC e Globo.com

Tem versão open source (via varnish-cache.org) e comercial via a empresa Varnish Cache (varnish-cache.com)

Por que o Varnish?

1. Open Source

1. Iniciativas de tornar o clicRBS viável com produtos open source;

2. Confiabilidade

1. Precisava ter a confiabilidade conquistada pelo Oracle WebCache;

3. Fácil configuração

1. A equipe de infra não poderia ter que seguir processos para implementar modificações no cache

4. Otimizado para sistemas Linux

1. Os servidores do clicRBS são Linux, a implementação do HTTP Cache teria que ter aderência primária para essa plataforma de sistema operacional.

Implementação no clicRBS

Requisitos para o clicRBS

Oracle WebCache como servidor de cache primário, o Varnish precisa “comportar-se” como WebCache para os mecanismos de entrega e invalidação.

Por mecanismos de entrega, entenda Caixa Cisco.

Por mecanismos de invalidação, entenda Vinas.

As aplicações usam recursos direcionados para o WebCache, como o suporte a tags ESI, o Varnish precisa usar o mesmo dialeto para processar as mesmas tags ESI.

Requisitos do Varnish no clicRBS

Vinas

Persistência de sessão

HTTPS

O VARNISH NÃOSUPORTA SSL

Invalidações de conteúdo

O Varnish suporta dois tipos de invalidação:

Por parão de URL

Por URL completa

Invalidar o quê?

Invalidações de conteúdo

Quando você invalida um conteúdo em um HTTP Cache, o que você espera atingir?

Como você notifica aos milhares, ou milhões, de usuários navegando em seu site que o conteúdo foi expirado no cache?

Seu site tem uma política de cache de conteúdo alinhada com o que fica no cliente e o que não pode ficar?

Para o conteúdo que fica no cliente, quando fazer “conditional get”?

Você pensa no consumo de banda do usuário do seu site quando você usa “don´t cache” no servidor de HTTP Cache?

Invalidações....

Dados...

Os sites do clicRBS passaram a ser servidos por apenas servidores Varnish em 17 de Abril de 2014. Desde essa data não havia nenhuma entrega por Oracle WebCache;

De 17 de Abril de 2014 a 29 de Abril de 2014 o clicRBS ficou sem NENHUM mecanismo de invalidação de cache ativo. O mecanismo existia, mas não estava configurado.

O mecanismo de invalidação de cache foi configurado no clicRBS em 29 de Abril de 2014, mas continua ate hoje desligado o mecanismo de invalidações automáticas para conteúdos. O mecanismo automático não mais será ativado!

Log de requisições

O Varnish precisava ter suporte a log de requisições usando o formato Apache Common Format.

Usamos os logs de acesso nos sites para envio para o IVC.

Configuração

Configuração

Usamos a versão 3.0.4 do Varnish compilando a partir do fonte.

A compilação permite a customização de diretórios de instalação e configuração.

Linguagem de configuração do Varnish: VCL – Varnish Configuration Language

Configuração - VCL

VCL

O Varnish é configurado via sua linguagem de descrição de configuração;

A sintaxe parece com uma estrutura json com definição de rotinas;

Há uma ordem de execução das rotinas, como mostrado no slide anterior;

A configuração é sobre-escrita apenas no ponto de modificação.

A linguagem trabalha com tipos próprios e não contém estruturas completas de uma linguagem de programação (por isso é de configuração!).

VCL

A solicitação inicia na rotina vcl_recv.

O documento pode ser lido do cache (lookup) ou diretamente do servidor (pass ou miss).

Quando a estratégia lookup é selecionada, a rotina vcl_hash cria o identificador único da URL para que o Varnish possa localizar o conteúdo no cache.

O documento retornado do servidor pode “informar” ao varnish para não reter aquela cópia em cache.

O Varnish trata a solicitação via a rotina vcl_deliver antes de entregar a resposta ao cliente.

Definições de VCL

- Um backend é, para o Varnish, o servidor de origem que contém a página.

- Sendo o Varnish um proxy reverso, ele irá buscar o conteúdo em um servidor, caso o conteúdo não esteja com ele.

- Um backend tem as propriedades:

- Host: identificação de rede do backend

- Port: qual porta atende o serviço

- Probe: como validar se o serviço no backend está funcionando.

- Múltiplos backends podem agir com um só em uma configuração denominada director.

BACKEND

Definições de VCL

- ACL é Access Control List. O Varnish permite criar restrições de acesso para recursos, seja por qual informação for.

- Usamos ACL no Varnish para que ele aceite invalidações pelos servidores do CMS.

- Podemos implementar ACLs para restringir um conteúdo a apenas acessos internos, por exemplo.

- A verificação é feita por VCL, logo é possível usar qualquer atributo da solicitação, da URL à cabeçalhos HTTP, por exemplo.

ACL

Definições de VCL

- Probe é um atributo de um backend.

- O Varnish não “deixa” o usuário saber que um servidor está com problemas. Ele usa as definições de probe, para de forma pró-ativa, verificar os backends. Os backends inaptos não recebem solicitações dos usuários.

PROBE

Definições de VCL

- O Varnish usa três escopos de cache:

- LOOKUP: o documento deverá ser lido do cache, caso não exista, será lido no servidor e armazenado no cache. O tempo de armazenado é definido pelo cabeçalho Cache-Control, ou na sua ausência, pela diretiva de DEFAULT_TTL.

- PASS: o documento será entregue do cache, mas será antes buscado no servidor de aplicações. O cache age como um buffer.

- PIPE: o documento será entregue diretamente do servidor, sem usar a estrutura de cache e fail over.

ESCOPO DE CACHE

Definições de VCL

- Rotina responsável por iniciar o processamento da solicitação.

- Nela são tomadas as decisões para:

- Diferenciação mobile;

- Seleção de backend;

- Estratégia de cache;

- Redefinição de informações de solicitação etc.

vcl_req

Definições de VCL

- Rotina responsável por criar o identificador único da URL para o cache.

- Utilizamos vcl_hash para distinguir documentos com e sem paywall no clicRBS. vcl_hash

Definições de VCL

- Rotina responsável por buscar, por isso fetch, o documento no servidor de aplicações.

- Permite a customização da solicitação para o servidor de aplicações, bem como permite a configuração de como o varnish irá servir o documento (se do cache ou não, com gzip ou não, com esi ou não).

- Usamos vcl_fetch no clic para habilitar o suporte a ESI através do cabeçalho Surrogate-Control

- Também usamos no vcl_fetch a instrução de ignore cache no Varnish de acordo com o cabeçalho Surrogate-Control.

vcl_fetch

Definições de VCL

- Rotina responsável por tratar a resposta para o usuário removendo informações que julgamos desnecessárias, dentre elas temos os cabeçalhos:

- Surrogate-Control: contém dialeto Oracle WebCache

- Server: exposição desnecessária da implementação do servidor de aplicações;

- Content-Location: exposição desnecessária da localização de recursos no servidor abaixo das URLs amigáveis.

- Cabeçalhos de controle de cache: usamos três cabeçalhos de controle de cache que permitem a invalidação pelo vinas.

vcl_deliver

Definições de VCL

- O Varnish permite definir rotinas customizadas. Usamos isso para implementar a identificação de mobile. Hoje identificamos os dispositivos:

- iPhone, iPad, tablet Android, phone Android, Firefoxos, bots, mobile smartphone (que não seja Android nem iOS) e mobile genéric (telefone com WAP).

rbs_mobile

Tempo de vida em cache

O Varnish usa o cabeçalho Cache-Control, enviado pelo servidor de aplicações, para controlar o tempo de vida do documento em cache.

O header Age é gerado pelo Varnish para que o navegador possa calcular corretamente o tempo que o objeto pode ser considerado válido.

O Varnish NÃO modifica cabeçalhos da requisição SENÃO por definição no VCL. Usamos no clic a inclusão do cabeçalho Cache-Control via VCL para SOMENTE as páginas que não o definem e, com isso, caem na regra de DEFAULT_TTL.

Alta disponibilidade

Alta disponibilidade

A alta disponibilidade de entrega no Varnish é feita via três mecanismos de garantia de entrega:

1. Probe: o mecanismo principal para garantir que o Varnish não encaminhe a solicitação para um servidor que não está apto a fazer entregas;

2. Director: um director é uma composição de backends, tal que o Varnish lida com todos como se fossem um só. Via Director é possível implementar mecanismos de seleção sendo round-robin, round, random, fallback, cliente e dns.

3. Saint-mode: O mecanismo saint-mode apenas está disponível na configuração do tipo Director. Nela o Varnish valida a resposta do servidor, se for inadequada, o varnish repete a solicitação em outro servidor, sem interação com o usuário.

Probe

probe hc_it_80 {.request = "HEAD /rs/jsp/probe.jspx HTTP/1.1“

"Host: zerohora.clicrbs.com.br“"User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64;

rv:21.0) Gecko/20100101 Firefox/21.0“"Connection: close";

.interval = 10s;

.timeout = 0.5s;

.window = 9;

.threshold = 3;}

Director

backend enzo_7779 {

.host = "enzo.rbs.com.br";

.port = “7779";

.probe = hc_it_80;

}

director it_80 round-robin {

{ .backend = enzo_7779; }

{ .backend = jaguar_7779; }

{ .backend = lincolm_7779; }

{ .backend = bentley_7779; }

}

Saint-mode

sub vcl_fetch {

(...)

//Saint Mode for 10 seconds

if (beresp.status >= 500) {

set beresp.saintmode = 10s;

return(restart);

}

return(deliver);

}

Monitoramento

Monitoramento

O Varnish usa monitoramento ativo e tão efetivo que é possível assumir um comportamento reativo antes mesmo que os usuários no site comecem a perceber algum erro.

Via a api varnishadm o Varnish exporta dados de execução do runtime para que possam ser analisadas por mecanismos de acompanhamento de disponibilidade como Zabbix, por exemplo.

A api Varnishlog expõe com nível de detalhamento de mensagem de rede, como foi a verificação de disponibilidade do servidor de backend.

varnishlog

0 Backend_health - wp_clicrbs_com_br_80[1] Still sick 4--X-R- 0 3 9 0.640206 0.000000 HTTP/1.1 404 Not Found

0 Backend_health - www_clicrbs_com_br_80[0] Still healthy 4--X-RH 9 3 9 0.004539 0.004548 HTTP/1.1 301 Moved Permanent

Extensões do Varnish

VMODs (Varnish Modules)

O Varnish permite customização de configurações via inclusão de módulos compiláveis, escritos na linguagem C.

A instalação padrão traz o vmod std que contém rotinas utilitárias.

Os projetos de vmods são mantigos no github

Para compilar um vmod você só precisa do fonte do Varnish e baixar, ou criar o seu próprio fonte do vmod.

Performance

Performance

Havia um grande receio de o Varnish não suportar a carga que era entregue pelos servidores de Oracle WebCache.

Fizemos um trabalho de publicar uma máquina de Varnish por vez, medindo sempre a resposta e comparando com os Oracle WebCaches.

Não havia máquina disponível para “subir” ao lado, então a instalação no clicRBS consistiu de retira um servidor de Oracle WebCache, remove tudo, instala e configura o Varnish e sobe novamente o servidor.

Foi catastrófico....para o Oracle WebCache

Estatísticas via APIs Open Source

VARNISHSTAT

Consumo de CPU com Varnish

Somente Oracle WebCache

Aqui, tiramos a máquina para remover o Oracle WebCache e instalar o Varnish. Mantemos o SO.

Somente o Varnish

Lincolm AguiarGrupo RBS

Obrigado!