Varnish cache

249 visualizações

Publicada em

Como usamos o Varnish no clicRBS

Publicada em: Internet
  • Seja o primeiro a comentar

Varnish cache

  1. 1. Varnish Cache Implementação no clicRBS
  2. 2. Agenda  O projeto Varnish Cache  A implementação no clicRBS  Configuração  Alta disponibilidade e performance  Monitoramento  Logs  Extensões via VMODs
  3. 3. O Projeto Varnish Cache
  4. 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. 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. 6. Implementação no clicRBS
  7. 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. 8. Requisitos do Varnish no clicRBS Vinas
  9. 9. Persistência de sessão
  10. 10. HTTPS O VARNISH NÃO SUPORTA SSL
  11. 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. 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. 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. 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. 15. Configuração
  16. 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. 17. Configuração - VCL
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. Alta disponibilidade
  31. 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. 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. 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. 34. Saint-mode sub vcl_fetch { (...) //Saint Mode for 10 seconds if (beresp.status >= 500) { set beresp.saintmode = 10s; return(restart); } return(deliver); }
  35. 35. Monitoramento
  36. 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. 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. 38. Extensões do Varnish
  39. 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. 40. Performance
  41. 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. 42. Estatísticas via APIs Open Source
  43. 43. VARNISHSTAT
  44. 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. 45. Lincolm Aguiar Grupo RBS Obrigado!

×