Symfony, cloud computing y web escalables

organizan patrocinan

colaboran

Jornadas Symfony 5 y 6 de julio 2010

Universitat Jaume I, Castellón

http://decharlas.uji.es/symfony

Symfony, cloud computing y web escalablesAsier Marqués, blackslot.com

Jornadas Symfony 5 y 6 de julio 2010Universitat Jaume I, Castellón


http://blackslot.com

Jornadas Symfony http://decharlas.uji.es/symfony

Proveemos y gestionamos

infraestructuras basadas en servidores y

soluciones cloud





soluciones cloud

Desarrollamos aplicaciones web





soluciones cloud

Desarrollamos aplicaciones web

Por supuesto, en Symfony


Agenda

0. Presentación/Spam

1. Arquitectura web: escalabilidad y rendimiento

2. Cloud computing

3. Preguntas


Agenda

0. Presentación


2. Cloud computing

3. Preguntas


Escalabilidad:• Capacidad de crecimiento• Rendimiento• Alta disponibilidad• Gestión simplificada


Escalabilidad:• Capacidad de crecimiento• Rendimiento• Alta disponibilidad• Gestión simplificada


Conceptos


Una aplicación web o infraestructura es escalable cuando es capaz de aumentar la capacidad de dar servicio y funcionalidad, con la menor carga administrativa y de desarrollo posible.

Escalabilidad


Disponemos de buen rendimiento cuando somos capaces de soportar la mayor carga de trabajo posible con los menores recursos de hardware posibles.

Rendimiento


Gozamos de Alta disponibilidad cuando seguimos dando servicio aunque nuestra infraestructura sufra problemas en algunas de sus partes críticas.

Alta disponibilidad


- Implementación nativa de MVC

- Flexible gracias a especialización y configuración

- Arquitectura REST

- Potente framework para automatizar tareas mediante línea de comandos

Symfony


- Desarrollo

- Base de datos

- Caché

- División de nuestra aplicación en capas críticas

- Gestión de la infraestructura

Escalabilidad / puntos críticos


- Desarrollo (pensando en nuestra infraestructura)

- Base de datos

- Caché

- División de nuestra aplicación en capas críticas

- Gestión de la infraestructura

Escalabilidad / puntos críticos


DesarrolloDesarrolla pensando en la infraestructura


Usa la configuraciónPermite que una persona no programador mantenga tu aplicación.

Automatiza el mantenimiento mediante tareas.

Symfony / Desarrollo


ejemplo

SITUACIÓN

1. Son las 4am y nuestro administrador de sistemas necesita añadir un nuevo nodo de memcached al pool

2. Nosotros estamos ([ durmiendo | en Tokio | bien acompañados ]+)


Problema: implementación actual



Ips hardcodeadas en el código



Ips hardcodeadas en el código



Usamos nuestro

propio sistema de

cache


- Las ips de los servidores están hardcodeadas en el código

- Si un administrador añade un nuevo servidor de memcached, debe modificar el código para que nuestra aplicación lo pueda utilizar

- No es fácilmente automatizable



Configuración de caché propia

config / bsCache.yml



Más elegante y mantenible

config / bsCache.yml





Cacheamos el archivo de

configuración

Leemos la configuración

desde cache


- Hemos dejado más accesible la configuración a los sysadmin y otras personas no programadoras que mantengan el pool de memcached

- Estaría bien que se pudiese automatizar el despliegue de nuevos nodos para memcached de forma fácil



Automatizamos el añadir nuevos servers al pool


Automatizamos el añadir nuevos servers al pool

Leemos la configuración y

agregamos un nuevo

servidor en el caso de que

sea necesario


Resultado


Resultado

Con un solo comando la aplicación usará el nuevo nodo del pool de memcached


MySQL


Suele ser la primera necesidad a la hora de escalar y el principal cuello de botella en rendimiento

Opciones habituales:

• Arquitectura Master – Slave• Optimización de consultas , ¿ORM, DQL? y

mysql • Desnormalización y No-SQL• Particiones o estrategias federated• Busquedas: Sphinx

Symfony / MySql


Nodos master: para escribir

Nodos slaves: para leer

Objetivos:

- Replicación y alta disponibilidad.

- Delegamos las consultas read-only en los Slaves, liberando de esa carga a los servidores Master.

MySql / Master - Slave





lecturas y escrituras





LECTURASESCRITURAS



LECTURASESCRITURAS







Extendemos las clases Doctrine_Query y

Doctrine_Record





Si la query es de tipo SELECT la conexión se

hará a un servidor Slave, en caso contrario al

master





Cuando salvemos, la consulta se hará contra el

servidor master


Reducir el número de consultas VS desglosar una consulta compleja en varias sencillas

QueryCache

Sustituir Count(*) por FOUND_ROWS()

Olvidarnos de DQL en consultas complejas

Desnormalizar VS usar NO-SQL: Memcached, Redis, Cassandra..

MySql / Optimizar


MySql / sfPager sin Count



Añadimos

SQL_CAC_FOUND_ROWS

al SELECT



Contamos las tuplas totales

