Webprendedor 2009 Escalabilidad

Desafíos para escalar aplicaciones WebEmilio DavisGerente de Tecnologí[email protected]/emiliodavis

1. Definiciones

2. El desafío de escalar

3. Elegir los componentes de las capas de la aplicación.

4. Ciclo crecimiento-tunning-crecimiento

Temario

1. Definiciones


3. Elegir los componentes de las capas de la aplicación


Temario

Pasado cierto número de usuarios la rentabilidad de cada uno debe ser

positiva.

Bligoo: Ancho de banda consumido v/s Carga

Se puede escalar de dos formas, vertical y horizontalmente.

Escalamiento Vertical: Agregar más “poder” a cada nodo.

ProsTrivial de implementar y administrarCasi todo el software escala bien verticalmenteEj. Más RAM → Más procesos Apache/Java

Contras

Costo de hardware exponencialmente alto.

Escalamiento Horizontal: Agregar más nodos.

ProsCosto de hardware lineal.

Contra

Más complejo de implementar. Más complejo de administrar.No todo el software está preparado.

Usualmente se mezclan los dos modelos, se escala verticalmente mientras los costos no se

disparan y horizontalmente después.

El “cuando” se mueve rápidamente. (Ley de Moore)

1. Definiciones




Temario

Crecer verticalmente es trivial (o razonablemente fácil).

El real desafío es crecer horizontalmente manteniendo controlado el costo de desarrollo y

operación.

Es difícil y no hay recetas infalibles, pero nuestra experiencia en Bligoo nos dice que necesitamos al

menos:

Calidad del equipo

Para que una aplicación no sólo crezca, sino que escale, es necesario un equipo excepcional.

Conocimento

Teórico: el equipo debe manejar algoritmos y estructuras de datos complejas

Práctico: el equipo debe sentirse cómodo con cada componente tecnológico de la aplicación.

Calidad de los procesosNo es posible generar una aplicación escalable si

hay emergencias todos los domingos.

Ciclos de desarrollo claros y no muy largos, empoderamiento del equipo, etc.

Manejo de versiones del código (svn, cvs, git...).

Control de historias de usuarios, bugs, casos de uso (jira, mantis, bugzilla, etc).

Pruebas unitarias y de integración.

Calidad del software

Todas las líneas de código deben ser “aceptables” y unas pocas geniales.

Arquitectura simple y probada

O suficientemente simple para que la entienda todo el equipo (desarrollo y operación)

Este NO es el espacio para probar lo último que leíste en <inserte blog cool> (DB sharding, motor

experimental de mysql, pre-alpha de cache distribuido de moda, etc).

Framework y lenguaje de desarrollo con énfasis en rendimiento

Muchos frameworks permiten prototipado rápido pero no ofrecen performance razonable.

Verificar si hay casos de éxito en producción antes de elegirlo.

Apertura de mente

Pese a lo dicho antes, soluciones poco ortodoxas pueden ser justo lo que necesitabas. (NoSQL por

ejemplo)

1. Definiciones




Temario

Contenido estático (web server)

Hay muchas soluciones opensource y de código privativo que resuelven bien este problema.

apache, lighttpd, nginx, iis, etc

Lógica de la aplicación

Decidir el lenguage de programación basado en la experiencia del equipo mientras ofrezca

capacidades documentadas de escalabilidad y disponibilidad de IDEs razonables.

Elegir el framework de desarrollo basado en las capacidades documentadas de escalabilidad

horizontal.

Capa de lógica (cont.)

Por la naturaleza stateless de las aplicaciones web, usualmente la capa de lógica escala

trivialmente, un request puede ser respondido por cualquier nodo de la capa lógica.

Usar “caches” siempre que se pueda. (jboss-cache, memcached, etc), ojo con los caches

replicados versus los distribuidos.

Capa de persistencia

En las aplicaciones Web la capa de persistencia (usualmente base de datos) es la que presenta las

mayores complejidades al escalar.

En Bligoo usamos y recomendamos Mysql.

Escalabilidad en Mysql

Existen dos modelos de crecimiento horizontal en Mysql

Mysql cluster y Mysql Replication

Mysql Cluster

Promete alta disponibilidad y buen performance pero es muy complejo de implementar y

administrar.

Mysql Replication

Mysql Replication

Usa uno o dos nodos “maestros” en los que se puede escribir y leer, y N esclavos donde se puede leer.

Permite HA y respaldos “en vivo” o “atrasados”, incluso distanciados geográficamente.

Trivial de implementar y razonablemente sencillo de administrar.

Mysql Replication

Los esclavos funcionan serialmente, por lo que pueden atrasarse. Si pierden la conexión con el maestro pueden atrasarse sin saberlo.

Mysql cluster + replication

Siempre aparecerán problemas de performance. La gracia está en darse cuenta a tiempo.

1. Definiciones




Temario

Detectar (o predecir) rápidamente el problema

Usar software de monitoreo (cacti, nagios, etc)

Definir la línea base en los servidores: iostat, vmstat, status e innodb status en mysql.

Logear todo, en particular las queries lentas (en lo posible usar el patch microslow).

Predecir el punto del swap de la muerte.

Corregir el problema

Queries

Select * from tabla_gigante;

Select count(*) where condicion;

Select a, b where f(a) = const;

Select a where b in (...);

Select a where b not in (...);

Corregir el problemaÍndices (B-TREES):

Se leen de izquierda a derecha sin saltarse ninguno.

Toda query debe ser indexada.

Ojo con los índices “repetidos”.

Si lo permite la memoria, usar los índices para leer los elementos seleccionados.

En InnoDB la llave primaria es siempre parte del índice.

Usar LEFT al crear índices de textos.


Caches:

Toda la RAM disponible se debería usar en caches.

Distribuidos son más “eficientes”.

Replicados son más seguros.

Buddy-Replication es lo mejor de ambos mundos.

Llave-valor v/s Path-valor.

No confundir con Query Cache de mysql.


Búsqueda:

No usar LIKE

En vez de LIKE usar FULL-TEXT.

Mejor que FULL-TEXT es sphinx o lucene.

Tipos de datos

Usar los tipos de datos más chicos posible.

Declararlos “NOT NULL” siempre que se pueda.


Como regla general usar InnoDB plugin salvo:

Si no importa la persistencia de los datos y la tabla es “chica”, es más rápido usar MEMORY.

Si se necesita búsqueda full-text se debe usar MyISAM.

Si la aplicación está hecha para MyISAM (usa el feature del count(*) extensivamente, por ejemplo).

Probar la solución

Tener servidores de prueba similares a producción y someterlos a carga real (usando logs de transacciones).

Automatizar las pruebas de carga: jmeter.

Finalmente

Aplicar la solución

...y a buscar el siguiente cuello de botella...

Desafíos para escalar aplicaciones WebEmilio DavisGerente de Tecnologí[email protected]/emiliodavis

Webprendedor 2009 Escalabilidad

Technology