Arquitecturas Escalables para
Aplicaciones en el Web
Egdares Futch H.
Junio 2009

 Pensemos en un supermercado, con
múltiples filas y múltiples cajeros.
Frustraciones
Filas “lentas”
Throughput impredecible
¿Y la “Caja Rápida”?

 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

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 ?

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

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?

 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!

 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.

¡A veces, tendemos a no
separar en capas
nuestras aplicaciones! Almacenamiento
Usuarios vienen Cache
de la “nube”
Servidor de Base de AJAX
aplicaciones datos

 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)

 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)

 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

 ¿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)

 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

 Twitter = 200 tweets / segundo
 NASDAQ = 35,000 mensajes /segundo
 Google = 46,000 API calls / segundo

OK, lo entiendo. ¿Ahora qué?

Escalabilidad

 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

 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

 Recordemos nuestra arquitectura inicial
Almacenamiento
Cache
Servidor de Base de AJAX
aplicaciones datos

 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)

 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

 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

 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.

 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

Scaling for E-Business
Menasce y Almeida
Building Scalable Web Sites
Henderson
High Performance Web Sites
Souders

efutch@gmail.com
www.blipea.com/perfil/efutch
www.twitter.com/efutch
http://efutch.blogspot.com
http://maestros.unitec.edu/~efutch