arquitecturas escalables para aplicaciones web - egdares futch, unitec
DESCRIPTION
Presentación acerca de Escalabilidad de Infraestructuras de Alojamiento por Egdares Futch de UNITEC en la conferencia WebConfLatino 2009.TRANSCRIPT
Arquitecturas Escalables para Aplicaciones en el Web
Egdares Futch H. Junio 2009
¿Por qué este tema? Algunos titulares recientes
Arquitectura
Pensemos en un supermercado, con múltiples filas y múltiples cajeros.
FrustracionesFilas “lentas”Throughput impredecible
¿Y la “Caja Rápida”?
Arquitectura
Ahora pensemos en un banco, donde hay una sola fila y varios cajeros
Mayor satisfacciónUna transacción “lenta” no detiene otrasMayor throughput
¿Cuál es la diferencia?
ARQUITECTURA
Arquitecturas tradicionales
Un gran banco local tiene:
200 sucursales5 cajeros en cada sucursal80 ATMs0.3 transacción/min por cajero/ATM
De 9AM a 7PM procesa:324 transacciones por minuto5.4 transacciones/segundo
¿De 7PM a 9AM ?
Arquitecturas tradicionales
Una universidad pública local tiene:
8 campus5,000 estudiantes en cada campus5 cursos trimestrales / estudiante2,000 cursos en oferta académica50 estudiantes por curso
Durante el período de registro trimestral, que dura 7 días, se procesan:
50 estudiantes/segundo2.5 segundos de tiempo de procesamiento/estudianteCola de 12 transacciones => Espera de 30 segundos
(La conectividad en la región)
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?
En arquitecturas Web
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!
¿Qué es la Arquitectura?
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.
Arquitectura base 1.0
Servidor deaplicaciones
Base dedatos
Cache
Almacenamiento
AJAX
Usuarios vienende la “nube”
¡A veces, tendemos a no separar en capas nuestras aplicaciones!
Picos de trabajo
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 ejemplo práctico
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)
Un ejemplo práctico
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
Un ejemplo práctico
¿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)
Un ejemplo práctico
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
¿Qué sucede en el mundo real?
Twitter = 200 tweets / segundo
NASDAQ = 35,000 mensajes /segundo
Google = 46,000 API calls / segundo
OK, lo entiendo. ¿Ahora qué?
Necesitamos algo importante
Escalabilidad
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
Dos tipos de escalabilidad 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
¿Por qué difícil?
Recordemos nuestra arquitectura inicial
Servidor deaplicaciones
Base dedatos
Cache
Almacenamiento
AJAX
Escalando horizontalmente…
Un poco más…
La enchilada completa!
¿Qué pasó tras bambalinas?
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)
¿Qué pasó tras bambalinas? 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
¿Qué pasó tras bambalinas?
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
Con todo lo anterior…
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.
Las prácticas son…
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
Para profundizar
Scaling for E-BusinessMenasce y Almeida
Building Scalable Web SitesHenderson
High Performance Web SitesSouders
¡GRACIAS!
[email protected]/perfil/efutchwww.twitter.com/efutch
http://efutch.blogspot.comhttp://maestros.unitec.edu/~efutch