Título Saas Varnish Autor Gonzalo Pascual Cantero Fecha 24/05 ...

Título Saas Varnish

Autor Gonzalo Pascual Cantero

Fecha 24/05/2016

Director Oriol Mercadé Figueras

Empresa Omitsis Consulting S.L.

Ponente David Carrera Perez

Departamento Arquitectura de Computadores

Titulación Ingeniería Superior en Informática

Centro Facultat d’Informàtica de Barcelona (FIB)

Universidad Universitat Politècnica de Catalunya (UPC) - BarcelonaTech

Índice general

1. Introducción 31.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Motivación personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Organización de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Alcance 72.1. Omitsis Consulting S.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Oportunidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1. Web server caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Paas – Plataforma como servicio, Saas – Servicio como software . . . 82.2.3. Servicio de gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4. Asistencia técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.5. Content Delivery Network . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Estudio previo 113.1. Aspectos tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Web cache / Reverse proxy . . . . . . . . . . . . . . . . . . . . . . . 113.1.2. Content Delivery Network (CDN) . . . . . . . . . . . . . . . . . . . 113.1.3. Bases de datos relacionales . . . . . . . . . . . . . . . . . . . . . . . 123.1.4. NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.5. Colas de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Soluciones existentes y alternativas para Web caching . . . . . . . . . . . . 133.2.1. Varnish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.1.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1.3. Balanceo de carga . . . . . . . . . . . . . . . . . . . . . . . 143.2.1.4. Otras características . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2. Squid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3. Otras alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3. Otras tecnologías a considerar . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1.1. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ÍNDICE GENERAL

3.3.1.2. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1.3. Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.2. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2.1. Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Full-stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Microframework . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2.2. Candidatos . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.3. Librerías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.3.1. Parsers y lexers . . . . . . . . . . . . . . . . . . . . . . . . 19ANTLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20YACC & LEX . . . . . . . . . . . . . . . . . . . . . . . . . . 20Pygments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Pyparsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4. Especificación 234.1. Dominio del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . 234.2.3. Modelado de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.3.1. Ámbito del negocio . . . . . . . . . . . . . . . . . . . . . . 25Contexto de trabajo . . . . . . . . . . . . . . . . . . . . . . . 25Eventos de negocio . . . . . . . . . . . . . . . . . . . . . . . . 25Casos de uso de negocio . . . . . . . . . . . . . . . . . . . . . 28

5. Diseño 435.1. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.1. Modelo conceptual normalizado . . . . . . . . . . . . . . . . . . . . . 455.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1. Asignación de responsabilidades a capas . . . . . . . . . . . . . . . . 465.2.2. Modelo conceptual distribuido por subsistemas . . . . . . . . . . . . 47

5.3. Subsitemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.1. Usuarios y autenticación . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.2. Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.3. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.4. Distribución y estadísticas . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.4.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . 495.3.4.2. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . 50

Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50LogEntryProcessor . . . . . . . . . . . . . . . . . . . . . . . . 55LogFormatter . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59RequestBySitesFormatter . . . . . . . . . . . . . . . . . . . . 60

ÍNDICE GENERAL

RequestManager . . . . . . . . . . . . . . . . . . . . . . . . . 65

6. Implementación 676.1. Varnishlog - Monitorización y recopilación de logs . . . . . . . . . . . . . . . 67

6.1.1. Formato de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.1.1.1. Descripción de la llamada utilizada . . . . . . . . . . . . . 68

6.1.2. Extract Transform and Load ETL . . . . . . . . . . . . . . . . . . . 706.1.2.1. Extracción de datos . . . . . . . . . . . . . . . . . . . . . . 706.1.2.2. Transformación . . . . . . . . . . . . . . . . . . . . . . . . 736.1.2.3. Carga de datos . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.2. Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.2.1. Puntos de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.1.1. POST /data/ . . . . . . . . . . . . . . . . . . . . . . . . . 78Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Parámetros de entrada . . . . . . . . . . . . . . . . . . . . . . 78Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2.1.2. GET /sites/:path-sites/:start/:end . . . . . . . . . . . . . . 79Parámetros de entrada . . . . . . . . . . . . . . . . . . . . . . 80Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3. Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7. Pruebas y análisis del rendimiento 837.1. Entorno de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.1.1. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . 837.2. Descripción detallada de las pruebas . . . . . . . . . . . . . . . . . . . . . . 847.3. Resultados de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.3.1. 5 hilos simultáneos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.3.1.1. Sin cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Resultados por URL . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.1.2. Con Varnish . . . . . . . . . . . . . . . . . . . . . . . . . . 88Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Resultados por URL . . . . . . . . . . . . . . . . . . . . . . . 89

7.3.1.3. Con VSAAS . . . . . . . . . . . . . . . . . . . . . . . . . . 90Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Resultados por URL . . . . . . . . . . . . . . . . . . . . . . . 91Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.3.2. 10 hilos simultáneos . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.3.2.1. Sin cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92



ÍNDICE GENERAL

7.3.2.3. Con VSAAS . . . . . . . . . . . . . . . . . . . . . . . . . . 96Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Resultados por URL . . . . . . . . . . . . . . . . . . . . . . . 97

7.3.3. 100 hilos simultáneos . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.3.3.1. Sin cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98



7.3.3.3. Con VSAAS . . . . . . . . . . . . . . . . . . . . . . . . . . 102Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Resultados por URL . . . . . . . . . . . . . . . . . . . . . . . 103

7.4. Análisis y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.4.1. Comparativa entre entornos . . . . . . . . . . . . . . . . . . . . . . . 103

7.4.1.1. 5 hilos simultáneos . . . . . . . . . . . . . . . . . . . . . . . 1037.4.1.2. 10 hilos simultáneos . . . . . . . . . . . . . . . . . . . . . . 1047.4.1.3. 100 hilos simultáneos . . . . . . . . . . . . . . . . . . . . . 106

7.4.2. Impacto del volumen de peticiones sobre el desempeño . . . . . . . . 1087.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8. Planificación, recursos y costes 1138.1. Condiciones y restricciones en la planificación . . . . . . . . . . . . . . . . . 113

8.1.1. Despliege progresivo del sistema . . . . . . . . . . . . . . . . . . . . 1138.1.2. Priorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138.1.3. Divide y vencerás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138.1.4. Estabilización de contratos . . . . . . . . . . . . . . . . . . . . . . . 1148.1.5. Estandarización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.2. Recursos disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158.2.1. Capital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158.2.2. Mano de obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158.2.3. Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.3.1. Extracción de información . . . . . . . . . . . . . . . . . . . . . . . . 1188.3.2. Altas de usuario y planes de suscripción . . . . . . . . . . . . . . . . 1188.3.3. Consultas estadísticas . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.3.4. Sitios web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.3.5. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.3.6. Módulo de Drupal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.3.7. Historial y recuperación de configuraciones . . . . . . . . . . . . . . 1188.3.8. Gestión de servidores . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.3.9. Pasarela de pago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.4. Desviaciones y problemas acaecidos . . . . . . . . . . . . . . . . . . . . . . . 119

ÍNDICE GENERAL 1

9. Conclusiones 121

Bibliografía 1

2 ÍNDICE GENERAL

Capítulo 1

Introducción

El presente proyecto final de carrera (PFC), Varnish as a Service, ha sido realizado porGonzalo Pascual Cantero, estudiante de Ingeniería Superior en Informática en la Facultadde Informática de Barcelona (UPC). El desarrollo del mismo se emmarca dentro de lamodalidad B, por lo que ha sido realizado en una empresa real, en este caso, OmitsisConsulting S.L. La supervisión la ha efectuado Oriol Mercadé Figueras, cofundador ypropietario de la empresa y también Ingeniero Superior en Informática titulado en elmismo centro en el que yo he estudiado.

1.1. Contexto

La realización de este proyecto surgió de una negociación entre los cofundadores de laempresa y yo. Ya había una relación previa con la empresa: un convenio de colaboración porel ya llevaba casi dos años trabajando como becario, participando en diversos proyectos,incluido un intento fallido de Proyecto Final de Carrera. Dicho proyecto se llevó a cabosatisfactoriamente y resultó funcional y adecuado a las especificaciones del cliente que noscontrató, sin embargo no me resultó satisfactorio el hecho de que el proyecto fuera unacolaboración entre otro estudiante y yo mismo, y que fuera a ser sólo yo el que presentaradicho proyecto como único realizador. Esto más el hecho de que aún estaba cursandoasignaturas resultó en una pobre documentación, a la pérdida del enfoque didáctico y a lapérdida del interés y la perspectiva, por mi parte, cuando ya acabé todas mis asignaturasde segundo ciclo.

Ante este hecho me planteé volver a realizar en un futuro un proyecto siguiendo unaspautas más adecuadas para llegar a ser un PFC con el que yo me sintiera a gusto. Noobstante, antes de hablar con mi empresa, seguí trabajando en otros proyectos sin tenermuy claro qué quería hacer. Empecé a trabajar en un portal de alquiler de embarcaciones,al cual me mantuve vinculado durante diez meses. Dicho proyecto recibió un enfoque destartup y empezó con una base sólida en cuanto a planteamiento, búsqueda de inversoresy asignación de recursos, almenos en apariencia. Lamentablemente, con el tiempo percibíuna falta de liderazgo y de visión en los responsables de dirigir dicho proyecto, yo fui elúnico recurso en el apartado técnico duranto los inicios y no supe ver los problemas en su

3

4 CAPÍTULO 1. INTRODUCCIÓN

momento, no fui capaz de aportar mis ideas y objeciones, por lo que entré en un círculocerrado de desarrollo. Me explicaban qué se debía hacer, programaba el código en base aesas explicaciones, entregaba dichos cambios, se volvía a evaluar cómo funcionaban esasnuevas ideas y al no ver mejorías en el rendimiento de la web, el proceso se repetía abeternum. Hasta tal punto fue así que mi rendimiento fue descendiendo hasta que no pudeaguantar más y solicité un cambio de proyecto a mis jefes.

1.2. Motivación personalSurgió entonces la oportunidad de realizar mi PFC, mantuve algunas charlas con los

gerentes de la empresa y ellos me propusieron un proyecto grande, interesante y de largorecorrido. Tendría la oportunidad de trabajar desde cero, con una visión más clara ya quese trataba de un proyecto interno de la empresa relacionado con el cacheo de contenidoweb. Esto implicaba que yo mismo y el resto de compañeros podíamos ser stakeholders ydefinir el proyecto con mayor seguridad.

Las bases para comenzar a trabajar las tenía de sobra adquiridas después de casidos años de trabajo. Tenía los conocimientos necesarios para poder abordar el proyecto asícomo un grupo de compañeros con mayor experiencia que la mía a los que poder preguntary buscar asesoramiento en aquellos campos en los que mi experiencia no fuera suficiente.

Cuando a comencé a trabajar dentro del convenio de colaboración con empresas, penséque era una buena idea para comenzar a reunir un currículo interesante y para tomarcontacto con el mundo laboral que me pudiera encontrar una vez terminados mis estudios.Por eso comencé a trabajar incluso antes de haber acabado el segundo ciclo del plan deestudios, para entrar con paso firme dentro de una empresa una vez acabados mis estudios.

1.3. Organización de la memoriaLa memoria contendrá nueve capítulos, incluyendo éste primero.

1. Introducción Breve descripción del contexto bajo el cual se ha realizado este proyecto.

2. Alcance Observaciones sobre la repercusión, alcance y objetivos.

3. Estudio previo Análisis y descripción detallada de los aspectos técnicos a tener encuenta.

4. Especificación Desarrollo exhaustivo sobre el dominio del problema y el modelado denegocio.

5. Diseño Recopilación de artefactos pertenecientes a la etapa de diseño del software.

6. Implementación Enumeración y explicación de los aspectos más relevantes durantela creación del software.

7. Pruebas y análisis del rendimiento Descripción, visualización y análisis en pro-fundidad de las pruebas de rendimiento y los resultados obtenidos.

1.3. ORGANIZACIÓN DE LA MEMORIA 5

8. Planificación Detalle de la planificación y observaciones sobre los problemas y des-viaciones acaecidas.

9. Conclusiones Observaciones y evaluación personal sobre el proyecto.

6 CAPÍTULO 1. INTRODUCCIÓN

Capítulo 2

Alcance

2.1. Omitsis Consulting S.L.

Omitsis Consulting S.L. es una empresa dedicada a ofrecer soluciones IT para empresasy clientes de toda índole; está especialmente centrada en el desarrollo web, en entornos e-commerce, en portales i proyectos a medida. Fue fundada por dos jóvenes emprendedores,Oriol Mercadé Figueras y Ferran Martínez Mussons, en el 2008. La empresa tiene unavisión de carácter emprendedor y abierto, con una fuerte voluntad por innovar y asumirretos tecnológicos.

DPese a su corta vida, la organización ha ido creciendo a ritmo constante incorporandopersonal, nuevos proyectos, clientes y colaboradores. Entre sus clientes más habituales po-demos encontrar al Ayuntamiento de Barcelona, la diputación de Barcelona, GrandValirao la edición barcelonesa de TimeOut. Entre sus proyectos más interesantes y conocidosencontramos la web del festival .El Grec", el portal de alquiler de barcos Boatbureau o laaplicación web Nou-u.

2.2. Oportunidad

En los últimos tiempos, la aparición de la nube y la necesidad de escalar el tamaño delas bases de datos y de atender el mayor número de peticiones a nuestros servidores hanhecho proliferar distintas soluciones para tratar de mitigar los problemas de escalabilidadmediante sistemas distribuidos por internet.

Sin embargo, muchas veces el enfoque para solucionar estos problemas pasa por asignarmás recursos sin reparar en si es la mejor alternativa en términos de sostenibilidad tantomedioambiental como económica.

Por suerte, existe una alternativa que basa su éxito en la Ley de Pareto, aplicándolo alas peticiones de objetos que atiende un servidor (como pudiera ser una página web). Eseprincipio se podría expresar como:

El 80% por ciento de las peticiones reclaman sólo el 20% de los objetos que contieneun servidor. El 20% restante de peticiones, solicita el 80% que falta.

7

8 CAPÍTULO 2. ALCANCE

