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. 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. 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. 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. 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. Es difícil y no hay recetas infalibles, pero nuestra
experiencia en Bligoo nos dice que necesitamos al
menos:
13. Calidad del equipo
Para que una aplicación no sólo crezca, sino que
escale, es necesario un equipo excepcional.
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. 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.
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. 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. Apertura de mente
Pese a lo dicho antes, soluciones poco ortodoxas
pueden ser justo lo que necesitabas. (NoSQL por
ejemplo)
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. 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. 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. 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. 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.
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. Mysql Replication
Los esclavos funcionan serialmente, por lo que
pueden atrasarse. Si pierden la conexión con el
maestro pueden atrasarse sin saberlo.
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. 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. 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. 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. 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. 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. 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. 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.