O documento discute a implementação do Varnish Cache no clicRBS para substituir o Oracle WebCache como servidor de cache HTTP, abordando a configuração, alta disponibilidade, monitoramento e desempenho do Varnish.

1. Varnish Cache
Implementação no clicRBS

2. Agenda
 O projeto Varnish Cache
 A implementação no clicRBS
 Configuração
 Alta disponibilidade e performance
 Monitoramento
 Logs
 Extensões via VMODs

3. O Projeto Varnish Cache

4. 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)

5. 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.

6. Implementação no clicRBS

7. 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.

8. Requisitos do Varnish no clicRBS
Vinas

9. Persistência de sessão

10. HTTPS
O VARNISH NÃO
SUPORTA SSL

11. Invalidações de conteúdo
 O Varnish suporta dois tipos de invalidação:
 Por parão de URL
 Por URL completa
Invalidar o quê?

12. 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?

13. 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!

14. 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.

15. Configuração

16. 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

17. Configuração - VCL

18. 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!).

19. 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.

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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.

30. Alta disponibilidade

31. 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.

32. 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;
}

33. 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; }
}

34. Saint-mode
sub vcl_fetch {
(...)
//Saint Mode for 10 seconds
if (beresp.status >= 500) {
set beresp.saintmode = 10s;
return(restart);
}
return(deliver);
}

35. Monitoramento

36. 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.

37. 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

38. Extensões do Varnish

39. 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.

40. Performance

41. 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

42. Estatísticas via APIs Open Source

43. VARNISHSTAT

44. 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

45. Lincolm Aguiar
Grupo RBS
Obrigado!