Esa alternativa se llama Web Server Caching y es una variante de un proxy inverso(reverse proxy). La función de dicho proxy es almacenar aquellos objetos requeridos porun cliente en un espacio de memoria o caché cuyo acceso sea más rápido que el coste devolver a generar dicho objeto en el servidor represetado o de origen, de modo que cuandose reclama un objeto, éste sólo se genera en el servidor de origen si no está presente en lacaché del servidor proxy.

2.2.1. Web server caching

El beneficio en el coste computacional que supone no tener que volver a generar unmismo objeto cada vez que se solicita, redunda en que el servidor proxy puede atenderun mayor número de peticiones que el servidor representado. Esa mayor capacidad paraatender peticiones redunda, a su vez, en una mitigación de la necesidad de clonar recursos,ya que clonar al servidor representado es más ineficaz que ponerlo detrás de un proxy. Por lotanto no hace falta tanto dinero en la adquisición de más recursos y el consumo energéticose ve reducido.

2.2.2. Paas – Plataforma como servicio, Saas – Servicio como software

No siempre una empresa o desarrolladora está familiarizada o tiene los recursos sufi-cientes para gestionar por él mismo toda su infraestructura. Además, si le sumamos queesa infraestructura conlleva un software específico para realizar una tarea concreta, esprobable que se quiera externalizar toda esa gestión a una empresa externa.

Contemplando los costes que supondría para una empresa gestionar por ella mismaun entramado de servidores extra, los efectos de las economías de escala, la capacidad decachear no sólo una página web en un sólo proxy, si no varias, y de aglutinar conocimientoy experiencia en un sólo campo, sería interesante comprobar si aquí hay potencial para unnegocio rentable.

Concentrar el tráfico de varias páginas web supone conocer una información valiosísimasobre el tráfico de estás páginas, de tal manera que se le podrían mostrar a los clientesestadísticas tales como el número de visitas, el ancho de banda consumido, sus páginasmás visitadas, el ratio de aciertos en la caché... Estos datos pueden ser muy interesantespor temas de márketing, optimización de costes y rendimiento.

Por ejemplo, una tienda virtual podría saber a través de este servicio cuales son sus pro-ductos más o menos vendidos y definir promociones especiales en base a ese conocimiento.Otro ejemplo sería la información de uso que un administrador de sistemas obtendría yque le podría ser útil para optimizar el funcionamiento de su sitio web.

2.2.3. Servicio de gestión

En ciertos casos, podemos encontrarnos con clientes que ni siquiera tengan interés engestionar por ellos mismos qué páginas quieren cachear y cómo cachearlas.

A estos clientes podría resultarles útil un servicio de gestión y asesoramiento queadministre su cuenta y les aconseje sobre la plataforma. Esto conllevaría formar un grupo

2.3. OBJETIVOS 9

de técnicos encargados de administrar las cuentas de esa cartera de clientes.El trabajo consistiría en establecer qué páginas cachear, hacerse cargo de las inci-

dencias, monitorear el uso de los proxy, preparar y presentar al cliente informes sobre elrendimiento obtenido...

2.2.4. Asistencia técnica

Como todo buen servicio, sería aconsejable definir bien el comportamiento de la em-presa en términos de asistencia técnica. Podría ser interesante fijarse en el conjunto debuenas prácticas definidas por ITIL.

2.2.5. Content Delivery Network

En un futuro, si se decide adquirir una dimensión internacional, podemos ofrecer nues-tra solución como una alternativa más de tipo Content Delivery Network (CDN).

La idea consistiría en tener una red de servidores por zonas o regiones del globo terrá-queo, y dirirgir la resolución de nombres y dominios para que apunten al servidor proxymás cercano a la posición del navegador web cliente.

Lo que se tendría que gestionar de manera adicional serían las configuraciones de losservidores DNS que ofrezcan los distintos proveedores de servicios de internet (ISP), la ne-gociación de sus protocolos de enrutamiento interno (en inglés Interior Gateway Protocol,IGP) o la utilización de cualquier otra técnica de resolución de nombres de host a nivelglobal.

2.3. Objetivos

1. La utilización del sistema debe proporcionar una mejora muy sustancial en la rapideza la hora de servir contenidos por parte de un sitio web. De momento se estableceuna reducción mínima del 90% en el tiempo de respuesta desde que una peticiónllega al sistema y la respuesta es servida, respecto a la ausencia de caché.

2. La configuración de un sitio web a cachear debe ser asistida y sencilla de usar parael usuario. También se deben poder importar configuraciones VCL (Varnish Confi-guration Language) de ser necesario. El sistema debe ser robusto y fiable por lo quedeberá comprovar la validez de las configuraciones introducidas e indicar posibleserrores. Debido a que VCL es un pseudo lenguage bastante sencillo y con pocasdirectrices se podría optar por crear analizadores léxicos y parsers.

3. Los usuarios del servicio deben poder consultar estadísticas sobre el funcionamientode su cuenta y de sus sitios web (tasa de aciertos, ancho de banda consumido yahorrado, URLs más solicitadas, tiempo de espera cuando hay un miss...). Se proponerealizar una agregación de información estadística en un datawarehouse.

10 CAPÍTULO 2. ALCANCE

4. El sistema debe escalar de manera fácil. Por lo que para añadir un servidor Varnisha nuestra granja de servidores sólo deberían ser necesarios unos pocos pasos. Ideal-mente, sólo se requeriría instalar el software necesario en el servidor y proporcionarsu IP y puertos de accesos necesarios al subsistema encargado de la gestión de ser-vidores. También sería deseable que un balanceador de carga se encargue de asignarautomáticamente un servidor Varnish a cada sitio web.

5. Se debe proporcionar una API para que los usuarios puedan incluir en sus proyectosacciones simples sobre la caché, como podrían ser invalidar la caché de una URLconcreta o hacer una precarga en caché (fetching).

6. Como modelo de negocio se puede optar por un sistema de suscripción por el cualse habilita un máximo mensual de ancho de banda consumido, por ejemplo. En esecaso, sobrepasado el límite, se invalidarían las caches del sitio o sitios web asociadosa la cuenta y se ofrecería un plan de suscripción superior.

Capítulo 3

Estudio previo

3.1. Aspectos tecnológicos

En esta sección realizaré un repaso general a los componentes tecnológicos relacionadoscon el proyecto.

3.1.1. Web cache / Reverse proxy

Figura 3.1: Diagrama que ilustra el comportamiento de un servidor proxy

3.1.2. Content Delivery Network (CDN)

Una red de entrega de contenidos es una red superpuesta de computadoras que contie-nen copias de datos, colocados en varios puntos de esa red con el fin de maximizar el anchode banda para el acceso a los datos por parte de los clientes que los quieran consultar. Uncliente accede a una copia de la información cerca de su posición, en contraposición a unared convencional donde todos los clientes acceden al mismo servidor central, mitigando asíel riesgo de colapsarlo.

Los tipos de contenido distribuidos en estas redes incluyen objetos web, objetos pa-ra descargar, aplicaciones, streaming en tiempo real y otros componentes de entrega de

11

12 CAPÍTULO 3. ESTUDIO PREVIO

Figura 3.2: El sistema tradicional de distribución de datos y CDN

Internet (mensajes de resolución de nombres DNS, rutas y consultas de base de datos).

3.1.3. Bases de datos relacionales

Una base de datos relacional, cumple con el modelo relacional de datos, el cual es am-pliamente utilizado para implementar bases de datos ya planificadas. Permiten establecerinterconexiones (relaciones) entre datos que pueden estar guardados en tablas diferentes,y a través de dichas conexiones establecer comprobaciones de integridad, indexacionesadicionales y operaciones conjuntas entre las dos tablas.

El sistema de gestión de bases de datos relacional escogido será MySQL.

3.1.4. NoSQL

En informática, NoSQL (a veces llamado "no sólo SQL") es una amplia clase de sistemasde gestión de bases de datos que difieren del modelo clásico del sistema de gestión de basesde datos relacionales en aspectos importantes, el más destacado es que no usan SQL comoel principal lenguaje de consultas. Los datos almacenados no requieren estructuras fijascomo tablas, normalmente no soportan operaciones JOIN, ni garantizan completamenteACID (atomicidad, coherencia, aislamiento y durabilidad), y habitualmente escalan bienhorizontalmente.

En este proyecto se trabajará en tiempo real con una enorme cantidad de informaciónderivada del uso de servidores proxy tales como las tasas de acierto en caché, las latenciasa la hora de servir datos, los servidores que sirven cada petición, etc. Además esta infor-mación puede generarse de manera estacional, por ejemplo en el caso de que una páginaweb reciba un pico de visitas cada día a las doce de la tarde. Por lo que es muy importantepoder almacenar esa información, al menos temporalmente, de la manera más rápida yescalable posible.

Existe una gran cantidad de sistemas NoSQL diferentes, sin embargo para este pro-yecto creo conveniente utilizar una implementación del tipo clave/valor. Este tipo de basede datos se caracteriza por almacenar la información en columnas y supercolumnas, de

3.2. SOLUCIONES EXISTENTES Y ALTERNATIVAS PARA WEB CACHING 13

manera muy eficiente y permitiendo escalar. Cada entrada consta de una clave indexadaasociada a una entrada, dicha clave puede estar compuesta a su vez de diversos campos,permitiendo así consultar y filtrar las entradas de una manera secuencial conociendo quécampos componen dicha clave y en qué orden la componen.

Por ejemplo, si tenemos una tabla que almacena las peticiones a los servidores proxycuyas claves están compuestas por los campos servidor proxy y Fecha de creación, entoncespodremos consultar las peticiones a un determinado servidor proxy. Pero además, podre-mos consultar las peticiones hechas a un determinado servidor proxy y en un intervalode tiempo concreto, ya que la fecha de creación forma parte de la clave como segundocomponente. Sin embargo, el hecho de que sea el segundo componente de la clave hace queno podamos consultar las peticiones hechas en un intervalo de tiempo sin discriminar porservidor proxy. Ésto nos sirve para remarcar la importancia a la hora de definir las tablasen este tipo de bases de datos.

Por lo tanto, tras una escueta búsqueda debido a las restricciones temporales del pro-yecto, el sistema de gestión de base de datos NoSQL escogido es Apache Cassandra.

3.1.5. Colas de mensajes

Este tipo de software puede ser de gran ayuda para la recopilación de datos estadísticos,ya que permiten desacoplar la recolección de datos de su tratamiento y guardado. Deese modo, podemos tener scripts reducidos que vayan leyendo el output que generan losservidores de caché y vaya enviando dichos datos a una cola, la cual puede ser atendidapor el número necesario de workers (procesos encargados de ir vaciando una cola) querecopilen dicha información, la procesen y la guarden.

El sistema de colas de mensajes que se aplicará será RabbitMQ.

3.2. Soluciones existentes y alternativas para Web caching

Debido a que el eje central del proyecto reside en el almacenamiento de contenidos weben cache, creo conveniente extenderme y documentar la información que he encontradosobre las principales implementaciones de este tipo de servidores proxy.

3.2.1. Varnish

Varnish implementa un servidor proxy que permite - entre muchas otras cosas y si-guiendo unas reglas definidas por el usuario - mantener una cache de recursos accesiblesmediante el protocolo HTTP, balancear su carga de trabajo a otros servidores, gestionarla validez de las copias en caché y, incluso, alterar las cabeceras de los documentos quegestiona.

3.2.1.1. Arquitectura

En cuanto a gestión de memoria y procesos en la máquina, Varnish almacena datos enla memoria y delega la tarea de decidir qué elementos se guardan en memoria y cuales se


paginan en disco al sistema operativo. Con ésto se intenta trabajar de manera coordinadapara que los documentos consultados con mayor frecuencia sean servidos desde memoria,mientras que los menos consultados sean los más propensos a ser paginados en memoriavirtual a disco.

Además, Varnish está muy paralelizado en el sentido de que cada conexión con uncliente es gestionada por un hilo de trabajo distinto workerthread. Cuando se alcanza ellímite configurado de hilos de trabajo activos, las conexiones entrantes entran en una colade espera; únicamente cuando el tamaño de dicha cola llega a su límite configurado, lasconexiones entrantes son rechazadas por el servidor.

El mecanismo principal de configuración se llama Varnish Configuration LanguageV CL, un lenguaje de dominio específico utilizado para alterar el comportamiento delservidor en puntos críticos durante la gestión de cada petición al servidor. La mayor partede las políticas de cacheo para tratar una petición están configuradas mediante VCL,haciendo que Varnish resulte mucho más configurable comparándolo con otras solucionespara acelerar un servidor. Cuando Varnish carga un script VCL, ese script es traducidoa C, es compilado y el objeto resultante es enlazado directamente al Varnish como unalibrería dinàmica. O, al menos, eso pregonan en su web.

Hay una serie de parámetros de ejecución, tales como el mínimo y el máximo númerode hilos de trabajo, plazos de expiración (timeouts), etc. que pueden ser modificados enlos scripts VCL y cargados en el acelerador sin tener que reiniciar el servidor proxy.

Con tal de reducir el número de llamadas de sistema para escribir en directorios o fiche-ros, la información de logs se escriben en memoria compartida, delegando el tratamientode logs a otras aplicaciones que puedan leer esa memoria, pero provocando que todo datoque no se haya leído en tiempo de ejecución se pierda. Ésto a la práctica, resulta menosrimbombante, ya que simplemente se proporciona un ejecutable varnishlog que lo únicoque hace es escribir por pantalla la información de los logs. Otras aplicaciones que quieranleer los logs, simplemente tendrán que leer la salida de ese ejecutable.

3.2.1.2. Rendimiento

Aunque Varnish está diseñado para reducir la latencia a la hora de servir cada peticiónal mínimo posible, sus autores indican que su rendimiento sólo será tan bueno como lo seala implementación de la librería pthreads que tenga instalado els sistema.

Además, argumentant desde su web, que una pobre implementación de la funciónmalloc puede añadir latencia innecesaria y por lo tanto limitar el rendimiento. Por lo quela recomendación general es utilizar Varnish en entornos Linux o UNIX-based.

3.2.1.3. Balanceo de carga