con FOUND_ROWS


Limitaciones de MySql en búsquedas

Bajo rendimiento en tablas con muchas tuplas en las que es necesario buscar en campos de texto muy grandes.

No distingue resultados en base a su relevancia.

A menudo obliga a desnormalizar.

MySql / Búsquedas


Sphinx

- Ranking de resultados por relevancia

- Distribuido

- Muy rápido, tanto indexando como a la hora de devolver los resultados

- Indexación en caliente

MySql / Búsquedas


Sphinx: proceso de búsqueda

MySql / Búsquedas

APLICACIÓN



MySql / Búsquedas

APLICACIÓN



MySql / Búsquedas

APLICACIÓN



MySql / Búsquedas

APLICACIÓN


Cache


ViewCache (Symfony <=1.4)

- Caché a nivel de acción

- Caché a nivel de componente y partial

Doctrine posee caché a nivel de consultas

Opciones:

APC, Xcache, Memcached, SQLite, Disco…

Symfony / Cache


Cache / APC


Cache / APC

Cada servidor web almacena

objetos localmente, inaccesibles

desde el resto de frontales


Pros

- Opcode para php, reduce carga de procesador- Nos permite almacenar información- Caché muy rápida

Contras

- La caché es local- No escala horizontalmente

Cache / APC


apc.shm_size (por defecto 30MB)Tamaño de memoria compartida utilizada para almacenar objetos.

apc.stat (por defecto 1)Si se encuentra activado comprueba por cada ciclo deejecución si el código ha cambiado. Estableciéndolo 0 incrementa el rendimiento siempre que usemos rutas absolutas en los requires/includes.

Cache / APC


Cache / Memcached


Cache / Memcached

Cualquier servidor web puede

gestionar la información de

cache


Cache / Memcached

Cualquier servidor web puede

gestionar la información de

cache

Cada servidor de memcached

es el responsable de una serie

de objetos


Pros• Uno de los sistemas más rápidos• Nos permite distribuir la información• Fácilmente escalable

Contras• Almacenamiento no persistente• No hay replicación• Limitaciones:

• keys <= 255caracteres • valores <= 1MB

Cache / Memcached


Pros• Uno de los sistemas más rápidos• Nos permite distribuir la información• Fácilmente escalable

Contras• Almacenamiento no persistente• No hay replicación*• Limitaciones:

• keys <= 255caracteres • valores <= 1MB

Cache / Memcached


RepCache para MemcachedDota a memcached de replicación

Cache / Memcached


Cache / sfViewCache


Cache / sfViewCache

Cache de acción, incluyendo el layout


Cache / sfViewCache

Cache de acción, sin incluir el layout


Cache / sfViewCache

Cache de partial y componente


- Nos facilita la invalidación de cache- Claves basadas en REST e integradas con el sistema de routing

- Está bien para empezar, pero en proyectos avanzados tendremos que considerar otras opciones:

- Estrategia personalizada de cache a nivel de controlador y modelo- Proxy Caché a nivel de sistema- ESI: Edge Side Includes, integrado en symfony 2

Cache / sfViewCache


- Ideal para cachear estáticos almacenados en otras ubicaciones como s3

- Más óptimo que cualquier caché gestionado en nuestra aplicación, pero menos flexible

- La invalidación y en algunos casos la creación de la cache, debe ser gestionada desde la aplicación web o tareas automatizadas.

- Nos permite el uso de ESI, Edge Side Includes

Cache / proxyCache


Cache / proxyCache


Cache / proxyCache


Cache / proxyCache

Evalúa si tiene cache

de la vista solicitada.


Cache / proxyCacheEn caso de no tener,

solicita la información a los

servidores web y de archivos.


Cache / proxyCacheAlmacena la información

en caché y responde a la

petición.


Cache / proxyCache

La siguiente petición es

servida desde caché


Opciones más usadas:

• Varnish: varnish-cache.org

• Nginx: nginx.org

• Squid: squid-cache.org

Cache / proxyCache


Cache / proxyCache / Varnish



Conexión al servidor web

Cacheamos los estáticos

No cacheamos las

peticiones POST

No cacheamos las

peticiones que incluyan

autenticación http o una

cookie __sesion

Lo demás se cachea



Cuando una url es

gestionada por la cache de

varnish, se llamará a los

métodos hit, miss y fetch



vcl_hit

Configuramos que si la url

contiene la palabra

«PURGAR_CACHE» elimine

la caché.

vcl_miss

Configuramos que si la url

contiene la palabra

«PURGAR_CACHE» y no se

encuentra en caché, nos

avise



vcl_fetch

Miss llama a este método

para que cree la caché.

Ahí le establecemos el

tiempo de vida de la misma


ESI (Edge Side Includes) nos permiten incluir contenidos de una url en nuestras vistas.

Podemos distribuir contenido de nuestro site e incluso tratar cada parte como si se tratase de una aplicación web independiente.

Symfony2 incluirá soporte nativo para ESI.

Cache / proxyCache / ESI


<esi:include src = " /esi/categorias.php" alt = " <?php echo url_for(…) ?>" onerror="continue" />



