Arquitecturas Escalables para Aplicaciones  en el Web Egdares  Futch H. Junio  2009
 
<ul><li>Pensemos en un supermercado, con múltiples filas y múltiples cajeros. </li></ul>Frustraciones Filas “lentas” Throu...
<ul><li>Ahora pensemos en un banco, donde hay una sola fila y varios cajeros </li></ul>Mayor satisfacción Una transacción ...
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 7...
Una universidad pública local tiene: 8 campus 5,000 estudiantes en cada campus 5 cursos trimestrales / estudiante 2,000 cu...
<ul><li>Para ir a: </li></ul><ul><li>Mi banco </li></ul><ul><li>Mi universidad </li></ul><ul><li>Mi periódico </li></ul><u...
<ul><li>Caso TuBabel </li></ul><ul><ul><li>2,993 visitas/día  equivale a 1 visita cada 28 segundos </li></ul></ul><ul><ul>...
<ul><li>No hablaremos de especificaciones técnicas, como memoria, procesador, etc. </li></ul><ul><li>Nos referimos al conj...
Servidor de aplicaciones Base de datos Cache Almacenamiento AJAX Usuarios vienen de la “nube” ¡A veces, tendemos a no sepa...
<ul><li>La existencia de picos de trabajo (peak workloads) hace que determinar un diseño óptimo de arquitectura para aplic...
<ul><li>Un servidor web, con scripting del lado del servidor, conectado a Internet por un canal E1. </li></ul><ul><li>Medi...
<ul><li>Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg </li></ul><ul><li>Demanda del canal inbound = 240*8 /  2,097,152 =...
<ul><li>¿Qué tal si ahora le hacemos un lindo menú en Flash, o agregamos botones animados en DHTML, o usamos AJAX para una...
<ul><li>Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg </li></ul><ul><li>Demanda del canal inbound = 240*8 /  2,097,152 =...
<ul><li>Twitter = 200 tweets / segundo </li></ul><ul><li>NASDAQ = 35,000 mensajes /segundo </li></ul><ul><li>Google = 46,0...
OK, lo entiendo.  ¿Ahora qué?
<ul><li>Escalabilidad </li></ul>
<ul><li>Si </li></ul><ul><ul><li>Soportar incremento en tráfico </li></ul></ul><ul><ul><li>Soportar incremento en la data ...
<ul><li>Escalabilidad vertical </li></ul><ul><ul><li>Crecimiento de cajas </li></ul></ul><ul><ul><li>Un servidor pequeño, ...
<ul><li>Recordemos nuestra arquitectura inicial </li></ul>Servidor de aplicaciones Base de datos Cache Almacenamiento AJAX
 
 
 
<ul><li>Manejo de sesiones </li></ul><ul><ul><li>Stateless, similar a NFS, cookies “pesadas” </li></ul></ul><ul><li>Balanc...
<ul><li>Bases de datos </li></ul><ul><ul><li>En general, el tema de mejora de base de datos en una aplicación Web escala v...
<ul><li>Caching </li></ul><ul><ul><li>Mantener copias de objetos frecuentemente usados hace la escalabilidad menos necesar...
<ul><li>Una aplicación Web es más que presentación,  usabilidad , genialidad, o aplicabilidad. </li></ul><ul><li>Se suma  ...
<ul><li>Tratar de diseñar para escalar linealmente añadiendo hardware </li></ul><ul><li>Balancear cargas entre grupos de c...
Scaling for E-Business Menasce y Almeida Building Scalable Web Sites Henderson High Performance Web Sites Souders
[email_address] www.blipea.com/perfil/efutch www.twitter.com/efutch http://efutch.blogspot.com http://maestros.unitec.edu/...
Upcoming SlideShare
Loading in...5
×

Arquitecturas Escalables de Web

1,327

Published on