Varnish soporta balanceo de carga, esto quiere decir que un servidor Varnish puederepartir el conjunto de peticiones entrantes entre varios servidores, sean o no servidoresVarnish. Los algoritmo de balanceo soportados son Round Robin y Random director. Acada servidor balanceado se le denomina backend y a cada backend puede se le puede

3.2. SOLUCIONES EXISTENTES Y ALTERNATIVAS PARA WEB CACHING 15

asignar un peso, esto quiere decir que si un balanceador tiene dos backends uno puedeconfigurarse para atender el 60% de las peticiones y el otro el 40%, por poner un ejemplo.

3.2.1.4. Otras características

Soporte para crear y añadir extensiones mediante módulos de Varnish, tambiénllamados VMODs.

Soporte para tratar Edge Side Includes, incluido el encapsulado de varios fragmentosen un sólo elemento de cache.

Compresión y descompresión Gzip

Balanceo de carga mediante DNS, Random, Hashing y IP de cliente.

Tecnología de previsualización para HTTP Streaming Pass & Fetch.

Soporte experimental para hacer persistente los elementos en cache

Modo Saint and Grace.

Ventajas:Independiente de los servidores a los cuales cachea, sólo necesita su IP o dominio, elpuerto y unas reglas de cacheo.

Sólo actúa según el protocolo HTTP y el nivel de red del modelo OSI.

Altamente configurable mediante su lenguaje de configuración VCL

Permite cambiar la configuración en caliente mediante un telnet.

Puede usarse como balanceador de carga para otros proxies.

Muy eficiente en términos de rendimiento

Sabe delegar tareas como la gestión de memoria al SO.

El log que ofrece es muy detallado.Inconvenientes:VCL es un lenguaje sencillo, pero es posible que para definir las reglas de cacheo parauna aplicación haya que trabajar de manera exhaustivas con las cabeceras HTTP delas peticiones.

La gestión de ciertas cosas, como cookies o sesiones, puede requerir modificar laaplicación web a cachear expresamente para facilitar la configuración de Varnish. Eshabitual el uso de plugins para Drupal, por ejemplo.

Aunque ofrece un log, su procesado puede resultar complejo.Para conocer más sobre Varnish se puede acceder a su documentación desde su página

web [16].


3.2.2. Squid

Esta herramienta es muy parecida a Varnish. Se trata también de un servidor proxyque mantiene y gestiona recursos accesibles mediante el protocolo HTTP.

Ventajas:

Ofrece un sistema de autenticación para restringir el acceso a las reglas ACL.

Ofrece un conjunto reducido de directivas basadas en ACLs que simplifican muchola configuración.

Permite cambiar la configuración en caliente mediante línea de comandos.

Al igual que Varnish, sólo necesita la información referente a la IP o dominio, puertoy reglas de

cacheo de los servidores a los cuales cachea. No necesita nada más de ellos.

Muy eficiente en términos de rendimiento.

El log que ofrece es muy detallado.

Inconvenientes:

La configuración mediante ACLs hace que la configuración básica sea sencilla, perocomo método de configuración resulta poco potente para según qué tareas

La gestión de cookies o sesiones puede requerir modificar la aplicación web a cachear

Se trata de una herramienta menos utilizada y, por tanto, de un proyecto no tanactivo como otros y con menos documentación

Para conocer más sobre Squid se puede acceder a su documentación desde su páginaweb [12].

3.2.3. Otras alternativas

O bien por ser productos comerciales o bien porque se traten de proyectos descontinua-dos, menos desarrollados o con menor documentación y comunidad activa, aquí incluyouna lista de otras alternativas que no he tomado en consideración.

LiteSpeed

Lusca

McAfee Web Gateway

Microsoft ISA Server 2006

ThunderCache

3.3. OTRAS TECNOLOGÍAS A CONSIDERAR 17

3.3. Otras tecnologías a considerar

3.3.1. Lenguajes de programación

Siempre que se busca aplicar el concepto de divide y vencerás, el uso de contratoso una descripción fidedigna del estado del sistema, siempre es mejor utilizar lenguajesque soporten la programación orientada a objetos (OOP) y que permitan explotar laspropiedades del polimorfismo y la declaración de interfaces.

Es muy probable que el ciclo de desarrollo del proyecto sea iterativo, y que se denmuchas iteraciones, o que la susceptibilidad a cambios sea alta. En estos casos es interesanteutilizar lenguajes que propaguen los cambios rápidamente a la ejecución. Sin duda loslenguajes más idóneos en estos casos son los interpretados. Pueden haber alternativascomo aquellos que ofrezcan algún mecanismo de compilación en tiempo de ejecución oautomática al guardar cambios (esto último depende mucho de herramientas de terceros).

Debido a que se desarrollará una parte para web, será importante utilizar lenguajesespecíficos para el desarrollo web o que ya sean utilizados satisfactoriamente para esemenester.

No está de más aclarar que podría adoptarse más de un lenguaje. Por ejemplo, podríanimplementarse componentes como un panel de control web con PHP y un servicio deasignación de servidores para páginas web con Java. Pero no debería ser necesario si seencuentra una opción que cumpla con todas las necesidades.

Hay diversos lenguajes interpretados que cumplen con lo que se busca: PHP, Pythono Ruby serían los más extendidos. Todos tienen paradigmas, curvas de aprendizaje yespecificaciones distintas.

Es remarcable que todos estos lenguajes ofrecen la posibilidad de añadir extensionesprogramadas en C. Pero rara vez nos veremos obligados a crear una extensión si no es porproblemas muy graves de rendimiento.

3.3.1.1. PHP

Es un lenguaje con una especificación madura, aunque no sin sus problemas (porejemplo, con los valores devueltos por los comparadores == o === al comparar variablescon valor nulo). Cabe destacar que incorporó una orientación a objetos, al estilo de C++desde su especificación 5.3, ya en la 5.4 se incorporan avances más interesantes comopodrían ser los traits.

Es el lenguaje interpretado con mayor difusión en la web.Tiene una curva de aprendizaje moderada, pero debido a su sintaxis muy cercana a

C/C++ o Java, puede ser adoptado con facilidad por programadores familiarizados conesos lenguajes. Esta similitud tiene sus pros y sus contras, ya que las especificaciones deC++ y PHP difieren y un código adaptado directamente de C puede no comportarse dela manera esperada.


3.3.1.2. Python

La especificación de este lenguaje es también madura y no parece adolecer de ambi-güedades presentes en PHP.

Su difusión no es tan grande, pero hay muchos ejemplos exitosos que hacen uso de él. Dehecho Google ofrecía su Google App Engine a desarrolladores de Python, principalmente.Grandes empresas como Pinterest o Disqus utilizan este lenguaje.

Su curva de aprendizaje se dice que es corta. No obstante, su sintaxis utiliza la inden-tación para delimitar los bloques de ejecución, por lo que hay que tener cuidado con loseditores de código con los que se trabaja y cómo están configurados los saltos de línea ylas tabulaciones de todo aquél que trabaje sobre un mismo código.

También hay que tener claro que Python es un lenguaje cuya legibilidad depende muchode lo pulcro que se es al codificar, siendo de los más legibles si se codifica siguiendo losestándares recomendados en su página web .

3.3.1.3. Ruby

La especificación de Ruby es rica, influenciada por otros lenguajes con un paradigmafuncional como Lisp. Muchos que lo usan dicen que el código en Ruby es muy expresivo yde los más cercanos al lenguaje natural.

Su difusión no es tan grande como la de PHP pero hay muchas empresas conocidasque lo usan. Por ejemplo: Twitter o Groupon.

Su sintaxis es poderosa pero a la vez incrementan su curva de aprendizaje, siendoel más difícil de aprender de los tres citados. Como también sucede con Python, ciertasoperaciones se realizan mejor adoptando una postura funcional, en contraposición a unaimperativa.

3.3.2. Frameworks

El uso de ciertos patrones es fácil y no reviste mayor dificultad que el de utilizarlos demanera sabia. Pero, sobretodo si el patrón es de tipo arquitectónico o estructural, entonceses muy posible que existan frameworks que nos ayuden.

3.3.2.1. Tipos

Cada framework reúne un conjunto de propiedades que los hacen diferentes entre sí:

Full-stack frameworks de gran tamaño que proporcionan un conjunto de librerías ocomponentes que pretenden ofrecer una solución completa para el desarrollo de una páginaweb (autenticación de usuarios, persistencia de datos, generación de plantillas, flujos depeticiones...). Suelen incorporar una serie de patrones de diseño que el desarrollador debeconocer para utilizar dicho framework.


MVC frameworks cuyo patrón de diseño arquitectónico consiste en tres componentesprincipales. Uno es el modelo, encargado de alojar la capa de negocio y que acostumbraa comunicarse con otros servicios o con bases de datos. Otro componente es la vista, elcometido del cual es la presentación de la información y las acciones que el usuario puederealizar. Finalmente tenemos el controlador, el cual es el punto de acceso a las distintasfuncionalidades y se encarga de coordinar a los otros componentes entre sí.

Microframework frameworks que ofrecen un conjunto muy básico de funcionalidades.Suelen permitir que se les añada más componentes. Pero suelen otorgar un mecanismo deenrutamiento de peticiones y poca cosa más.

Y enlazando con los lenguajes propuestos anteriormente y con la necesidad de hacer unpanel de administración vía web, paso a describir brevemente sus principales frameworks,los cuales pueden ser interesantes para dicha tarea:

3.3.2.2. Candidatos

Framework Lenguaje Tipo Otras caracterís-ticas

Zend Framework 2 PHP Full-stack, MVCSymfony 2 PHP Full-stack, MVC Muy configurable y

extendibleCodeigniter PHP Full-stack, MVC Convención por en-

cima de la configu-ración

Phar PHP MicroframeworkSilex PHP MicroframeworkDjango Python Full-stack, MVCPylons Python MicroframeworkRuby on Rails Ruby Full-stack, MVC Convención por en-

cima de la configu-ración

Sinatra Ruby Microframework

3.3.3. Librerías

3.3.3.1. Parsers y lexers

Hay un aspecto del proyecto que podría requerir validar las configuraciones de Var-nish antes de aplicarlas a un servidor. De modo que si existiera cualquier error en dichaconfiguración, se pudiera indicar dónde está ese error y, a poder ser, el porqué se ha dado.

En ese sentido sería útil disponer de un analizador léxico/semántico y otro sintácticoque fueran capaces de reconocer el lenguaje de configuración VCL. Éstos analizadores


se pueden obtener mediante el uso de generadores que reciben una descripción de unagramática como entrada y dan como salida los analizadores de dicha gramática.

Sin hacer pruebas exhaustivas, he podido observar que definir una gramática paraVCL no es tan complejo como definir una gramática de un lenguaje imperativo sencillocomo podría ser C. Y las ventajas de la generación automática de código pueden suponerun gran ahorro de tiempo y esfuerzo respecto a la creación manual de estos analizadoresmanualmente.

ANTLR Es una de la librerías más usadas en este campo y parece ser de las que tieneuna comunidad de usuarios y desarrolladores más activa. También es la que ofrece soportea más lenguajes, pudiendo generar analizadores en PHP, Ruby, JavaScript y Python, peroes en éste último lenguaje donde no se han dado errores durante mis pruebas. Otroslenguajes que no muestran errores son C, C++ y Java.

El algoritmo que implementa para el analizador sintáctico se llama LL(*), el cuales descendiente o top-down. Este algoritmo analiza las sentencias de entradas (en undeterminado lenguaje que se quiera analizar) de izquierda y derecha, y siempre deriva elanálisis por la izquierda.

Este algoritmo restringe el tipo de gramáticas que puede reconocer a aquellas de tipoLL. Y el tipo de análisis top-down es una abstracción mucho más fácil de comprender paraun ser humano.

Hay un gran número de empresas que utilizan esta librería, como Apple o IBM.

YACC & LEX Estas dos herramientas están presentes en entornos UNIX, sin embargosuelen generar analizadores en C y no en otros lenguajes, sin embargo existen implemen-taciones para otros lenguajes.

Otra vez más, Python parece ser el lenguaje que tiene un mejor soporte para estasherramientas, ya que dispone de una implementación propia llamada PLY, un proyectobastante más vivo que los que he encontrado para Ruby o PHP.

El algoritmo para el analizador sintáctico suele ser una de las variantes del LR, el cuales ascendente o bottom-up y es capaz de reconocer gramáticas libres de contexto. Losalgoritmos bottom-up requieren un nivel de abstracción mayor, pero el hecho de poderreconocer gramáticas de contexto libre lo hace muy potente.

El famoso compilador GNU de C utiliza Bison, el cual es una implementación de estaslibrerías.

Pygments Esta librería de Python sirve principalmente para dar un formato (como porejemplo HTML) a un texto que cumpla el léxico de una gramática. Como sólo requierede un analizador léxico, no hace falta implementar ningún análisis sintáctico. Eso sí, paranuestro proyecto haría falta implementar un analizador léxico según las especificacionesde esta librería.

Hay un gran número de páginas web que hacen uso de esta librería, sobretodo reposi-torios de código tales como GitHub o BitBucket.


Pyparsing Otra librería de Python que, como ANTLR, implementa un algoritmo LL.

Capítulo 4

Especificación

4.1. Dominio del problema

4.2. Requisitos

4.2.1. Requisitos funcionales

Ref. RequisitoFREQ001 El cliente debe poder registrarse como usuario de la plataforma y contratar

nuestro planes de serviciosFREQ002 Un usuario debe poder registrar y borrar sus páginas web de la plataformaFREQ003 Un usuario con webs registradas debe poder configurarlas y definir sus

reglas de cacheoFREQ004 Una página web configurada, dentro de un plan vigente, debe ser cacheada

por nuestros servidoresFREQ005 Un usuario debe poder dar de baja sus planes contratados y borrarse de la

plataformaFREQ006 Un usuario debe poder ver informes estadísticos sobre el funcionamiento

de sus páginas web dentro de la plataformaFREQ007 El servicio de cacheo a un usuario con un plan expirado o insuficiente debe

ser denegadoFREQ008 Nuestro personal debe poder añadir o retirar servidores de caché a la pla-

taformaFREQ009 Nuestro personal debe poder ver qué configuración tienen los servidores de

caché y modificarla, guardarla y aplicar los cambiosFREQ010 Nuestro personal debe poder crear y notificar incidencias, tanto a usuarios

