Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC

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

Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC

by Alejandro Corpeño on Jun 10, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 12

Statistics

Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC — Presentation Transcript