3. Pensemos en un supermercado, con
múltiples filas y múltiples cajeros.
Frustraciones
Filas “lentas”
Throughput impredecible
¿Y la “Caja Rápida”?
4. Ahora pensemos en un banco, donde hay
una sola fila y varios cajeros
Mayor satisfacción
Una transacción “lenta” no
detiene otras
Mayor throughput
¿Cuál es la diferencia?
ARQUITECTURA
5. Un gran banco local tiene:
200 sucursales
5 cajeros en cada sucursal
80 ATMs
0.3 transacción/min por cajero/ATM
De 9AM a 7PM procesa:
324 transacciones por minuto
5.4 transacciones/segundo
¿De 7PM a 9AM ?
6. Una universidad pública local tiene:
8 campus
5,000 estudiantes en cada campus
5 cursos trimestrales / estudiante
2,000 cursos en oferta académica
50 estudiantes por curso
Durante el período de registro
trimestral, que dura 7 días, se procesan:
50 estudiantes/segundo
2.5 segundos de tiempo de
procesamiento/estudiante
Cola de 12 transacciones => Espera de 30
segundos
7. Para ir a:
•Mi banco
•Mi universidad
•Mi periódico
•Sitios de un país vecino
¡Tengo que pasar por Miami!
Pocos acuerdo de “peering” entre ISP locales
¿Conectividad local más cara que la internacional?
8. Caso TuBabel
2,993 visitas/día equivale a 1 visita cada 28
segundos
8,987 consultas/día
Caso Flickr
40,000 fotos/segundo!
130,000 consultas/segundo!
9. No hablaremos de especificaciones
técnicas, como memoria, procesador, etc.
Nos referimos al conjunto de elementos de
red, computadoras, aplicaciones y sistemas
operativos que soportan una aplicación Web.
10. ¡A veces, tendemos a no
separar en capas
nuestras aplicaciones! Almacenamiento
Usuarios vienen Cache
de la “nube”
Servidor de Base de AJAX
aplicaciones datos
11. La existencia de picos de trabajo (peak
workloads) hace que determinar un diseño
óptimo de arquitectura para aplicaciones
Web sea difícil.
Día de pago
Semana de matrícula
Después de que ganó la Selección Nacional
Cuando pasa el temblor (8)
12. Un servidor web, con scripting del lado del
servidor, conectado a Internet por un canal E1.
Mediciones muestran lo siguiente:
5 mseg para procesar el HTTP request (240 bytes)
40 mseg para correr el script
5 mseg para responder (5,120 bytes)
13. Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg
Demanda del canal inbound = 240*8 / 2,097,152 = 0.00091
seg
Demanda del canal de salida = 5,120*8 / 2,097,152 = 0.019
seg
Atendemos un máximo de 20 transacciones/seg
En un servidor de $10,000, nos cuesta $8.33 cada transacción
14. ¿Qué tal si ahora le hacemos un lindo menú
en Flash, o agregamos botones animados en
DHTML, o usamos AJAX para una mejor
interacción?
Blipea.com necesita 272.5K la primera vez
(cache miss) ó 150K al refrescar (cache hit)
15. Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg
Demanda del canal inbound = 240*8 / 2,097,152
= 0.00091 seg
Demanda del canal de salida = 150,000*8 /
2,097,152 = 0.57 seg
Es decir que, ahora podemos atender
únicamente dos transacciones por segundo (al
refrescar)
El CPU está muerto de risa
El canal está muerto de capacidad
16. Twitter = 200 tweets / segundo
NASDAQ = 35,000 mensajes /segundo
Google = 46,000 API calls / segundo
19. Si
Soportar incremento en tráfico
Soportar incremento en la data
Henderson dice: “que además sea fácil de
mantener”
No
Velocidad pura
Una tecnología particular
20. Escalabilidad vertical
Crecimiento de cajas
Un servidor pequeño, luego un servidor quad
core, luego un servidor multicore, luego ….
Fácil! Pero limitada en cierta medida
Escalabilidad Horizontal
Más cajas
Balanceo de cargas
Difícil! Pero crecimiento ilimitado
21. Recordemos nuestra arquitectura inicial
Almacenamiento
Cache
Servidor de Base de AJAX
aplicaciones datos
22.
23.
24.
25. Manejo de sesiones
Stateless, similar a NFS, cookies “pesadas”
Balanceo de cargas
Simple: DNS round-robin
Hardware: Múltiples *.* de red
Software: Perlbal, Pound
Más allá: Balanceo Geográfico de Cargas (Global)
26. Bases de datos
En general, el tema de mejora de base de datos en una
aplicación Web escala verticalmente
Sin embargo, las aplicaciones Web tienen una proporción
80-90% de lecturas vs. escrituras
En ese caso, podemos usar replicación y distribución de
datos
Y un tabú: denormalización
27. Caching
Mantener copias de objetos frecuentemente
usados hace la escalabilidad menos necesaria o
por lo menos más barata
Redes de Distribución de contenido
Alta disponibilidad
Identificar Puntos Únicos de Falla
Eliminarlos
28. Una aplicación Web es más que
presentación, usabilidad , genialidad, o
aplicabilidad.
Se suma la arquitectura con la que haya sido
diseñada.
Actualmente es un arte, aprendido de los
sitios más exitosos del Internet.
29. Tratar de diseñar para escalar linealmente
añadiendo hardware
Balancear cargas entre grupos de
componentes
Diseñar pensando en redundancia y
tolerancia a fallas
Algo importante: métricas y estadísticas
proveen visión de qué sucede en nuestra
aplicación