como a otro personal

4.2.2. Requisitos no funcionales

23

24 CAPÍTULO 4. ESPECIFICACIÓN

Ref. RequisitoNREQ001 Las páginas web configuradas deben ser cacheadas de manera desasistida

por parte del usuario. Sólo en determinada situaciones se le indicará quecambie sus IP de resolución de nombres mediante DNS.

NREQ002 Las páginas web recién registradas y configuradas deben empezar a sercacheadas en menos de 24 horas.

NREQ003 Las páginas web o servidores de caché cuya configuración haya sido modi-ficada deben ver sus cambios aplicados en unos pocos minutos.

NREQ004 Los informes estadísticos deben ser ofrecidos de manera instantánea y bajodemanda del usuario en cualquier momento.

NREQ005 Nuestras granjas de servidores de cacheo deben tener una alta disponibili-dad y tolerancia a fallos.

NREQ006 Los informes estadísticos deben ser ofrecidos de manera instantánea y bajodemanda del usuario.

4.2. REQUISITOS 25

4.2.3. Modelado de negocio

4.2.3.1. Ámbito del negocio

Figura 4.1: Diagrama de contexto de trabajo (Work Context Diagram)

Contexto de trabajo

Eventos de negocio

Ref. Evento Entrada SalidaBEV001 Contratar plan Información de usuario

y bancaria (si hace fal-ta)

Plan contratado


Ref. Evento Entrada SalidaBEV002 Registrar sitio web Dominio, IP y puerto

del sitio (1 objeto); máslas reglas de cacheo (1objeto)

Registro de asignacióny configuración de ser-vidor de cacheo (2 ob-jetos)

BEV003 Configurar sitio web Reglas de cacheo Registro de reasigna-ción (si se requiere) yreconfiguración de ser-vidor de cacheo (1 o 2objetos)

BEV004 Dar de baja sitio Dominio del sitio Liberación de servidorBEV005 Actualizar registro de

dominioDominio del sitio repre-sentado, IP y puerto delservidor encargado decachearlo (1)

Registro conforme se harealizado la petición decambio de registro deldominio

BEV006 Cargar imagen de servi-dor preconfigurado

Imagen con SO precon-figurada o software ainstalar

Registro conforme se haconfigurado el servidor

BEV007 Asignar sitio web Dominio, IP y puertodel servidor representa-do (1); IP y puerto delservidor que lo repre-senta (2); reglas de ca-cheo (3)

Registro de asignaciónentre servidor represen-tado y proxy

BEV008 Configurar servidor Dominio, IP y puertodel servidor representa-do (1); IP y puerto delservidor que lo repre-senta (2); reglas de ca-cheo (3), urls a invali-dar (4)

Registro de modifica-ción de configuracióndel sitio web cacheado

BEV009 Denegar cacheo de sitioweb

Dominio, IP y puertodel servidor representa-do (1); IP y puerto delservidor que lo repre-senta (2)

Registro conforme se hadenegado el cacheo deun sitio (1); notifica-ción de servicio denega-do (2)

BEV010 Solicitar recurso Establecimiento de co-nexión con el servicioIaaS (1); característicasde los recursos solicita-dos (2)

Registro conforme se hasolicitado un recurso aun proveedor externo

BEV011 Notificar recurso asig-nado

IP y puerto de los recur-sos proporcionados

Registro de nuevos re-cursos disponibles

4.2. REQUISITOS 27

Ref. Evento Entrada SalidaBEV012 Alertar de incidencia Mensaje de error con

código y número de in-cidencia (por ejemplo,dependerá del servicioutilizado)

Notificación de inciden-cia al encargado de sis-temas (por ejemplo)

BEV013 Retirar recurso Establecimiento de co-nexión con el servicioIaaS (1); IP y puertodel recurso a retirar (2)

Registro conforme se haretirado el recurso

BEV014 Enviar estadísticas deuso

Informe de estadísticasde uso

BD con los nuevos da-tos agregados

BEV015 Recargar configuraciónVCL

Configuración VCL delsitio web

Registro de carga deconfiguración VCL


Casos de uso de negocio A continuación se listan los casos de negocio obtenidos

Figura 4.2: Contratar plan

4.2. REQUISITOS 29

Figura 4.3: Registrar sitio web


Figura 4.4: Configurar sitio web

4.2. REQUISITOS 31

Figura 4.5: Dar de baja sitio web

Figura 4.6: Actualizar el registro de dominio


Figura 4.7: Agregar un servidor de cacheo al sistema

4.2. REQUISITOS 33

Figura 4.8: Asignar sitio web


Figura 4.9: Configurar servidores de cacheo asociados a un sitio web

4.2. REQUISITOS 35

Figura 4.10: Denegar el cacheo de un sitio web


Figura 4.11: Solicitar recurso

4.2. REQUISITOS 37

Figura 4.12: Notificar recurso asignado.png


Figura 4.13: Alertar de incidencia

4.2. REQUISITOS 39

Figura 4.14: Retirar recurso


Figura 4.15: Enviar estadísticas de uso

4.2. REQUISITOS 41

Figura 4.16: Recargar configuración VCL en un servidor de cache

Capítulo 5

Diseño

En este capítulo se recopilarán todos los diagramas de secuencia y modelos de datospertenecientes al diseño del proyecto.

43

44 CAPÍTULO 5. DISEÑO

5.1. Modelo conceptual

El modelo conceptual de datos tiene el siguiente aspecto

Figura 5.1: Modelo conceptual

5.1. MODELO CONCEPTUAL 45

5.1.1. Modelo conceptual normalizado

Tras aplicar la normalización previa al modelado de la base de datos, el modelo presentala siguiete apariencia

Figura 5.2: Modelo conceptual normalizado


5.2. ArquitecturaSe espera aplicar una arquitectura orientada a microservicios. Cada uno de esos micro-

servicios será implementado aplicando una arquitectura de 3 capas (presentación, dominioy persistencia).

Los paneles de administración y aplicaciones web usarán el patrón arquitectónico Mo-delo Vista Controlador

5.2.1. Asignación de responsabilidades a capas

En la medida de lo posible, se asignarán responsabilidades a capas de manera racional.

5.2. ARQUITECTURA 47

5.2.2. Modelo conceptual distribuido por subsistemas

En el siguiente diagrama se muestran los elementos del dominio agrupados por subsis-temas.

Figura 5.3: Modelo conceptual dsitribuido por subsitemas


5.3. Subsitemas

5.3.1. Usuarios y autenticación

Este sistema es el más sencillo y simple. Sólo se encargaría de la gestión de la infor-mación del perfil de usuario, de su registro y su baja o borrado.

El motivo de que se haya pensado en dedicarle un subsistema se debe a que de este modose mantiene más reducido y limpio el subsistema de Negocio. Otro motivo sería que muyprobablemente se utilice algún componente o framework específico para su implementación,el cual se comentará en el capítulo siguiente.

5.3.2. Negocio

Este sistema tiene la responsabilidad de gestionar la contratación de planes por partedel usuario y de vigilar éstos que sigan vigentes. También es el punto a través del cual laplataforma se comunica con los clientes para cosas como notificaciones de incidencias ypeticiones de cambios de resolución de nombres.

5.3.3. Configuración

Este sistema se encarga de ofrecer las herramientas necesarias para configurar tantolos servidores de cacheo de la plataforma como los sitios web registrados por los clientes.Básicamente servirá para gestionar las reglas de cacheo de los sitios web, mirar qué servi-dores de cacheo las sirven y en base a esa información generar la configuración de Varnishpara cada uno de los servidores de cacheo.

5.3.4. Distribución y estadísticas

Este sistema se encarga de mantener las granjas de servidores de caches de los quedispone la plataforma así como de la captación de datos estadísticos sobre su uso.

5.3. SUBSITEMAS 49

5.3.4.1. Diagrama de clases

Figura 5.4


5.3.4.2. Diagramas de secuencia

Consumer Esta clase se encarga de procesar los mensajes que se envíen a través delgestor de colas, provenientes de los logs de Varnish.

Figura 5.5: callback

5.3. SUBSITEMAS 51

Figura 5.6: constructora


Figura 5.7: initChannels

5.3. SUBSITEMAS 53

Figura 5.8: load


Figura 5.9: run

5.3. SUBSITEMAS 55

LogEntryProcessor Esta clase va leyendo las entradas de los logs de Varnish y las vaagrupando en un diccionario que representa a una sola petición HTTP.

Figura 5.10


Figura 5.11

5.3. SUBSITEMAS 57

Figura 5.12


LogFormatter Esta clase se encarga de dar un formato común, para el resto de com-ponentes, a la información de las peticiones HTTP procesadas.

Figura 5.13

5.3. SUBSITEMAS 59

Publisher Esta clase publica la información de las peticiones HTTP a través del gestorde colas.

Figura 5.14


RequestBySitesFormatter Cuando se solicita la información para un determinadosite o grupo de sites, esta clase se encarga de presentar dicha información agregada.

Figura 5.15

5.3. SUBSITEMAS 61

Figura 5.16


Figura 5.17

5.3. SUBSITEMAS 63

Figura 5.18


Figura 5.19

5.3. SUBSITEMAS 65

RequestManager Esta clase propociona funciones y métodos para consultar la infor-mación de un site o grupo de sites.

Figura 5.20


Figura 5.21

Capítulo 6

Implementación

6.1. Varnishlog - Monitorización y recopilación de logs

Varnish Cache es capaz generar un log detallando información sobre el tráfico que estáentrando y saliendo a través del servidor proxy, así cómo de las acciones que ha tomadoen cada caso. Por poner un ejemplo, puede mostrar que se recibió una petición entrantey si dicha petición ha hecho hit en la cache; en el caso de de una respuesta HTTP, puedemostrar si proviene de la cache, del servidor suplantado o de otro servidor proxy, esteúltimo caso se daría si el log se genera desde un servidor configurado como balanceador.

Dicho log se obtiene con un comando de consola llamado varnishlog. Si no se ejecutadicho comando el log no se genera; si éste es ejecutado pero su salida no es leída por ningúnotro programa o no es redirigida a algún fichero o dispositivo, la información del log sepierde porqué Varnish Cache no la guarda en ningún medio persistente.

Podría entrar en profundidad sobre cómo utilizar el comando varnishlog, pero sim-plemente comentaré que es una herramienta muy completa y personalizable, que permiteobtener información de prácticamente todo lo que hace el servidor proxy. Tal nivel de per-sonalización se alcanza a costa de añadir muchísimas opciones de configuración. Intentarexplicar todo lo que se puede hacer con esta herramienta creo que es innecesario y melimitaré a detallar el formato de salida del comando y el uso que se le da en este proyectoen concreto.

6.1.1. Formato de salida

