Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Desafíos para escalar
aplicaciones Web
Emilio Davis
Gerente de Tecnologías
Bligoo.com
emilio@bluecompany.cl
twitter.com/em...
1. Definiciones
2. El desafío de escalar
3. Elegir los componentes de las capas de la
aplicación.
4. Ciclo crecimiento-tun...
1. Definiciones
2. El desafío de escalar
3. Elegir los componentes de las capas de la
aplicación
4. Ciclo crecimiento-tunn...
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.
Pros
Trivial de implementar y administrar
Casi todo el software...
Escalamiento Horizontal: Agregar más nodos.
Pros
Costo de hardware lineal.
Contra
Más complejo de implementar.
Más co...
Usualmente se mezclan los dos modelos, se
escala verticalmente mientras los costos no se
disparan y horizontalmente despué...
1. Definiciones
2. El desafío de escalar
3. Elegir los componentes de las capas de la
aplicación
4. Ciclo crecimiento-tunn...
Crecer verticalmente es trivial (o razonablemente
fácil).
El real desafío es crecer horizontalmente
manteniendo controlado...
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 ...
Calidad de los procesos
No es posible generar una aplicación escalable si
hay emergencias todos los domingos.
Ciclos de de...
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 N...
Framework y lenguaje de desarrollo
con énfasis en rendimiento
Muchos frameworks permiten prototipado rápido
pero no ofrece...
Apertura de mente
Pese a lo dicho antes, soluciones poco ortodoxas
pueden ser justo lo que necesitabas. (NoSQL por
ejemplo)
1. Definiciones
2. El desafío de escalar
3. Elegir los componentes de las capas de la
aplicación
4. Ciclo crecimiento-tunn...
Contenido estático (web server)
Hay muchas soluciones opensource y de código
privativo que resuelven bien este problema.
a...
Lógica de la aplicación
Decidir el lenguage de programación basado en la
experiencia del equipo mientras ofrezca
capacidad...
Capa de lógica (cont.)
Por la naturaleza stateless de las aplicaciones
web, usualmente la capa de lógica escala
trivialmen...
Capa de persistencia
En las aplicaciones Web la capa de persistencia
(usualmente base de datos) es la que presenta las
may...
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.
Pe...
Mysql Replication
Los esclavos funcionan serialmente, por lo que
pueden atrasarse. Si pierden la conexión con el
maestro p...
Mysql cluster + replication
Siempre aparecerán problemas de performance.
La gracia está en darse cuenta a tiempo.
1. Definiciones
2. El desafío de escalar
3. Elegir los componentes de las capas de la
aplicación
4. Ciclo crecimiento-tunn...
Detectar (o predecir) rápidamente el
problema
Usar software de monitoreo (cacti, nagios, etc)
Definir la línea base en l...
Corregir el problema
Queries
Select * from tabla_gigante;
Select count(*) where condicion;
Select a, b where f(a) = co...
Corregir el problema
Índices (B-TREES):
Se leen de izquierda a derecha sin saltarse
ninguno.
Toda query debe ser indexa...
Corregir el problema
Caches:
Toda la RAM disponible se debería usar en
caches.
Distribuidos son más “eficientes”.
Repl...
Corregir el problema
Búsqueda:
No usar LIKE
En vez de LIKE usar FULL-TEXT.
Mejor que FULL-TEXT es sphinx o lucene.
Ti...
Corregir el problema
Como regla general usar InnoDB plugin salvo:
Si no importa la persistencia de los datos y
la tabla ...
Probar la solución
Tener servidores de prueba similares a
producción y someterlos a carga real (usando
logs de transaccio...
Finalmente
Aplicar la solución
...y a buscar el siguiente cuello de botella...
Desafíos para escalar
aplicaciones Web
Emilio Davis
Gerente de Tecnologías
Bligoo.com
emilio@bluecompany.cl
twitter.com/em...
Upcoming SlideShare
Loading in …5
×

Webprendedor 2009 Escalabilidad

1,348 views

Published on

Published in: Technology, Business
  • Be the first to comment

Webprendedor 2009 Escalabilidad

  1. 1. Desafíos para escalar aplicaciones Web Emilio Davis Gerente de Tecnologías Bligoo.com emilio@bluecompany.cl twitter.com/emiliodavis
  2. 2. 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
  3. 3. 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
  4. 4. Pasado cierto número de usuarios la rentabilidad de cada uno debe ser positiva.
  5. 5. Bligoo: Ancho de banda consumido v/s Carga
  6. 6. Se puede escalar de dos formas, vertical y horizontalmente.
  7. 7. Escalamiento Vertical: Agregar más “poder” a cada nodo. Pros Trivial de implementar y administrar Casi todo el software escala bien verticalmente Ej. Más RAM → Más procesos Apache/Java Contras Costo de hardware exponencialmente alto.
  8. 8. Escalamiento Horizontal: Agregar más nodos. Pros Costo de hardware lineal. Contra Más complejo de implementar. Más complejo de administrar. No todo el software está preparado.
  9. 9. 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)
  10. 10. 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
  11. 11. Crecer verticalmente es trivial (o razonablemente fácil). El real desafío es crecer horizontalmente manteniendo controlado el costo de desarrollo y operación.
  12. 12. Es difícil y no hay recetas infalibles, pero nuestra experiencia en Bligoo nos dice que necesitamos al menos:
  13. 13. Calidad del equipo Para que una aplicación no sólo crezca, sino que escale, es necesario un equipo excepcional.
  14. 14. 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.
  15. 15. Calidad de los procesos No 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.
  16. 16. Calidad del software Todas las líneas de código deben ser “aceptables” y unas pocas geniales.
  17. 17. 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).
  18. 18. 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.
  19. 19. Apertura de mente Pese a lo dicho antes, soluciones poco ortodoxas pueden ser justo lo que necesitabas. (NoSQL por ejemplo)
  20. 20. 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
  21. 21. Contenido estático (web server) Hay muchas soluciones opensource y de código privativo que resuelven bien este problema. apache, lighttpd, nginx, iis, etc
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. Escalabilidad en Mysql Existen dos modelos de crecimiento horizontal en Mysql Mysql cluster y Mysql Replication
  26. 26. Mysql Cluster Promete alta disponibilidad y buen performance pero es muy complejo de implementar y administrar.
  27. 27. Mysql Replication
  28. 28. 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.
  29. 29. Mysql Replication Los esclavos funcionan serialmente, por lo que pueden atrasarse. Si pierden la conexión con el maestro pueden atrasarse sin saberlo.
  30. 30. Mysql cluster + replication
  31. 31. Siempre aparecerán problemas de performance. La gracia está en darse cuenta a tiempo.
  32. 32. 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
  33. 33. 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.
  34. 34. 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 (...);
  35. 35. 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.
  36. 36. Corregir el problema 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.
  37. 37. Corregir el problema 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.
  38. 38. Corregir el problema 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).
  39. 39. 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.
  40. 40. Finalmente Aplicar la solución ...y a buscar el siguiente cuello de botella...
  41. 41. Desafíos para escalar aplicaciones Web Emilio Davis Gerente de Tecnologías Bligoo.com emilio@bluecompany.cl twitter.com/emiliodavis

×