Arquitecturas Escalables para
Aplicaciones en el Web




         Egdares   Futch H.
          Junio      2009
   Pensemos en un supermercado, con
    múltiples filas y múltiples cajeros.

                               Frustracione...
   Ahora pensemos en un banco, donde hay
    una sola fila y varios cajeros

                            Mayor satisfacci...
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...
Una universidad pública local tiene:

8 campus
5,000 estudiantes en cada campus
5 cursos trimestrales / estudiante
2,000 c...
Para ir a:
•Mi banco
•Mi universidad
•Mi periódico
•Sitios de un país vecino

¡Tengo que pasar por Miami!

Pocos acuerdo d...
   Caso TuBabel
     2,993 visitas/día equivale a 1 visita cada 28
      segundos
     8,987 consultas/día


   Caso F...
   No hablaremos de especificaciones
    técnicas, como memoria, procesador, etc.

   Nos referimos al conjunto de eleme...
¡A veces, tendemos a no
                  separar en capas
                  nuestras aplicaciones!    Almacenamiento



U...
   La existencia de picos de trabajo (peak
    workloads) hace que determinar un diseño
    óptimo de arquitectura para a...
 Un servidor web, con scripting del lado del
  servidor, conectado a Internet por un canal E1.
 Mediciones muestran lo s...
   Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg
   Demanda del canal inbound = 240*8 / 2,097,152 = 0.00091
    seg
 ...
   ¿Qué tal si ahora le hacemos un lindo menú
    en Flash, o agregamos botones animados en
    DHTML, o usamos AJAX para...
   Demanda de servicio CPU = 5 + 40 +5 = 0.050 seg
   Demanda del canal inbound = 240*8 / 2,097,152
    = 0.00091 seg
 ...
   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ác...
   Escalabilidad vertical
     Crecimiento de cajas
     Un servidor pequeño, luego un servidor quad
      core, luego ...
   Recordemos nuestra arquitectura inicial


                                       Almacenamiento



                   ...
   Manejo de sesiones
     Stateless, similar a NFS, cookies “pesadas”


   Balanceo de cargas
     Simple: DNS round-...
   Bases de datos
     En general, el tema de mejora de base de datos en una
      aplicación Web escala verticalmente
 ...
   Caching
     Mantener copias de objetos frecuentemente
      usados hace la escalabilidad menos necesaria o
      por...
   Una aplicación Web es más que
    presentación, usabilidad , genialidad, o
    aplicabilidad.

   Se suma la arquitec...
   Tratar de diseñar para escalar linealmente
    añadiendo hardware
   Balancear cargas entre grupos de
    componentes...
Scaling for E-Business
Menasce y Almeida




              Building Scalable Web Sites
              Henderson




       ...
efutch@gmail.com
www.blipea.com/perfil/efutch
www.twitter.com/efutch
http://efutch.blogspot.com
http://maestros.unitec.edu...
Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC
Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC
Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC
Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC
Próxima SlideShare
Cargando en…5
×

Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC

3.047 visualizaciones

Publicado el

Presentación acerca de Escalabilidad de Infraestructuras de Alojamiento por Egdares Futch de UNITEC en la conferencia WebConfLatino 2009.

Publicado en: Tecnología, Empresariales
0 comentarios
3 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
3.047
En SlideShare
0
De insertados
0
Número de insertados
13
Acciones
Compartido
0
Descargas
113
Comentarios
0
Recomendaciones
3
Insertados 0
No insertados

No hay notas en la diapositiva.
  • Estoyusandounadistribución de Poisson, en horapico de 50 estudiantesporsegundo, en un servidorqueprocesa 100 transaccionesporsegundo,
  • Arquitecturas Escalables para Aplicaciones Web - Egdares Futch, UNITEC

    1. 1. Arquitecturas Escalables para Aplicaciones en el Web Egdares Futch H. Junio 2009
    2. 2.  Pensemos en un supermercado, con múltiples filas y múltiples cajeros. Frustraciones Filas “lentas” Throughput impredecible ¿Y la “Caja Rápida”?
    3. 3.  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
    4. 4. 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. 5. 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. 6. 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?
    7. 7.  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!
    8. 8.  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.
    9. 9. ¡A veces, tendemos a no separar en capas nuestras aplicaciones! Almacenamiento Usuarios vienen Cache de la “nube” Servidor de Base de AJAX aplicaciones datos
    10. 10.  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)
    11. 11.  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)
    12. 12.  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
    13. 13.  ¿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)
    14. 14.  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
    15. 15.  Twitter = 200 tweets / segundo  NASDAQ = 35,000 mensajes /segundo  Google = 46,000 API calls / segundo
    16. 16. OK, lo entiendo. ¿Ahora qué?
    17. 17. Escalabilidad
    18. 18.  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
    19. 19.  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
    20. 20.  Recordemos nuestra arquitectura inicial Almacenamiento Cache Servidor de Base de AJAX aplicaciones datos
    21. 21.  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)
    22. 22.  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
    23. 23.  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
    24. 24.  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.
    25. 25.  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
    26. 26. Scaling for E-Business Menasce y Almeida Building Scalable Web Sites Henderson High Performance Web Sites Souders
    27. 27. efutch@gmail.com www.blipea.com/perfil/efutch www.twitter.com/efutch http://efutch.blogspot.com http://maestros.unitec.edu/~efutch

    ×