<esi:include src = " /esi/categorias.php" alt = " <?php echo url_for(…) ?>" onerror="continue" />

Las urls pueden ser relativas o absolutas



Dividir en capas


Arquitecturas más modulares y por lo tanto, más fáciles de escalar horizontalmente.

Separamos los problemas en capas.

Nos permite usar varias tecnologías de forma transparente, la más adecuada para cada caso.

Dividir en capas


- Almacenamiento de archivos y estáticos

- Cache

- Acceso a fuentes de datos

- Mailing

- Procesamiento de media o tareas de cálculo

Dividir en capas


Consejo de Yahoo!: no usar ORMsUna buena estrategia si:

- Usamos diferentes tecnologías de bases de datos según el tipo de información

- Equipos de trabajo concentrados exclusivamente en esa área

- Nuestra tecnología de base de datos no implementa interfaz PDO

Capas / Acceso a base de datos


Gestión IT


Monitorización- Alertas: Nagios- Gráficos: Munin, Ganglia, Cacti

Aprovisionamiento- Buena nomenclatura- Configuraciones bajo control de versiones- Automatización de aprovisionamiento (Virtualización o

instalación por red)

Backup- ¿Has probado a restaurar?- Configuraciones bajo control de versiones

Gestión IT


Agenda

0. Presentación


2. Cloud computing

3. Preguntas


- Tres modelos principales: SAAS, PAAS y IAAS

- Nos despreocupamos de los costes y gestión de la capa de hardware y de red

- El despliegue es inmediato

- Pago por uso

- La escalabilidad horizontal no es un problema

Cloud computing


IAAS

- No hay que aprender nada nuevo en la capa de sistemas.

- Nos permite migrar aplicaciones sin hacer grandes cambios

- Tenemos límites similares o menores a los que tendríamos en una infraestructura física

IAAS vs PAAS

PAAS

- Hay que pensar de forma distinta a como pensaríamos en una infraestructura física.

- Hay que desarrollar siendo conscientes de los requisitos y recursos de dicho entorno

- Suele ser mucho más sencillo para un programador. Abstrae de la complejidad de la capa de sistemas.


IAAS

- Amazon EC2

- Softlayer

- UbiCloud

- Rackspace

- …

IAAS vs PAAS / Proveedores

PAAS

- Microsoft Azure

- Google App Engine

- Amazon S3, SDB

- …


AMAZON EC2, S3, SQS



- Permite desplegar instancias virtuales desde AMIs en minutos

- Permite configurar AMIs y compartirlas con la comunidad

- Distintos tipos de instancias: desde 1.7GB de Ram hasta 64.8GB de Ram

- Pago por tiempo de CPU, transferencia de datos e I/O

- Disponemos de volúmenes EBS, ip fijas, snapshots, balanceo y monitorización (CloudWatch)

Amazon / EC2


- Almacenamiento de objetos clave / valor. Cada archivo es un objeto.

- Para recuperar grandes cantidades de objetos, disponemos de AWS Import/Export

- Se paga por almacenamiento, número de peticiones y transferencia.

- El almacenamiento es flexible e infinito, pero cada objeto tiene un límite de 5GB

- Accesible mediante REST con url basada en subdominios o directorio:http:// [bucket_id] .dominio.com/objetohttp://s3.amazonaws3.com/ [bucket_id] /objeto

Amazon / S3


- Servicio de cola de mensajes

- Ideal para trabajos de alta carga que se puedan hacer de forma asíncrona

- Se paga por transferencia y número de mensajes.

- El almacenamiento es flexible e infinito.

Amazon / SQS


- Conjunto de clases para trabajar con los servicios web de Amazon

- Muy bien documentada y soporta todos los servicios de Amazon

- Es muy sencilla de utilizar

Amazon / Cloudfusion


Amazon / Cloudfusion / S3

Subimos un archivo a S3


Amazon / Cloudfusion / S3

Subimos un archivo a S3 Creamos un bucket

Subimos el archivo al bucket


Amazon / Cloudfusion / EC2


Amazon / Cloudfusion / EC2

Arranco una instancia

virtual en EC2

Le asocio una dirección ip

pública.


Amazon / Cloudfusion

- Usando cloudfusion junto a las herramientas de configuración y tareas de Symfony, automatizamos el crecimiento y gestión de la infraestructura.

- Podemos en todo momento aumentar nuestra capacidad de almacenamiento y proceso, de forma inmediata y flexible


Resumen


- Debemos empezar a pensar en la infraestructura como parte de nuestro proyecto de desarrollo

- Además de por escalar, necesitamos preocuparnos por el rendimiento para reducir nuestros costes

- Hoy en día existen más opciones que Apache + Mysql en entornos Linux

- El cloud computing es una opción asequible para disponer de arquitecturas pensadas para escalar desde el principio.

Resumen


Agenda

0. Presentación


2. Cloud computing

3. Preguntas

GRACIASAsier Marqués [email protected]

Jornadas Symfony 5 y 6 de julio 2010Universitat Jaume I, Castellón


Technology

Symfony, cloud computing y web escalables