Varnish Cache

Varnish Cache Reverse Proxy, además de acelerar una aplicación web, protege efectivamente ante ataques DoS/DDoS al enviar sólo las peticiones que son completas al servidor web. La configuración dependerá del escenario final, sea un solo servidor o arquitecturas basadas en varios servidores. En caso de disponer de un solo servidor e IP podemos configurar el servidor web (Apache) en la IP local y el puerto 80, por ejemplo 127.0.0.1:80. Por otro lado, configuramos Varnish en la IP pública y el puerto 80.

Ejemplo real

El siguiente gráfico muestra un ejemplo real de como Varnish actúa en el caso de un ataque DoS. Con 550 peticiones al segundo, el servidor tenia una carga no superior a 0.5 y el ataque no afecto al funcionamiento de la web basada en el gestor de contenidos eZ Publish.

Análisis

Para analizar fácilmente la velocidad de carga de nuestro sitio disponemos básicamente de dos extensiones para Firefox/Firebug:

1. Yslow, creada por Yahoo!
2. Pagespeed, creada por Google

Estos complementos analizan múltiples factores y nos dan sugerencias para optimizar la página analizada. Las dos extensiones son muy parecidas tanto en las pruebas que ejecutan y las sugerencias que indican, pero en Yslow destaca la integración de Smush.it™, un optimizador de imágenes. En cambio en Pagespeed, es muy destacable la opción de disponer, en caso de sugerencia, de las alternativas minified u optimizadas de las css y los js, como también analizar e indicar los selectores css poco eficientes.

Optimización

Dependiendo de cada servidor y aplicaciones instaladas tendremos que optimizar diferentes factores, pero a modo de ejemplo, en el servidor de este blog era necesario optimizar los Cache-Control Header y la compresión gzip. Tras buscar en Google y leer varios post realice los siguientes pasos para optimizar el servidor:

1. Compresión gzip con mod_deflate

Primero hay que activar mod_deflate desde la linea de comando

a2enmod deflate

Luego editar el archivo deflate.conf que se encuentra en /etc/apache2/mods-available/deflate.conf

        AddOutputFilterByType DEFLATE text/plain
        AddOutputFilterByType DEFLATE text/html
        AddOutputFilterByType DEFLATE text/xml
        AddOutputFilterByType DEFLATE text/css
        AddOutputFilterByType DEFLATE text/javascript
        AddOutputFilterByType DEFLATE image/svg+xml
        AddOutputFilterByType DEFLATE image/x-icon
        AddOutputFilterByType DEFLATE application/xml
        AddOutputFilterByType DEFLATE application/xhtml+xml
        AddOutputFilterByType DEFLATE application/rss+xml
        AddOutputFilterByType DEFLATE application/javascript
        AddOutputFilterByType DEFLATE application/x-javascript
 
        AddOutputFilterByType DEFLATE application/x-httpd-php
        AddOutputFilterByType DEFLATE application/x-httpd-fastphp
        AddOutputFilterByType DEFLATE application/x-httpd-eruby
 
        DeflateCompressionLevel 9
 
# Netscape 4.X tiene ciertas limitaciones
        BrowserMatch ^Mozilla/4 gzip-only-text/html
 
# Netscape 4.06-4.08 tiene limitaciones
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
 
# MSIE enmascarado como Netscape
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 
# Las siguientes lineas sirven para probar que la configuración funciona, en producción hay que comentarlas
 DeflateFilterNote Input instream
 DeflateFilterNote Output outstream
 DeflateFilterNote Ratio ratio
 LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
 CustomLog /var/log/apache2/deflate_log deflate

2. Expires headers mediante mod_expires

Primero activamos el modulo

a2enmod expires

Luego editamos o creamos el archivo expires.conf en el directorio /etc/apache2/mods-available/expires.conf