Presentación para el WebConfLatino 2009

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,327
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Arquitecturas Escalables de Web

    1. 1. Arquitecturas Escalables para Aplicaciones en el Web Egdares Futch H. Junio 2009
    2. 3. <ul><li>Pensemos en un supermercado, con múltiples filas y múltiples cajeros. </li></ul>Frustraciones Filas “lentas” Throughput impredecible ¿Y la “Caja Rápida”?
    3. 4. <ul><li>Ahora pensemos en un banco, donde hay una sola fila y varios cajeros </li></ul>Mayor satisfacción Una transacción “lenta” no detiene otras Mayor throughput ¿Cuál es la diferencia? ARQUITECTURA
    4. 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 ?
    5. 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
    6. 7. <ul><li>Para ir a: </li></ul><ul><li>Mi banco </li></ul><ul><li>Mi universidad </li></ul><ul><li>Mi periódico </li></ul><ul><li>Sitios de un país vecino </li></ul><ul><li>¡Tengo que pasar por Miami! </li></ul><ul><li>Pocos acuerdo de “peering” entre ISP locales </li></ul><ul><li>¿Conectividad local más cara que la internacional? </li></ul>
    7. 8. <ul><li>Caso TuBabel </li></ul><ul><ul><li>2,993 visitas/día equivale a 1 visita cada 28 segundos </li></ul></ul><ul><ul><li>8,987 consultas/día </li></ul></ul><ul><li>Caso Flickr </li></ul><ul><ul><li>40,000 fotos/segundo! </li></ul></ul><ul><ul><li>130,000 consultas/segundo! </li></ul></ul>
    8. 9. <ul><li>No hablaremos de especificaciones técnicas, como memoria, procesador, etc. </li></ul><ul><li>Nos referimos al conjunto de elementos de red, computadoras, aplicaciones y sistemas operativos que soportan una aplicación Web. </li></ul>
    9. 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!
    10. 11. <ul><li>La existencia de picos de trabajo (peak workloads) hace que determinar un diseño óptimo de arquitectura para aplicaciones Web sea difícil. </li></ul><ul><ul><li>Día de pago </li></ul></ul><ul><ul><li>Semana de matrícula </li></ul></ul><ul><ul><li>Después de que ganó la Selección Nacional </li></ul></ul><ul><ul><li>Cuando pasa el temblor (8) </li></ul></ul>
    11. 12. <ul><li>Un servidor web, con scripting del lado del servidor, conectado a Internet por un canal E1. </li></ul><ul><li>Mediciones muestran lo siguiente: </li></ul><ul><ul><li>5 mseg para procesar el HTTP request (240 bytes) </li></ul></ul><ul><ul><li>40 mseg para correr el script </li></ul></ul><ul><ul><li>5 mseg para responder (5,120 bytes) </li></ul></ul>
    12. 13. <ul><li>Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg </li></ul><ul><li>Demanda del canal inbound = 240*8 / 2,097,152 = 0.00091 seg </li></ul><ul><li>Demanda del canal de salida = 5,120*8 / 2,097,152 = 0.019 seg </li></ul><ul><li>Atendemos un máximo de 20 transacciones/seg </li></ul><ul><li>En un servidor de $10,000, nos cuesta $8.33 cada transacción </li></ul>
    13. 14. <ul><li>¿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? </li></ul><ul><li>Blipea.com necesita 272.5K la primera vez (cache miss) ó 150K al refrescar (cache hit) </li></ul>
    14. 15. <ul><li>Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg </li></ul><ul><li>Demanda del canal inbound = 240*8 / 2,097,152 = 0.00091 seg </li></ul><ul><li>Demanda del canal de salida = 150,000*8 / 2,097,152 = 0.57 seg </li></ul><ul><li>Es decir que, ahora podemos atender únicamente dos transacciones por segundo (al refrescar) </li></ul><ul><li>El CPU está muerto de risa </li></ul><ul><li>El canal está muerto de capacidad </li></ul>
    15. 16. <ul><li>Twitter = 200 tweets / segundo </li></ul><ul><li>NASDAQ = 35,000 mensajes /segundo </li></ul><ul><li>Google = 46,000 API calls / segundo </li></ul>
    16. 17. OK, lo entiendo. ¿Ahora qué?
    17. 18. <ul><li>Escalabilidad </li></ul>
    18. 19. <ul><li>Si </li></ul><ul><ul><li>Soportar incremento en tráfico </li></ul></ul><ul><ul><li>Soportar incremento en la data </li></ul></ul><ul><ul><li>Henderson dice: “que además sea fácil de mantener” </li></ul></ul><ul><li>No </li></ul><ul><ul><li>Velocidad pura </li></ul></ul><ul><ul><li>Una tecnología particular </li></ul></ul>
    19. 20. <ul><li>Escalabilidad vertical </li></ul><ul><ul><li>Crecimiento de cajas </li></ul></ul><ul><ul><li>Un servidor pequeño, luego un servidor quad core, luego un servidor multicore, luego …. </li></ul></ul><ul><ul><li>Fácil! Pero limitada en cierta medida </li></ul></ul><ul><li>Escalabilidad Horizontal </li></ul><ul><ul><li>Más cajas </li></ul></ul><ul><ul><li>Balanceo de cargas </li></ul></ul><ul><ul><li>Difícil! Pero crecimiento ilimitado </li></ul></ul>
    20. 21. <ul><li>Recordemos nuestra arquitectura inicial </li></ul>Servidor de aplicaciones Base de datos Cache Almacenamiento AJAX
    21. 25. <ul><li>Manejo de sesiones </li></ul><ul><ul><li>Stateless, similar a NFS, cookies “pesadas” </li></ul></ul><ul><li>Balanceo de cargas </li></ul><ul><ul><li>Simple: DNS round-robin </li></ul></ul><ul><ul><li>Hardware: Múltiples *.* de red </li></ul></ul><ul><ul><li>Software: Perlbal, Pound </li></ul></ul><ul><ul><li>Más allá: Balanceo Geográfico de Cargas (Global) </li></ul></ul>
    22. 26. <ul><li>Bases de datos </li></ul><ul><ul><li>En general, el tema de mejora de base de datos en una aplicación Web escala verticalmente </li></ul></ul><ul><ul><li>Sin embargo, las aplicaciones Web tienen una proporción 80-90% de lecturas vs. escrituras </li></ul></ul><ul><ul><li>En ese caso, podemos usar replicación y distribución de datos </li></ul></ul><ul><ul><li>Y un tabú: denormalización </li></ul></ul>
    23. 27. <ul><li>Caching </li></ul><ul><ul><li>Mantener copias de objetos frecuentemente usados hace la escalabilidad menos necesaria o por lo menos más barata </li></ul></ul><ul><ul><li>Redes de Distribución de contenido </li></ul></ul><ul><li>Alta disponibilidad </li></ul><ul><ul><li>Identificar Puntos Únicos de Falla </li></ul></ul><ul><ul><li>Eliminarlos </li></ul></ul>
    24. 28. <ul><li>Una aplicación Web es más que presentación, usabilidad , genialidad, o aplicabilidad. </li></ul><ul><li>Se suma la arquitectura con la que haya sido diseñada. </li></ul><ul><li>Actualmente es un arte, aprendido de los sitios más exitosos del Internet. </li></ul>
    25. 29. <ul><li>Tratar de diseñar para escalar linealmente añadiendo hardware </li></ul><ul><li>Balancear cargas entre grupos de componentes </li></ul><ul><li>Diseñar pensando en redundancia y tolerancia a fallas </li></ul><ul><li>Algo importante: métricas y estadísticas proveen visión de qué sucede en nuestra aplicación </li></ul>
    26. 30. Scaling for E-Business Menasce y Almeida Building Scalable Web Sites Henderson High Performance Web Sites Souders
    27. 31. [email_address] www.blipea.com/perfil/efutch www.twitter.com/efutch http://efutch.blogspot.com http://maestros.unitec.edu/~efutch
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×