Un ejemplo del formato de salida de varnishlog sería:13 TxRequest b GET13 TxURL b /test2.html13 TxProtocol b HTTP/1.113 TxHeader b User-Agent: Wget/1.12 (linux-gnu)13 TxHeader b Accept: */*13 TxHeader b Host: 192.168.1.199:608113 TxHeader b X-Varnish: 171551254

67

68 CAPÍTULO 6. IMPLEMENTACIÓN

13 TxHeader b Accept-Encoding: gzip13 RxProtocol b HTTP/1.113 RxStatus b 20013 RxResponse b OK13 RxHeader b Date: Sat, 28 Jan 2012 05:05:59 GMT13 RxHeader b Server: Apache/2.2.15 (Scientific Linux)13 RxHeader b Last-Modified: Sat, 23 Jul 2011 08:09:05 GMT13 RxHeader b ETag: "5a28-51-4a8b8187f8177"13 RxHeader b Accept-Ranges: bytes13 RxHeader b Content-Length: 8113 RxHeader b Connection: close13 RxHeader b Content-Type: text/html; charset=UTF-813 Fetch_Body b 4(length) cls 0 mklen 113 Length b 8113 BackendClose b default *Close backend here.13 BackendOpen b default 192.168.1.199 36012 192.168.1.199 81 *Open backend

for ESI request here.El primer número identifica la petición (o respuesta) de la cual se informa. Por lo

tanto, un grupo de líneas seguidas con el mismo número, aportan datos sobre una mismapetición. Algunos aspectos a tener en cuenta:

Este identificador no tiene porqué ser único para cada petición que gestione el ser-vidor. Puede darse la situación en que aparezca el mismo número identificando pe-ticiones distintas. No obstante, el comando "varnishlog.asegura que nunca habránentradas de peticiones identificadas con el mismo número apareciendo de maneraentrelazada.

Si no se indica lo contrario con una opción que detallaré más adelante, las líneasque generará el log aparecerán agrupadas en base a ese identificador. Con la opciónque luego comentaré, pueden aparecer entradas de peticiones distintas de maneraentrelazada (pero cumpliendo en todo momento la restricción del primer punto).

El segundo componente de cada línea del log se denomina etiqueta ("tag", en inglés) ysirve para identificar qué ha pasado con esa petición, un hecho concreto. Por ejemplo, hayuna etiqueta que indica que se ha acertado en la caché - se ha producido un "hit , otroque se ha consultado a un servidor suplantado - backend - , otro que indica la cabeceradel protocolo HTTP de la respuesta, etc.

6.1.1.1. Descripción de la llamada utilizada

Con tal de monitorizar y registrar los eventos que genera el servidor proxy utilizo lasiguiente llamada a varnishlog:

varnishlog -x BackendClose,BackendOpen,BackendXID,CLI,Debug,Error,ExpBan,ExpKill,Fetch_Body,Hash,HitPass,HttpGarbage,ObjHeader,ObjProtocol,ObjRequest,ObjResponse,ObjStatus,ObjURL,ReqStart,RxProtocol,RxRequest,RxResponse,SessionClose,SessionOpen,StatSess,TTL,TxProtocol,TxRequest,TxResponse,TxStatus,VCL_acl,VCL_call,VCL_return,VCL_trace,WorkThread-i Hit,Length,RxUrl,TxUrl,ReqEnd,RxHeader,RxStatus,TxHeader -o

6.1. VARNISHLOG - MONITORIZACIÓN Y RECOPILACIÓN DE LOGS 69

La opción -x permite excluir las líneas del log que tengan una etiqueta dentro delconjunto de etiquetas indicado. De ese modo, varnishlog sólo mostrará líneas del log delresto de etiquetas.

La opción -i sirve para indicar qué etiquetas incluir. Si no se indica ni la opción -i nila opción -x, todas las etiquetas serán incluidas.

En la llamada me hubiera bastado con dejar la opción -i, pero por cuestiones de co-modidad hice la separación en la propia llamada. Así podía hacer pruebas con diferentesetiquetas sin tener que ir a buscar el nombre exacto en la documentación oficial de VarnishCache.

Hay ciertas etiquetas que siempre se incluyen, sin importar las opciones -x o -i queindiques. Como pueden ser las etiquetas Hit o BackendReuse.

Por último, la opción -o sirve para indicar a varnishlog que no hace falta que agrupe laslíneas de salida mediante el identificador de petición. De ese modo el rendimiento mejorabastante porqué varnishlog no tiene que esperar a que termine una petición para mostrarla siguiente. Además se evitan problemas con que una petición tarde mucho y ralentice lamonitorización de las demás peticiones.

A continuación detallaré las etiquetas que sí se utilizan (mediante la opción -i):Hit si aparece una línea en el log con esta etiqueta, indica que se devuelve una respuesta

de la caché. Se ha producido un acierto en la caché. De no aparecer esta etiquetaen el historial de una petición, significaría que no se acertó en caché (se produjo un"miss")

Length indica el tamaño de la respuesta, es igual a la cabecera HTTP Content-Length.La utilizo para calcular el ancho de banda consumido o que ha transitado por elservidor proxy

TxUrl indica la URL de la petición. Me permite saber que recurso ha sido pedido

RxUrl indica la URL de donde Varnish ha obtenido la respuesta de la petición. El usoque le doy es el mismo que para la etiqueta anterior, pero ésta última tiene prioridad,ya que la URL puede haber sido reescrita. Esta reescritura o redirección puede habersido hecha a nivel de servidor (forwarding) o a nivel del propio Varnish mediante lacofiguración VCL. De no sobrescribir el valor, un mismo objeto accesible desde doso más URLs distintas, tendría más de una métrica sobre el uso de caché

ReqEnd permite saber cuando acaba una petición, indicando que ya no habrán máslíneas para esa petición en el log. El uso que le doy es poder calcular el tiempo finalque ha tardado en servirse esa petición. También la utilizo para liberar memoria,cosa que detallaré en la próxima sección

RxHeader incluye las cabeceras HTTP de la respuesta a ser enviada. La utilizo paraobtener el hostname de la petición y poder cruzar bien los datos de respuesta pordominio

RxStatus devuelve el estado HTTP de la respuesta. Útil para saber si han habido caídasde servidores


TxHeader exactamente igual que la etiqueta RxHeader, exceptuando que incluye lascabeceras de la petición en vez de las de la respuesta

6.1.2. Extract Transform and Load ETL

Este componente es crucial para ofrecer datos estadísticos a los usuarios de maneraeficiente. Este concepto fue acuñado para referirse al proceso de adquisición de grandesvolúmenes de datos provenientes de diversas fuentes, en formatos heterogéneos, al procesode transformación de toda esa información para acomodarla a unas estructuras de datosque fueran idóneas para el proceso último de carga o exposición, donde el usuario finalpuede ver información ya organizada, filtrada y agregada [8].

En el proyecto, sólo se dispone de un sólo tipo de fuente de datos: el log del propioVarnish. Por lo tanto, este apartado está estrechamente relacionado con la sección anteriorsobre monitorización y recopilación de logs. En cuanto al número de fuentes de información,ahí la cosa cambia y se puede complicar, será igual al número de instancias de servidoresVarnish que tengamos levantados.

Por cuestiones de simplicidad, es más conveniente excluir del proceso de extraccióntodos aquellos servidores Varnish que actúen como balanceadores. En principio, sólo nosinteresa el número de aciertos en caché, el tiempo de proceso total y el ancho de banda;con leerlos de los servidores que actúan exclusivamente como cache debería ser suficiente;es más, de incluir también los logs de los balanceadores, corremos el riesgo de corrom-per los datos. Por ejemplo, se podrían dar logs duplicados, ya que un hit registrado enun balanceador, necesariamente ha debido producirse también en uno de los servidoresbalanceados.

Entonces, retomando el hilo, tenemos una heterogeneidad de datos escasa, ya quetodas las fuentes nos proporcionan información en el mismo formato, pero podemos tenerun número de fuentes variable a lo largo del tiempo.

Otro aspecto a recordar, es que los logs generados en un servidor de Varnish sóloson accesibles mediante el ejecutable varnishlog. Eso último, inevitablemente nos obligaa situar .algo"dentro de cada máquina, que albergue un varnish, que lea la salida de eseprograma y la emita allá dónde queramos para un posterior procesamiento.

6.1.2.1. Extracción de datos

Para extraer los datos de un servidor varnish, me he decantado por crear un pequeñoprograma en Python [11] encargado de leer la salida de varnishlog. Para mantener vivoese proceso, en cada máquina con un servidor Varnish se instalará una herramienta demonitorización y gestión de procesos en ejecución llamado Monit [9]

Este programa realiza hasta cuatro acciones sobre cada línea del historial que varnishlogexpone:

1. Trocea la línea, tomando como delimitador el carácter del tabulador, la "tokeniza",transformando el texto en una lista de valores, donde cada valor corresponde a unaporción de la entrada del historial inicial


2. De entre esa lista de valores, localiza la posición del valor que nos interese procesar enfunción de la etiqueta. El proceso queda la espera de ser guardada en una estructurade datos clave-valor que representa la información completa de una sola peticiónatendida por el servidor.

3. El valor extraído se guarda en la estructura de datos de tipo clave-valor, tomandocomo clave un nombre apropiado.

4. Comprueba si la línea procesada es la última de la petición actual (recordemos laliberación de memoria con la etiqueta ReqEnd"que comentaba anteriormente). Si esel caso, se considera la estructura clave-valor construida hasta el momento para esapetición como completada y se envía a una cola para su posterior gestión

Las claves de las estructuras clave-valor que se obtienen por cada línea del log, varíanen función de la etiqueta, la cual siempre corresponde al segundo elemento de la lista quese obtiene al trocear la línea (el primer paso que se realiza al procesar una línea).

Hay una estructura clave-valor diferente por cada petición que se esté observandosimultáneamente en un momento dado. Se van creando y destruyendo mediante la gestióndel proceso:

Una estructura se crea cuando se detecta una línea con un identificador de peticióndesconocido, es decir, se procesa la primera línea de una petición

Las estructuras se van enviando a la cola y destruyendo cuando se recibe una etiquetaReqEnd"

Las propiedades que conforman el objeto clave-valor final que se envía a la cola y querepresenta a una petición HTTP realizada contra los servidores es el siguiente:

hit su valor es un booleano que expresa si la respuesta se ha obtenido o no de la cache. Seobtiene de las líneas del log de etiqueta igual a "Hit". Para aquellas peticiones queprovoquen un "miss.en la caché, no recibiremos ninguna línea del log con etiquetaigual a "Hit", en ese caso, al enviar los datos, podemos poner un valor "false"

length incluye la propiedad "length"que representa el tamaño del recurso obtenido

host su valor no es más que el nombre del dominio a donde se está enviando la petición.Se obtiene de las líneas del log con etiqueta igual a "TxHeader.o RxHeader", lascuales representan las cabeceras de la petición HTTP o de la respuesta HTTP,respectivamente. Como pueden haber muchas cabeceras distintas, y cada una apareceen el log representada en una línea, se descartan las líneas de los logs con las cabecerasque no nos interese procesar

url su valor contiene parte de la URL de la petición, incluyendo sólo el "path.en adelante.Se obtiene de las etiquetas RxURL.o "TxURL". A simple vista pudiera parecer quecon procesar una de las dos etiquetas puede ser suficiente. Sin embargo, la cabeceraRxURL"puedo no aparecer, y de aparecer, lo hace porqué hay alguna regla de caché


definida que redirige la petición a otro recurso, y, por lo tanto, sobrescribe la URLoriginal que pudiera haberse recibido con la etiqueta "TxURL"

start su valor es la hora en formato UNIX a la que se recibió la petición. Se obtiene delquinto valor de las líneas con etiqueta igual a ReqEnd"

processtime su valor es el tiempo que se ha tardado en servir la petición. Se obtiene dela suma del octavo valor (tiempo desde que se empieza a procesar la petición hastaque se inicia el envío de la respuesta) y el noveno (tiempo desde que comienza elenvío de la respuesta hasta que se entrega completamente) de las líneas con etiquetaigual a ReqEnd"

status el código de estado HTTP que devuelve la respuesta. Se obtiene de las líneas conetiqueta RxStatus"

A continuación detallo un ejemplo de cómo se procesa una línea del historial de Varnish:

1. El proceso lee una línea con este aspecto: "13 RxHeader b Content-Length: 81"

2. La línea se trocea y transforma en una lista de valores: [13, RxHeader", "b", Çontent-Length: 81"]

3. Se detecta, por la etiqueta RxHeader", que se ha recibido una cabecera de la respuestaHTTP. En este caso, Çontent-Length: 81". Cómo las cabeceras HTTP salen en elhistorial compuestas por su nombre + ": - el valor, el proceso extrae el nombre y elvalor.

4. En la estructura clave-valor, se guarda un valor 81 para la clave "length"

5. El proceso da por finalizado el tratamiento de la línea y la desatiende, quedando ala espera de la siguiente

Al ser ReqEnd"la etiqueta más compleja a tratar, muestro un ejemplo de cómo seprocesaría:

1. El proceso lee una línea con este aspecto:"97 ReqEnd b 117511501 1227316210.5343589781227316210.535176039 0.035283089 0.000793934 0.000023127"

2. La línea se trocea y transforma en una lista de valores: [97, ReqEnd", "b", 117511501,1227316210.534358978, 1227316210.535176039, 0.035283089, 0.000793934, 0.000023127]

3. Se detecta por la etiqueta ReqEnd"que ya se ha enviado la respuesta a la petición

4. En la estructura clave-valor, se guarda el segundo valor numérico (1227316210.534358978)con la clave "start ya que ese número representa el momento en que se inicia la pe-tición, en formato timestamp de UNIX incluyendo decimales


5. También se guarda el valor resultante de sumar los dos últimos valores numéricos(0.000793934 y 0.000023127) bajo la clave "processtime". Sus respectivos valoresdenotan el tiempo de proceso de Varnish, aplicación de reglas de caché junto apeticiones a los servidores backend, y la latencia de red respecto al cliente, ambos ensegundos. Por lo tanto, la suma de los dos indica el tiempo total que se ha tardadoen servir la respuesta para la petición en curso

6. La petición ha finalizado, por lo que la estructura clave-valor se encola para suposterior tratamiento estadístico

7. El proceso da por finalizado el tratamiento de la línea y la desatiende, quedando ala espera de la siguiente

El resto de etiquetas requieren un tratamiento más o menos trivial, pero que no entrañauna complejidad tan relevante como para entrar más en detalle.

La cola va recibiendo datos de los historiales de peticiones resultantes del tratamientode varnishlog. Pero, ¿quién se encarga de ir vaciando la cola de mensajes? Pues en estecaso, se trata de un cluster de lo que comúnmente se denominan "workers", que no sonmás que los procesos que se encargan de vaciar y procesar los mensajes que contiene unacola.

Cada uno de estos "workers.agrega todos los mensajes que pueda hasta llenar un bufferinterno. En el momento en que se llena el buffer de mensajes, los envía todos juntosmediante la llamada a una API propia que se encarga de guardar toda esa información enun datawarehouse.

6.1.2.2. Transformación

La API se encarga de recibir los mensajes agrupados provenientes de los "workers 2lesaplica una serie de transformaciones para adaptar la información de tal manera que puedaextraerse información estadística relevante, agrupable y con posibilidades de ser filtrada.

Echemos un vistazo a una de las clases del modelo de datos del capítulo 5...


Figura 6.1: Clase Request del modelo de datos

Esta clase es importante porqué representa exactamente el aspecto del resultado finalque obtendremos con la transformación de los datos de las peticiones. El nombre quizásno sea del todo correcto, más bien indica información sobre un mismo recurso disponiblemediante peticiones HTTP.

A partir de ahora, haré referencia a la información ya transformada con la expre-sión .objetos transformados", o simplemente, objetos. Para los datos sin procesar, usarésimplemente la palabra "petición".

Tendremos una serie de atributos para los objetos tal que:

host El nombre del dominio presente en la URL de la petición

path La ruta de la URL

hits El numero de aciertos en caché para el recurso pedido

length El ancho de banda acumulado de todas las peticiones hacia el recurso

processtime El tiempo acumulado invertido en servir el recurso - desde la recepción dela petición hasta el final de la transmisión de la respuesta final al cliente

requests Número de peticiones totales

start Este campo indicaba, inicialmente, cuándo se originó la petición. Pero en el casode la transformación de datos estadísticos que nos ocupa, nos servirá para delimitartemporalmente la información agregada. De este modo, podremos ofrecer evolutivostemporales y opciones de filtrado por tiempo. Más adelante comentaré en mayorprofundidad la función de este campo

err5xx Número de errores HTTP con código de estado 5XX que se han producido

err4xx Número de errores HTTP con código de estado 4XX que se han producido


proctime_request El tiempo medio en servir el recurso para una petición. Este valor seha materializado, pero se podría obtener de la división entre el valor "processtime 2

requests"

hitrate La tasa de acierto en cache para una petición. Este valor se ha materializado,pero se podría obtener de la división entre el valor "hits 2requests"

Respecto al campo "start", cabe decir que su función principal será la de separar lainformación agregada en la granularidad temporal que se defina como apropiada. De talmanera que tendremos objetos con un campo "startçon un valor que representa un minutoen concreto, y que contendrá información agregada de todas las peticiones hechas paraun sólo recurso que se realizaron entre ese minuto con cero segundos y ese minuto máscincuenta y nueve segundos.

De hecho, no sólo se definirá una sola granularidad temporal, se definirán hasta cuatro:

segundos

minutos

horas

días

¿Qué supone definir múltiples granularidades de tiempo? Pues que se tendrán que crearobjetos cuyos campos "startrepresenten segundos, minutos, horas y días. Los datos de unamisma petición se agregarán en cada uno de estos objetos si el valor de su campo "start"sesolapa.

A modo ilustrativo podemos tener tres objectos con unos valores para el campo "start":

2014-05-22 09:15:00

2014-05-22 09:00:00

2014-05-22 00:00:00

Estos tres valores corresponden a objetos que contienen información agregada para unminuto, una hora y un día concretos, respectivamente.

Supongamos que se desea transformar y agregar los datos de una petición cuya fecha- o momento - de inicio es 2014-05-22 09:15:43. Pues bien, su información se agregará enlos tres objetos anteriores.

Por el contrario, si tenemos los datos de una petición con fecha 2014-05-22 09:12:33.La información de esta petición no se agregará al primer objeto, ya que la petición sucediófuera del minuto que estipula el campo "start"del objeto transformado.

El motivo de materializar distintas granularidades temporales es agilizar las búsquedas,hacerlas más rápidas.

Finalmente, una vez se procesan todas las peticiones y se obtienen todos los objetostransformados, se guardan éstos últimos en una base de datos de tipo NoSQL. En concreto,se insertan en un gestor de base de datos llamado Apache Cassandra.


6.1.2.3. Carga de datos

Apache Cassandra es un tipo de base de datos NoSQL de tipo clave y valor [3]. Alcontrario de otras bases de datos NoSQL, Cassandra no es "schema-free", eso significa quees necesario definir qué estructuras de datos contendrán sus tablas.

El hecho de que estemos ante una base de datos no relacional de tipo clave valor,nos fuerza a encontrar un esquema de tablas que potencien un acceso rápido a los datosmediante los índices de las claves.

Una peculiaridad de Cassandra, es que los datos no se pueden filtrar por ningún valorque no esté definido en una clave primaria. También es de vital importancia el orden en losque se enumeran los campos dentro de la cláusula que define el índice de la clave primaria,ya que, por norma general, no se podrá filtrar por un campo, si no se provee un filtro para,al menos, el primer campo que conforma la definición del índice [10].

Ésto es así, porqué internamente, el gestor de bases de datos utiliza este primer campopara crear una estructura de datos inicial por la cual empezar a filtrar. También utilizaéste primer campo como clave de partición ("partition key") mediante la cual distribuirdatos dentro de un cluster de bases de datos. Al resto de campos que componen la claveprimaria se les denomina çlustering keys".

Estas limitaciones a la hora de filtrar se pueden omitir añadiendo el texto .ALLOWFILTERING.al final de las consultas. Sin embargo, el uso de esta cláusula puede derivaren un rendimiento pésimo de la base de datos al darse el caso de que se filtren por valoresque puedan no estar en el índice.

Otra opción es definir un índice secundario para habilitar maneras de filtrar medianteotros campos no presente en la clave primaria.

A continuación se muestran las consultas de creación de tablas en el lenguaje CQL(Cassandra Query Language) [4]. el cual se asemeja bastante a SQL. Tambíen se incluyenalgunas explicaciones, principalmente sobre la definición de las claves de las tablas.

CREATE TABLE requests_by_second (host varchar,start timestamp,path varchar,hits counter,requests counter,length counter,processtime counter,err5xx counter,err4xx counter,PRIMARY KEY (host, start, path)

);

Esta tabla contendrá la información agregada por cada segundo en el que se hayanregistrado peticiones.


Del mismo modo que en SQL, se define una clave mediante una cláusula "PRIMARYKEY". En este caso, la clave se compone de las propiedades "host", "start 2"path". Elfiltrado, por lo tanto, deberá incluir al menos un filtro para el campo "host".

CREATE TABLE requests_by_minute (host varchar,start timestamp,path varchar,hits counter,requests counter,length counter,processtime counter,err5xx counter,err4xx counter,PRIMARY KEY (host, start, path)

);

Esta tabla contendrá la información agregada por cada minuto del que se tenga registrode peticiones.

La clave primaria es exactamente igual que para la primera tabla.

CREATE TABLE requests_by_hour (host varchar,start timestamp,path varchar,hits counter,requests counter,length counter,processtime counter,err5xx counter,err4xx counter,PRIMARY KEY (host, start, path)

);

Esta tabla contendrá la información agregada por cada hora de la que se tenga registrode peticiones.


CREATE TABLE requests_by_day (host varchar,start timestamp,


path varchar,hits counter,requests counter,length counter,processtime counter,err5xx counter,err4xx counter,PRIMARY KEY (host, start, path)

);

Esta tabla contendrá la información agregada por cada día del que se tenga registrode peticiones.


6.2. Webservices

Se implementó un pequeño servicio web mediante el cual se podían conseguir dosobjetivos básicos:

1. Enviar datos para ser transformados y guardados en las bases de datos durante elproceso ETL descrito en profundidad en este mismo capítulo

2. Proveer de información estadística un pequeño panel de administración mediante elcual ver gráficas sobre el rendimiento del sistema

Este servicio web se implementó usando un microframework para python llamado flask[5] y ofrece un pequeño listado de puntos de acceso que más adelante se describirán.

Al ser un servicio web de ámbito estrictamente privado, pero que a su vez puede sersusceptible de ser usado por plataformas y sistemas diversos, se optó por usar simplementeun mecanismo de Cross Origin Resource Sharing (CORS) [15] en materia de seguridad.

El formato de los mensajes, tanto de entrada como de salidad, del servicio web esJavaScript Object Notation (JSON) [14].

6.2.1. Puntos de acceso

6.2.1.1. POST /data/

Descripción Envía datos sobre las peticiones extraídas durante la lectura de los histo-riales de Varnish Cache para que sean transformados y guardados en base de datos tal ycomo se definió el proceso ETL a aplicar.

Parámetros de entrada En el cuerpo de la petición se pasa un listado JSON cuyoselementos constituyen objetos con las siguientes propiedades:

hit

6.2. WEBSERVICES 79

length

host

url

start

processtime

status

Ejemplo

[{"hit": true,"length": 1234,"host": "foo.bar","url": http://foo.bar/index.html,"start": 1261088887,"processtime": 0.0003221,"status": 200

},...]

Resultado Dependiendo de si ha habido error o no. En caso de éxito devolverá:

{"success": true

}

En caso de error, en cambio, devolverá:

{"success": false,"error": ###ERROR_MSG###

}

6.2.1.2. GET /sites/:path-sites/:start/:end

Obtiene información estadística sobre el acceso a recursos web y el uso de la cache.Permite filtrar por el dominio del sitio web y por rango e fechas.

Los datos se obtienen de la tabla de granularidad que más convenga, en función deltamaño del rango de fechas por el que se filtre. A continuación se muestra la porción decódigo de la función en Python que se encarga de ésto:


def guessProperQuery(self, start, end):diff = dateutil.parser.parse(end) - dateutil.parser.parse(start)if diff.seconds <= 3600: # 1 hour

return cql_request_by_second_select_host_rangeelif diff.days <= 1:

return cql_request_by_minute_select_host_rangeelif diff.days <= 56: # 8 weeks

return cql_request_by_hour_select_host_range

return cql_request_by_day_select_host_range

Básicamente, si la diferencia entre los momentos de inicio y fin es...

menor o igual a una hora Consultar la tabla que agrega datos por cada segundo

menor o igual a un día Consultar la tabla que agrega datos por cada minuto

menor o igual a dos meses, aproximadamente Consultar la tabla que agrega datospor cada hora

en cualquier otro caso Consultar la tabla que agrega datos por día

Parámetros de entrada El propio endpoint permite pasar los parámetros a través dela ruta:

:path-sites Un nombre de dominio o listado de dominios - separado por barras / por losque filtrar. Por ejemplo: foo.bar/lorem.ipsum.com/localhost

:start Momento a partir del cual incluir información a devolver en la llamada, en formatoUNIX timestamp. Por ejemplo: 1261043687

:end Momento a partir del cual dejar de incluir información a devolver en la llamada, enformato UNIX timestamp. Por ejemplo: 1261088887

Ejemplo de ruta hacia el endpoint /sites/omitsis.com/1261043687/1261088887

Resultado Devolverá un objeto con las siguientes propiedades:

timestamps

hits

requests

length

processtime

6.3. DASHBOARD 81

err5xx

err4xx

hitrate

proctime_request

Cada una de estas propiedades será un listado de valores que representarán los datospara un momento dado, ya sea un segundo, un minuto, una hora o un día en concreto

Por ejemplo:

{"timestamps" : [1261043580,...],"hits" : [343,...],"requests" : [457,...],"length" : [5173697,...],"processtime" : [2.5952573,...],"err5xx" : [0,...],"err4xx" : [2,...],"hitrate" : [0.75,...],"proctime_request" : [0.0056789,...]

}

Entonces, para obtener los datos del primer instante, se tendrán que acceder a lasprimeras posiciones de cada uno de los listados de las propiedades.

El formato puede parecer enrevesado, pero se ha hecho así porqué la mayoría de libre-rías que sirven para mostrar gráficos y diagramas de barras, requieren pasar la informaciónpara cada eje o dimensión en un listado separado.

Como observación adicional, algunas de las métricas aportadas se pueden combinarpara producir métricas derivadas. Por ejemplo, la métrica derivada más interesante seobtendría de la división de los valores de la métrica length entre los valores de la métricahitrate, y correspondería al ancho de banda ahorrado a los backends gracias al uso denuestro sistema.

6.3. Dashboard

Aunque la intención era acabar ofreciendo un panel de administración completo dondepoder configurar absolutamente todo, solo se pudo completar unas cuantas vistas dondeobservar la información estadística de la web.

Estas vistas utilizan el servicio web detallado en la sección anterior, están implemen-tadas como una aplicación web mediante el framework de modelo-vista-controlador [2]Symfony [13]

Otras herramientas o librerías de terceros que se usan son:


Flotcharts [6] Una librería para JavaScript que permite dibujar una gran variedad degráficos y diagramas fácilmente

jQuery [7] Una librería para JavaScript que permite manipular el DOM de un documentoHTML y gestionar eventos sin tener que preocuparse de la compatibilidad de cadanavegador

Bootstrap [1] Un framework para dar estilos fácilmente a un sitio web. Aglutina tantoficheros CSS como sus propias librerías para JavaScript

No me extenderé más en la implementación del dashboard porqué el resultado finalquedó a medias y aunque los gráficos de uso de los servidores funcionaban bien y ofrecíaninformación interesante, no dispongo de capturas de pantalla para poder mostrar algúnejemplo de cómo se veía.

Capítulo 7

Pruebas y análisis del rendimiento

Con tal de comprobar el rendimiento obtenido que el sistema implementado, se hanrealizado un conjunto de pruebas bajo distintas condiciones de estrés. Esas condicionesson, básicamente, el número de peticiones concurrentes y la periodicidad en las que serealizan.

7.1. Entorno de pruebas

El entorno de pruebas está formado por un servidor Varnish, un servidor RabbitMQ,un servidor Apache Cassandra y otro con los consumidores o workers que se nutren delgestor de colas.

7.1.1. Herramientas utilizadas

He utilizado un programa llamado Apache JMeter (http://jmeter.apache.org/).Este programa permite configurar y ejecutar peticiones a una o varias direcciones URL.

Al acabar, genera un archivo con los resultados y del cual se pueden generar gráficos ytablas con información estadística.

La configuración de las pruebas permite definir éstos parámetros (entre otros muchos):

1. El número de hilos que realizaran peticiones concurrentemente

2. El Ramp-up period", algo así como periodo de lanzamiento, que expresa cuantotiempo tardará JMeter en crear los hilos concurrentes. Por ejemplo, si tenemos 10hilos y un ramp-up de 20 segundos, entonces se creará un hilo cada 2 segundos

3. El contador de bucle, el cual indica el número de peticiones que lanzará un hilo

4. La duración en segundos de la prueba para cada una de las direcciones URL

83

84 CAPÍTULO 7. PRUEBAS Y ANÁLISIS DEL RENDIMIENTO

7.2. Descripción detallada de las pruebasPara realizar las pruebas, se han lanzado peticiones a la página web de la empresa

donde realicé el proyecto. En concreto, se han accedido a tres de sus contenidos cuyasdirecciones URL son:

1. www.omitsis.com/encolorazulenlasgráficas

2. www.omitsis.com/nuestra-filosofia

encolorrojo

3. www.omitsis.com/servicios_internet

encolorverde

Para cada una de las direcciones se han definido tres pruebas. Todas ellas se hanconfigurado para durar 120 segundos, con un periodo de lanzamiento de 1 segundo y 10peticiones por hilo. Cada una de estas tres pruebas tiene respectivamente 5, 10 y 100 hilosconfigurados.

Las pruebas se han repetido en distintos entornos para observar cómo evoluciona elrendimiento. Los entornos definidos son:

Sin cache Se accede a la web directamente sin que haya ningún servidor de cache activadoni ningún componente del proyecto activado

Con Varnish Se ataca a las distintas páginas web a través de un servidor proxy. No hayningún componente del proyecto monitorizando la actividad

Con VSAAS Se ataca a un servidor de Varnish y se habilitan los componentes del pro-yecto para monitorizar los históricos que se generan

7.3. Resultados de las pruebasA partir de los resultados obtenidos se han generado una serie de gráficas y tablas para

poder comprender y evaluar mejor lo que ha pasado.Todos los gráficos son del mismo tipo: un gráfico de líneas. Cada línea es de un color

y está asociada a una de las tres direcciones URl mencionadas antes. En el eje vertical sesitúa el tiempo de respuesta en milisegundos, en el eje horizontal se muestra una franjatemporal que abarca dos minutos.

La interpretación de ese gráfico muestra entonces el tiempo de respuesta acumulado(eje y) de las peticiones lanzadas en un momento dado (eje x).

También se muestra justo después de cada gráfica, una tabla que muestra algunosdatos agregados. La información estadística contenida en esas tablas muestra:

7.3. RESULTADOS DE LAS PRUEBAS 85

1. el número de peticiones realizadas

2. el número de fallos en servir dichas peticiones

3. el tiempo medio de respuesta por petición

4. el tiempo mínimo en que se ha servido una de las peticiones

5. el tiempo máximo

Esta información se muestra también desglosada por cada una de las direcciones URLincluidas en las pruebas.


7.3.1. 5 hilos simultáneos

7.3.1.1. Sin cache

Figura 7.1: Gráfica con la evolución del tiempo de respuesta


Resumen

#Samples Failures Success Rate Average Time Min Time Max Time215 13 93.95% 4484 ms 35 ms 127909 ms

Resultados por URL

Home#Samples Failures Success Rate Average Time Min Time Max Time

76 13 82.89% 12100 ms 37 ms 127909 msnuestra-filosofía#Samples Failures Success Rate Average Time Min Time Max Time

70 0 100.00% 400 ms 35 ms 4154 msservicios_internet#Samples Failures Success Rate Average Time Min Time Max Time

69 0 100.00% 232 ms 36 ms 2046 ms


7.3.1.2. Con Varnish



Resumen


Resultados por URL




199 0 100.00% 18 ms 1 ms 461 ms


7.3.1.3. Con VSAAS



Resumen


Resultados por URL



3 0 100.00% 17394 ms 16901 ms 17755 ms

Observaciones Los datos arrojados en estas pruebas muestran un comportamientoinusual, ya que sólo se han podido lanzar siete peticiones con unos tiempos de respues-ta particularmente altos y con una gran tasa de fallos. Hasta tal punto fueron mal laspruebas, que no se ejecutó ninguna petición para la tercera URL.

Eso puede ser indicativo de una falla de conectividad en la red, o un problema con elsistema VSAAS que no he podido determinar.

Tampoco pude repetir las pruebas al no tener acceso al entorno de pruebas tras dejarde trabajar en la empresa.



7.3.2.1. Sin cache



Resumen


Resultados por URL




541 0 100.00% 198 ms 35 ms 3451 ms


Resumen


Resultados por URL




1800 0 100.00% 25 ms 1 ms 590 ms


7.3.2.3. Con VSAAS



Resumen


Resultados por URL




1945 0 100.00% 18 ms 1 ms 846 ms



7.3.3.1. Sin cache



Resumen


Resultados por URL




4710 0 100.00% 209 ms 34 ms 4016 ms


Resumen


Resultados por URL




18200 0 100.00% 21 ms 1 ms 1033 ms


7.3.3.3. Con VSAAS


7.4. ANÁLISIS Y CONCLUSIONES 103

Resumen#Samples Failures Success Rate Average Time Min Time Max Time

51098 878 98.28% 153 ms 1 ms 43694 ms

Resultados por URLHome#Samples Failures Success Rate Average Time Min Time Max Time



17019 0 100.00% 18 ms 1 ms 1669 ms

7.4. Análisis y conclusiones

7.4.1. Comparativa entre entornos

En este apartado se mostrarán una serie de tablas cruzadas comparando los diferentesentornos entre sí en igualdad de condiciones, queriendo decir esto que se compararán losentornos dentro de una misma cantidad de hilos.

La tabla mostrará porcentajes comparativos sobre el número de peticiones, de errores,tasa de error y tiempo de servicio de un determinado entorno - situado en las columnas -respecto a los otros entornos - situados en las filas.

7.4.1.1. 5 hilos simultáneos

Antes de ver los datos para las pruebas con esta cantidad de hilos simultáneos, quierorecordar que se dió un comportamiento inusual durante las pruebas en el entorno conVSAAS. Por lo tanto, las conclusiones para este apartado tendrán que ser tomadas concautela.

Sin CachePeticiones Errores % errores ms/req

215 13 6.05% 4484 ms

Con Varnish

Peticiones 602 -64.29% - - -Errores 13 - 0.00% - -% errores 2.16% - - 180.00% -ms/req 541 ms - - - 728.84%

Con VSAAS

Peticiones 7 2971.43% - - -Errores 4 - 225.00% - -% errores 57.14% - - -89.42% -ms/req 32314 ms - - - -86.12%


Con VarnishPeticiones Errores % errores ms/req

602 13 2.16% 541 ms

Sin Cache

Peticiones 215 180.00% - - -Errores 13 - 0.00% - -% errores 6.05% - - -64,29% -ms/req 4484 ms - - - -87.93%

Con VSAAS


Con VSAASPeticiones Errores % errores ms/req

7 4 57.14% 32314 ms

Sin Cache

Peticiones 215 -96.74% - - -Errores 13 - -69.23% - -% errores 6.05% - - 845.05% -ms/req 4484 - - - 620.65%

Con Varnish


Me centraré sólo en comentar las diferencias entre los entornos con Varnish respectoal entorno sin cache.

Con Varnish, se han servido un 180% más de peticiones que sin cache.

Aunque el número de errores es igual en ambos entornos, debido al volumen depeticiones, la tasa de errores es un 80% mayor sin cache respecto a la tasa de errorescon Varnish

El tiempo en el que se sirve una petición sin cache es 6 veces más lento que conVarnish.

Es obvio que únicamente con el uso de Varnish, el rendimiento aumenta considerable-mente, disminuyendo también la tasa de errores.


A partir de esta sección, podemos empezar a comparar el rendimiento de Varnishrespecto al nuestro sistema VSAAS con registro de logs. Obviamente, el rendimiento denuestra herramienta provocará una pérdida de rendimiento, falta observar de cuánto seráesa perdida.



1643 47 2.86% 1529 ms

Con Varnish

Peticiones 5400 -69.57% - - -Errores 90 - -47.78% - -% errores 1.67% - - 71.64% -ms/req 111 ms - - - 1277.48%

Con VSAAS



5400 90 1.67% 111 ms

Sin Cache


Con VSAAS

Peticiones 5840 -7.53% - - -Errores 100 - -10.00% - -% errores 1.71% - - -2.67% -ms/req 150 ms - - - -26.00%


5840 100 1.71% 150 ms

Sin Cache

Peticiones 1643 255.45% - - -Errores 47 - 112.77% - -% errores 2.86% - - -40.14% -ms/req 1529 - - - -90.19%

Con Varnish

Peticiones 5400 8.15% - - -Errores 90 - 11.11% - -% errores 1.67% - - 2.74% -ms/req 111 - - - 35.14%

En cuanto al número de peticiones servidas respecto al entorno sin cache, con Varnishse logra un 229% más de rendimiento y con VSAAS se logra un 255% más derendimiento. VSAAS en esta prueba sirve un 8% más de peticiones que simplementeusando Varnish.

La tasa de errores se ha reducido un 42% usando Varnish y un 40% usando VSAAS.VSAAS ofrece una tasa de errores un 2,7% menor que usando únicamente Varnish.


El tiempo que se tarda en servir una petición es 13 veces más rápido usando Varnishy 9 veces más rápido usando VSAAS. VSAAS tarda un 35% más en servir unapetición que simplemente con el uso de Varnish.

Aunque el número de peticiones y la tasa de errores ofrecen mejores resultados conel uso de VSAAS respecto con el uso de Varnish, no ocurre lo mismo con el tiempo deservicio de una petición. No obstante, los datos obtenidos en este nivel de concurrencia sonpositivos en el sentido que un mismo servidor puede soportar niveles de carga parecidosusando tanto únicamente Varnish como todo el ecosistema VSAAS.

Como observación negativa, recalcar que la lectura de logs tiene un impacto notableen el procesamiento de cada una de las peticiones.



14342 435 3.03% 1756 ms

Con Varnish


Con VSAAS



54600 910 1.67% 101 ms

Sin Cache


Con VSAAS




14342 435 3.03% 1756 ms

Sin Cache

Peticiones 14342 256.28% - - -Errores 435 - 101.84% - -% errores 3.03% - - -43.35% -ms/req 1756 - - - -91,29%

Con Varnish


En cuanto al número de peticiones servidas respecto al entorno sin cache, con Varnishse logra un 281% más de rendimiento y con VSAAS se logra un 256% más de rendi-miento. VSAAS en esta prueba sirve un 6,4% menos de peticiones que simplementeusando Varnish.

La tasa de errores se ha reducido un 45% usando Varnish y un 43% usando VSAAS.VSAAS ofrece una tasa de errores un 3% mayor que usando únicamente Varnish.

El tiempo que se tarda en servir una petición es 16 veces más rápido usando Varnishy 10 veces más rápido usando VSAAS. VSAAS tarda un 51% más en servir unapetición que simplemente con el uso de Varnish.

Dado este nivel de concurrencia, el número de peticiones y la tasa de errores son parejosentre VSAAS y Varnish, siendo favorable por un margen pequeño a éste último. Tambiénse viene a corroborar lo mismo que en las pruebas del apartado anterior, los niveles decarga que soportan los dos entornos son parecidos pero la lectura de logs tiene un impactonotable en el procesamiento de cada una de las peticiones. Es más, ese impacto viene aacentuar la diferencia en los tiempos de servicio entre los dos entornos con caché.

Como nota positiva, el tiempo de servicio con VSAAS se ha mantenido en 150 mspor petición tanto en las pruebas con 10 hilos como con las de 100 hilos. Al menos elrendimiento es constante pese a aumentar el nivel de concurrencia. El incremento en lasdiferencias viene dado por una mejoría notable en el tiempo de servicio cuando se usaúnicamente Varnish.


7.4.2. Impacto del volumen de peticiones sobre el desempeño

Figura 7.10: Peticiones realizadas por hilo y entorno

Figura 7.11: Errores producidos por hilo y entorno


Figura 7.12: Tasa de errores por hilo y entorno

Figura 7.13: Tasa de errores (sólo 10 y 100 hilos)


Figura 7.14: Tiempo de servicio medio por hilo y entorno

Figura 7.15: Tiempo de servicio medio (sólo 10 y 100 hilos)

7.5. CONCLUSIONES 111

Figura 7.16: Peticiones por segundo por hilo y entorno

7.5. ConclusionesEl uso de caché, junto o no al tratamiento de logs de Varnish, supone una mejoría

de rendimiento en todos los aspectos respecto a los entornos en los que no se utilizacaché. El número de peticiones servidas por segundo aumenta en gran medida, las tasasde error se reducen casi a la mitad y los tiempos de servicio de una sola petición se reducendrásticamente.

En cuanto al tratamiento de logs, el overhead añadido tiene poco impacto en las tasas deerror y en el número de peticiones por segundo, pero sí repercute sensiblemente en el tiempode servicio de una sola petición. No obstante, las conclusiones que se extraen no dejan deser muy positivas, ya que los tiempos de servicio no se incrementan en función del númerode peticiones concurrentes, lo cual permite pensar que esa métrica se mantendrá establemientras los servidores no se vean colapsados por el número de peticiones simultáneas.

Capítulo 8

Planificación, recursos y costes

8.1. Condiciones y restricciones en la planificación

8.1.1. Despliege progresivo del sistema

Debido al tamaño de la empresa y a las características del proyecto, es necesario trazarun calendario para ir desplegando funcionalidades de tal manera que se permita iniciar laactividad empresarial y su monetización cuanto antes, pero dando margen suficiente parair desarrollando cada una de las funcionalidades que todavía no estén implementadas. Estotambién ayuda a la corrección y detección de nuevos requerimientos al conseguir que elproducto vaya desplegándose en base a un modelo de integración continua.

8.1.2. Priorización

Para este cometido es necesario priorizar las funcionalidades que se desean servir. Estose suele hacer durante la captación de requerimientos mediante técnicas como cuestiona-rios a algún cliente piloto y reuniones en las que se negocia un kick-off con el personalinvolucrado en el proyecto y el cliente piloto. Estos ejemplos de captación de requerimien-tos tienen lugar antes de empezar a implementar el nuevo sistema. No obstante, duranteel desarrollo del proyecto y una vez finalizado, se necesitará evaluar el rendimiento deaquello que ya esté en funcionamiento, analizando registros del sistema, reuniéndose conel técnico de sistemas y estando al tanto de las incidencias que puedan ocurrir, tales comoparadas del servicio, cortes de conexión, problemas de conectividad, consumo de recursoselevado... También se prevé que hayan reuniones para nuevas captaciones de requerimien-tos pero ya encaradas a plantear evolutivos para el sistema. Si el kick-off se realiza conéxito, en principio no debería haber un replanteamiento o cambio radical del sistema, sino más bien añadidos e inclusiones de nuevas funcionalidades.

8.1.3. Divide y vencerás

Otro aspecto importante es la división del problema o proyecto en partes más pequeñas,que ayudan a reducir su complejidad global a la suma de la complejidad de sus partes, el

113

114 CAPÍTULO 8. PLANIFICACIÓN, RECURSOS Y COSTES

comúnmente conocido "divide y vencerás". El hecho de dividir puede ayudar a vislumbrarcómo y de qué manera estructurar el trabajo durante la posterior implementación. Estadivisión se obtiene durante el proceso de definición del dominio del problema y la fase deespecificación del sistema. Si bien me ha resultado siempre un poco ambiguo situar esteproceso de definición y especificación dentro del proceso de creación de una herramientacompleja - en una empresa pequeña -, sí estoy seguro de que una gran parte del trabajo enlas etapas iniciales se invierte en esos menesteres. Sin embargo, las necesidades comercialesapremian, y muchas veces se da el caso de que se vende un producto antes de que éste sehaya producido, fijando plazos de entrega por el medio y estableciendo ciertas restricciones.Y aquí no queda más remedio que plantear un esquema inicial sencillo, listando las partesprincipales del sistema, y priorizar y analizar primero aquellas partes que formen el núcleodel sistema y, que sin ellas, no se pueda avanzar en otras. Las demás, si no se disponede tiempo ni recursos, no queda más remedio que dejarlas en el planteamiento inicial e irdesarrollándolas más adelante. ¿Ésto que significa? Que seguramente no se puedan definirtodos los casos de uso y otras especificaciones en su totalidad antes de afrontar el kick-offpara iniciar el proyecto.

8.1.4. Estabilización de contratos

Durante la fase de diseño se suelen establecer las directrices generales a la hora deestructurar el código (arquitectura en capas y/o mediante servicios), sin embargo no sólose estructura el código sino que se establece la comunicación entre estos niveles o servicios,ya sean paquetes o librerías. La comunicación entre estos componentes se define mediantelos contratos de sus operaciones.

Un contrato define por cada método de una pieza de código, su nombre, sus parámetros,sus valores devueltos, su visibilidad respecto a otros componentes y la descripción delestado del sistema antes y después de su ejecución.

Para este proyecto sería aconsejable tener muy estables los contratos de aquellos méto-dos que intervengan entre niveles arquitectónicos o servicios del sistema. De esta manera,se pueden programar servicios o niveles con una funcionalidad básica en su interior queluego pueden ser reemplazados por otros con una funcionalidad interna más elaborada sinque el resto del código se vea afectado. Todo ello mejorando criterios no funcionales comola manutención y la ampliación.

Por poner un ejemplo, durante un primer periodo de actividad, la empresa puede quetenga una sola granja de servidores caché, por lo que la asignación de páginas web declientes a uno de nuestros servidores puede ser gestionada mediante una lista hash, unminheap u otra estructura de datos sencilla. No obstante, si el negocio crece, puede sernecesario gestionar más de una granja de servidores alojados en más de un proveedor oincluso, si se desea, replicar la web en diversos países con distintos servidores. Pues bien, siesa gestión básica de servidores se encapsula en un servicio con los contratos bien definidos,luego podrá ser sustituido sin complicación por otro más elaborado sin que eso afecte alresto del sistema.

8.2. RECURSOS DISPONIBLES 115

8.1.5. Estandarización

Si bien la estabilización de contratos es muy deseable en el contexto en el cual semoverá el proyecto, también debe ser posible adaptarse a los cambios que puedan surgirdurante el proceso de desarrollo y el uso que se le da al sistema. Por ese motivo es necesariopoder realizar modificaciones y no cerrarse en banda con unos contratos que no satisfacenlos objetivos del proyecto. Sin embargo, siempre será mejor añadir cambios mediante laadición de funciones o métodos que no por modificación de lo que hay hecho. Si es nece-sario, es mejor crear un método nuevo con su contrato bien definido que modificar unoya constituido y que se está utilizando en otros lugares del código - cuya modificaciónacarreará cambios en otros servicios o capas. Ahora bien, supongamos que igualmente nosvemos obligados a realizar un cambio en los contratos ya hechos, pues será necesario idearun protocolo para propagar dichos cambios al resto del código que puedan verse afecta-dos, ya sea porqué le afecta irremisiblemente o porque les supone un beneficio práctico.También se debe establecer cómo son los pases a producción u otros entornos, teniendoen cuenta los posibles cambios en base de datos, requisitos en hardware o en software deterceros. Al principio la gestión será fácil, por lo que dicho protocolo no estará blindadoa cambios. Pero si el sistema crece, serán necesarios una serie de roles para documentarcambios, aplicarlos al código, realizar los pases a un entorno determinado...

8.2. Recursos disponibles

8.2.1. Capital

La empresa capitaliza el proyecto reservando un porcentaje de los beneficios que vapercibiendo de sus otras actividades empresariales y proyectos. Paralelamente, intenta fijarun cliente piloto que pueda aportar un poco de feedback y más de estabilidad financiera, eneste caso la Diputación de Barcelona y, más concretamente, la ampliación de un contratode mantenimiento de la web del el Festival de Teatre el Grec. Dicho contrato se revisaanualmente, pero debido a la confianza gestada durante los últimos años, siempre se harenovado con Omitsis Consulting S.L.

8.2.2. Mano de obra

El principal activo humano encargado del desarrollo del proyecto soy yo, Gonzalo Pas-cual Cantero, si bien mis acciones, los plazos y la priorización de tareas acaban siendoconsensuadas por mi director del proyecto, Oriol Mercadé Figueras. También se dispo-ne de un técnico encargado de sistemas que despliega e instala todo tipo de servidoresy herramientas necesarias para el proyecto, ya sean bases de datos, gestores de colas,configuraciones de servidores http, etc.

Mi dedicación al proyecto estaría prefijada en media jornada - 4 horas diarias o 20horas semanales - ampliables o reducibles en función de las necesidades de la empresa. Enprincipio trabajo a jornada completa, por lo que deberé compaginar mi actividad junto aotros proyectos dentro de la empresa.


8.2.3. Tiempo

El proyecto sitúa su inicio el 7 de enero de 2013, con la intención de ser desarrolladodurante los siguientes 7 meses hasta mediados de julio de es mismo año. Eso significamedio año de actividad.

8.3. Planificación

Se acordó con el director del proyecto una planificación consistente en estas etapas:

Extracción de información

Altas de usuario y planes de suscripción

Consultas estadísticas

Sitios web

API

Módulo de Drupal

Historial y recuperación de configuraciones

Gestión de servidores

Pasarela de pago

Para ilustrar la duración de cada etapa, se construyó un diagrama de Gantt

8.3. PLANIFICACIÓN 117

Figura 8.1: Diagrama de Gantt ilustrando la planificación del proyecto


8.3.1. Extracción de información

Se implementará todo aquello necesario para recopilar y tratar los logs de Varnish parasu posterior tratamiento estadístico.

8.3.2. Altas de usuario y planes de suscripción

En esta etapa se diseñará e implementará el sistema de registro y autenticación deusuarios; así como un apartado dónde poder mostrar los planes de suscripción disponibles.

Si bien no surgió el tema durante la planificación del proyecto, no hubiera estado demás definir los habituales documentos de "Términos de uso 2"Políticas de privacidad".

Más adelante, se completará este apartado añadiendo las pasarelas de pago.

8.3.3. Consultas estadísticas

Se implementarán pantallas y dashboards mediante los cuales, el usuario podrá ver elrendimiento de sus páginas y aplicaciones web.

8.3.4. Sitios web

Creación de un panel de control mediante el cual el cliente podrá registrar las páginasy aplicaciones web que quiera acelerar. También se podrán configurar las reglas de caché,idealmente mediante un formulario simplificado o mediante un asistente guiado o wizard.

8.3.5. API

Se crearán un conjunto de APIs para facilitar la integración y la gestión automatizadadentro de las páginas y aplicaciones web aceleradas por el sistema. Por ejemplo, se añadirála posibilidad de invalidar las cachés cuando desde un blog se edite un artículo.

8.3.6. Módulo de Drupal

Implementación de un módulo de Drupal que integre las APIs desarrolladas en elfamoso sistema de gestión de contenidos.

8.3.7. Historial y recuperación de configuraciones

Desarrollar un sistema de registro de eventos y recuperación de configuraciones previas.De ese modo, se pretende mejorar la trazabilidad de errore e incidencias, así como favorecerla tolerancia a fallos del sistema.

8.3.8. Gestión de servidores

Automatizar las tareas de mantenimiento de los clouds de serviores Varnish. El objetivoprincipal es la autoescalabilidad de la plataforma.

8.4. DESVIACIONES Y PROBLEMAS ACAECIDOS 119

8.3.9. Pasarela de pago

Añadir pasarelas de pago para monetizar la plataforma.

8.4. Desviaciones y problemas acaecidosLa planificación se vio severamente afectada por el excesivo optimismo en su plantea-

miento y la poca disponibilidad temporal que tuve durante la realización del proyecto.Se realizó una planificación poco realista y naif dada la complejidad y la cantidad de

cosas que se querían llevar a cabo. Lo que en otras empresas requería de un gran volumende recursos económicos, humanos y temporales se pretendía hacer con un becario queademás debía hacerse cargo de otros proyectos durante su jornada laboral. No tiene másexplicación que la que se expone aquí. Ni por parte del estudiante ni de su director en laempresa se supo prever esta situación antes de empezar a trabajar en el proyecto.

Ahora, a posteriori, podría haber adulterado la planificación que en su día se elaboró,pero dejaría de ser un reflejo de la experiencia que supuso realizar el proyecto. Además deque no sería ni ético ni honesto por mi parte.

En resumidas cuentas, de la planificación inicial sólo se pudieron realizar dos puntos.

Extracción de información

Consultas estadísticas

Capítulo 9

Conclusiones

Intentaré ser breve. Pese a la temática tan interesante escogida para este proyectofinal de carrera, su realización no ha sido perfecta en absoluto. La falta de visión durantela planificación por mi parte y la poca orientación por parte de la empresa, llevaron auna consecución parcial del proyecto. Debido a que mi carrera profesional ha seguidoavanzando, he descuidado el proyecto que realicé dentro de la primera empresa en la cualempecé a trabajar. No obstante, parece un desperdicio no conseguir el título cuando sóloqueda presentar este proyecto. Sin duda no acabar la carrera no es algo que me vaya a serpositivo en el futuro, y durante estos años, esa incapacidad mía para acabar mi más elevadaetapa educativa hasta el momento siempre ha sido la espina que más ha atormentado mimente.

Quizás no es el proyecto perfecto, pero sí me ha ayudado a madurar en muchos sentidos.Este proyecto me ha enseñado lo difícil que es sacar adelante y materializar una idea, heaprendido a no conformarme cuando las cosas se hacen mal por norma general y hadesconfiar cuando alguien sostiene que las cosas son fáciles y se pueden hacer de un díapara otro. Pero quizás la lección más importante, la anticipación, la preparación previa yel trabajo constante, así como cualquier virtud en su concepción más aristotélica, se debencultivar cada día sin excepción. Sin duda, durante todas mis etapas laborales en las yacuatro empresas para las que he trabajado, he ido creciendo en esos aspectos.

Otra lección que he aprendido es que para desenvolverse en el mundo laboral, unonecesita experiencia laboral. Por mucho que se prepare uno dentro de la universidad, pormuy duras que sean las asignaturas, por muy apretados que sean los horarios de las clases,todo eso nunca se podrá comparar a los niveles de trabajo y estrés que se dan fuerade la universidad o de cualquier tipo de institución educativa, desde el punto de vista delestudiante. En la vida real hay muchísimos más factores que aumentan si cabe la dificultaden el desempeño correcto de nuestro día a día.

Por poner un ejemplo de lo abrumador del asunto, en el mundo laboral casi todoversa sobre el interés. Da igual si uno es su propio jefe o no, siempre tendrás relacionesde interés con tus clientes, proveedores, compañeros de trabajo, jefes, administracionespúblicas, etcétera, todos intentarán apretarte, seducirte, persuadirte para que les cobresmenos, para que trabajes más horas, para que les dediques más atención. Y todas esas

121

122 CAPÍTULO 9. CONCLUSIONES

relaciones ya no comparten el interés en tu educación, todos comparten el interés enobtener un beneficio, económico en su mayoría. Ésto último es determinante, la correctainstrucción del estudiante es la piedra angular sobre la que se sustenta el negocio quesupone una universidad, cuanto mejor formados salgan sus estudiantes, mejores serán losingresos de una universidad. Al salir de la universidad, uno deja de ser el centro de atencióny pasa a tener que codearse para ser relevante y obtener su espacio.

Retomando las conclusiones sobre el presente proyecto, yo no creo que este proyectosea mi mejor obra, porqué es evidente que hay cosas que se han hecho mal. No obstante,el resultado final, de haberse planificado correctamente, supondría un proyecto más quecorrecto para lo que se espera de un PFC. No es fácil hacer un sistema de recopilacióny tratamiento estadístico de logs de Varnish. El problema fundamental fue que lo que seplanteó hacer era un sistema integral para ofrecer caché web siguiendo la moda de losSoftware As A Service, con todos los componentes imaginables: balanceadores, clouds yclusters auto-escalables, facturación, parsing y compilación de configuraciones, gestores decolas, hasta tres tipos de sistemas de gestión de bases de datos... Se pretendía montarun sistema enorme con la dedicación parcial de una sola persona. En cualquier empresagrande, este proyecto se asignaría a todo un departamento técnico.

Entonces, a modo de conclusión, si tan mal fue, merezco obtener el título? Yo creo quede todo lo que le pasa a uno en la vida, se pueden extraer lecciones valiosas. Y curiosamente,de todo aquello que no va de la manera esperada, ya sea porque es un fracaso estrepitosos oporqué no se logran todos los objetivos marcados, es de donde se aprenden las lecciones másvaliosas. Los seres humanos más memorables siempre han tenido grandes fracasos antesde saborear las mieles de la eternidad. Espero haber extraído las enseñanzas correctas deesta experiencia, con eso ya habré obtenido cosas muy positivas. ¿A qué fracaso me puedoestar enfrentando con este proyecto? ¿No obtener el título? ¿No haber acabado algo queempecé hace casi una década ya? Pues probablemente. Y si al final todo lo malo pasa,tendré que sobreponerme y seguir adelante, puede incluso que eso me lleve a saborear esasmieles de la eternidad.

Bibliografía

[1] Página oficial de bootstrap: http://getbootstrap.com/.

[2] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M.Pattern-Oriented Software Architecture, Volume 1, A System of Patterns. WhileyJohn and Sons, Reading, Massachusetts, 1996.

[3] Página oficial de apache cassandra: http://cassandra.apache.org/.

[4] Documentación oficial para cassandra query language (cql):https://cassandra.apache.org/doc/cql/cql.html.

[5] Página oficial de flask: http://flask.pocoo.org/.

[6] Página oficial de flotcharts: http://www.flotcharts.org/.

[7] Página oficial de jquery: http://jquery.com/.

[8] Kimball, R., Ross, M., Thornthwaite, W., Mundy, J., and Becker, B. TheData Warehouse Lifecycle Toolkit. Whiley John and Sons, Reading, Massachusetts,2008.

[9] Página oficial de monit: https://mmonit.com/monit/.

[10] Post sobre cómo filtrar datos en apache cassandra:http://www.planetcassandra.org/blog/flite-breaking-down-the-cql-where-clause/.

[11] Página oficial de python: https://docs.python.org/.

[12] Documentación oficial para squid cache: http://www.squid-cache.org/doc/.

[13] Sitio oficial de symfony php framework: http://symfony.com/.

[14] T. Bray, E. Rfc 7159: The javascript object notation (json) data interchange format,2014.

[15] van Kesteren, A. Cross-origin resource sharing, 2014.

[16] Documentación oficial para varnish cache: http://book.varnish-software.com/3.0/.

i

Título Saas Varnish Autor Gonzalo Pascual Cantero Fecha 24/05 ...

Documents

Transcript of Título Saas Varnish Autor Gonzalo Pascual Cantero Fecha 24/05 ...