#        ExpiresDefault "access plus 2 months"
 
        ExpiresByType image/x-icon "access plus 1 month"
        ExpiresByType image/png "access plus 1 month"
        ExpiresByType image/jpg "access plus 1 month"
        ExpiresByType image/gif "access plus 1 month"
        ExpiresByType image/jpeg "access plus 1 month"
        ExpiresByType application/pdf "access plus 1 month"
        ExpiresByType audio/x-wav "access plus 1 month"
        ExpiresByType audio/mpeg "access plus 1 month"
        ExpiresByType video/mpeg "access plus 1 month"
        ExpiresByType video/mp4 "access plus 1 month"
        ExpiresByType video/quicktime "access plus 1 month"
        ExpiresByType video/x-ms-wmv "access plus 1 month"
        ExpiresByType application/x-shockwave-flash "access 1 month"
 
        ExpiresByType text/css "access plus 1 hour"
        ExpiresByType text/javascript "access plus 1 hour"

3. Desactivar ETags

Añadir las siguientes lienas al archivo /etc/apache2/apache2.conf

Header unset ETag
FileETag None

4. Reiniciar Apache para activar los cambios

/etc/init.d/apache2 restart

Ya solo queda volver a comprobar la página con las extensiones de Firebug y comparar los resultados.

Enlaces de interes

• Recomendaciones sobre rendimiento web de Google
• Recomendaciones de Yahoo!
• Tutorial sobre Apache2, mod_deflate, mod_expires y ETag
• Tutorial sobre ETag (Esta web tiene otros posts relacionados con optimización de Apache)

Historia

Varnish fue creado por el periódico noruego Verdens Gang (VG). El diseño y desarrollo inicial fue realizado por el consultor danés Poul-Henning Kamp y actualmente, el desarrollo, está gestionado por la consultora noruega Linpro.

Varnish tiene licencia de código abierto (en concreto licencia FreeBSD), pero existe soporte comercial por parte de Linpro y otros.

Arquitectura

Quizás lo más destacable de Varnish es que desde el principio se diseño y programó teniendo en cuenta los sistemas operativos modernos, resumiendo, es un programa moderno.

Varnish almacena los datos en la memoria virtual y deja la tarea de decidir lo que se almacena en la memoria y lo que se guarda en el disco al sistema operativo. Esto ayuda a evitar la situación en la que el sistema operativo comienza a copiar datos al disco cuando la aplicación esta haciendo lo mismo.

Una característica significativa de Varnish es que cada conexión cliente se asigna a un subproceso  independiente. Cuando se alcanza el límite configurado en el número de subprocesos activos, las conexiones entrantes se colocan en cola y sólo cuando esta cola alcanza su límite configurado será rechazado las conexiones entrantes.

Con el fin de reducir el número de llamadas al sistema a un mínimo, los datos de registro o logs se almacenan en la memoria compartida, y la tarea de escribir los registros en el disco se delega a una aplicación separada.

Características

Podemos destacar las siguientes características de Varnish:

• Diseño moderno
• VCL, es un lenguaje de configuración que permite una gran flexibilidad y adaptación. Incluso es posible añadir código C con lo que es posible expandir Varnish sin modificar el código fuente.
• Load balancing
• Soporte parcial de ESI
• Web GUI (Beta), muy útil en caso de configuraciones en cluster
• Posibilidad de cambiar configuraciones sobre la marcha
• Reescritura y redireccionamiento de url (no es necesario un programa externo)
• Consulta de estadísticas y logs en tiempo real

Rendimiento

Como ya he comentado anteriormente, el rendimiento de Varnish y otros reverse proxies (como por ejemplo Squid) depende de múltiples factores y la configuración que se utilice, por lo que siempre es recomendable analizar cada situación y decidirse por una aplicación u otra. Por ejemplo en este post podemos ver una comparación entre Squid y Varnish.

Ejemplos reales

Estas son algunas webs de alto tráfico  que utilizan Varnish

• vg.no
• mashable.com
• wikia.com
• creativecommons.org
• wordpress.com

Por último, en uno de mis proyectos, el cliente quería separar completamente de Internet el acceso a su gestor de contenidos, pero mantener una web actualizada al segundo y con posibilidades de disponer de servidores distribuidos en Europa y América. Con estos requisitos, implementamos Varnish en los servidores públicos del cliente cacheando el servidor de contenido que se encontraba en la red privada del cliente. Gracias a esta arquitectura, los visitantes de la web solo acceden al servidor de Varnish, con lo que no tienen acceso a otros servicios como por ejemplo php, mysql o ssh. A su vez, el usuario final visualiza las páginas en menor tiempo al cargarlas desde Varnish.