• Like
Arquitecturas Escalables de Web
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Arquitecturas Escalables de Web

  • 1,295 views
Published

Presentación para el WebConfLatino 2009

Presentación para el WebConfLatino 2009

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,295
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
33
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Arquitecturas Escalables para Aplicaciones en el Web Egdares Futch H. Junio 2009
  • 2.  
  • 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. Servidor de aplicaciones Base de datos Cache Almacenamiento AJAX Usuarios vienen de la “nube” ¡A veces, tendemos a no separar en capas nuestras aplicaciones!
  • 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
  • 17. OK, lo entiendo. ¿Ahora qué?
  • 18.
    • Escalabilidad
  • 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
    Servidor de aplicaciones Base de datos Cache Almacenamiento AJAX
  • 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
  • 30. Scaling for E-Business Menasce y Almeida Building Scalable Web Sites Henderson High Performance Web Sites Souders
  • 31. [email_address] www.blipea.com/perfil/efutch www.twitter.com/efutch http://efutch.blogspot.com http://maestros.unitec.edu/~efutch