Arquitectura de las nuevas aplicaciones web

Como lograr escalabilidad, alta disponibilidad

y alto rendimiento

¿NUEVAS APLICACIONES WEB?

• Las aplicaciones de escritorio se pasan a la web (gmail, google docs)

• Nuestras vidas y actividades se mueven a la nube

• Los servicios y la información en la nube, accesibles con cualquier navegador conectado a la nube. (SaaS)

• Necesitamos igualdad de condiciones y rendimiento en la nube

Retos

• Velocidad (Alto Rendimiento)

• Ubicuidad

• Disponibilidad

• Seguridad

• Estabilidad

• Compatibilidad

LA WEB EVOLUCIONO

• Contenido puramente textual (Web 1.0)

• Completa interactividad

• Multimedia

• La web como plataforma (Web 2.0)

• Web 3.0 (??)

Browsers

1995 2010

• Experiencia de usuario enriquecida

– Gráficos

– Video

– Interactividad

• Acceso offline

• HTML 5

Retos

• Velocidad (Alto Rendimiento)

• Seguridad

• Estabilidad

• Compatibilidad

• El usuario, sus aplicaciones y sus datos se mueven a la web

• La web, los navegadores y las conexiones evolucionan

• + velocidad

• En cualquier lugar

¿ESCALABILIDAD?

Escalabilidad es aumentar la capacidad de atender usuarios o volumen de datos de manera

lineal con la capacidad de cómputo añadida

¿Por qué es importante?

• Pérdida de tráfico y/o ventas

– Google: +500ms – -20% tráfico

– Yahoo: +400ms – -5%/-9% tráfico

– Amazon: 100ms – -1% ventas

• Ahorro de costos

• Mejor experiencia de uso

|

http://webpagetest.org

• Tiempo de respuesta

– 0.1s a 1s: No es necesario feedback al usuario

– 1s a 10s: Es necesario feedback al usuario (cargador, opciones de carga)

– >10s: El usuario no llega a los 10s

¿Cómo escalamos?

Scaling up (vertical)

• Upgrades a cada nodo

• Más CPU

• Más memoria

• Más máquina

• Sencillo

• Muy limitado

Scaling out (horizontal)

• Aumentar el nro de nodos

• Más máquinas

• Distribuir

• Descentralizar

• Complicado

Sunfire E20k 36 x 1.8GHz

U$S450.000 – U$S 2.500.000

PowerEdge SC1435 Dualcore 1.8GHz

U$S 1.500

• “sólo se puede escalar con Java” (JA!)

• “PHP/Python/Ruby no escalan” (JA!)

• La escalabilidad depende del diseño de la arquitectura, NO de la tecnología utilizada

• NO es una tecnología

• NO es un protocolo

Escalar verticalmente

• Reemplazar el servidor por uno más grande

• Usar CPUs más rápidos

• Un servidor que es el doble de rápido cuesta bastante más que el doble.

Escalar horizontalmente

• Agregar servidores (1, 10, 100, 1000)

• Barato

• Depende de la red (gigabit, 10GB, Infiniband)

• Obtenemos gratis: redundancia (AD!)

• Escalabilidad NO ES alta disponibilidad

• Pero se intersecan

• Eliminar SPFs! (escalabilidad+AD+seguridad)

• LAMP básico

– Linux, Apache, MySQL, PHP (lenguaje de programación)

– ¿Escalable? • Máquina compartida para servidor web y

base de datos

– ¿Confiable? • Un solo punto de fallo (SPF)

• Base de datos dedicada – La base de datos corre en un servidor

separado

– Requerimientos • Otra máquina más administración

– ¿Escalable? • Hasta un servidor

– ¿Confiable? • DOS puntos de fallo

• Múltiples servidores web

– Beneficios • El tráfico puede crecer más allá de la capacidad de un servidor

– Requerimientos

• Más máquinas

• Configurar balanceo de cargas

– Balanceo de cargas utilizando DNS (DNS round robin)

• Registrar la lista de IPs en el DNS

• Balanceo de carga estadístico

• Los registros DNS son cacheados con TTL (Time To Live)

– Balanceo de cargas utilizando DNS (DNS round robin)

• Registrar la lista de IPs en el DNS

• Balanceo de carga estadístico

• Los registros DNS son cacheados con TTL (Time To Live) • Downtime hasta que los registros DNS se propaguen

– Balanceo de cargas utilizando DNS (DNS round robin)

– ¿Escalable? • Agregar más servidores web como sea necesario

– ¿Confiable? • No se puede redirigir tráfico rápidamente

• La base de datos aún es SPF

– Balanceo de cargas utilizando reverse proxy

– Beneficios • Ruteo flexible

• Balanceo de carga a nivel aplicación

– Requerimientos • Más máquinas

• Configuración y código para proxies

Reverse proxy

– ¿Escalable? • Agregar más servidores web

• Especialización

• Limitado por – Capacidad de ruteo del proxy

– Una base de datos

– ¿Confiable? • Ruteo rápido a nivel de aplicación

• Componentes especializados son más robustos

• Múltiples proxies requieren ruteo a nivel de red – Balanceo de carga con DNS (DNS Round Robin)

– Hardware de ruteo de red

• Base de datos sigue siendo el SPF

– Base de datos Maestro - Esclavo

– Beneficios • Mejor rendimiento de lectura

• Invisible a la aplicación

– Requerimientos • Aún más máquinas

• Cambios a MySQL

– Base de datos Maestro - Esclavo

– ¿Escalable? • Escala el ratio de lectura con el número de servidores

• Pero no la escritura

– Requerimientos • Aún más máquinas

• Cambios a MySQL

– Base de datos Maestro - Esclavo

– ¿Confiable? • Maestro es SPF para escrituras

• Maestro puede morir antes de replicarse

• Base de datos particionada

– Beneficios – Escala el rendimiento en

lectura tanto en escritura como lectura

– Requerimientos – Aún más máquinas

– Mucha administración

– Re arquitectura del modelo de datos

– Reescribir consultas

Shared nothing (SN)

• Cada nodo independiente

• Eliminar SPFs

• Storage separado

• DB separada de web

• Cache

• Sesiones

¿CLOUD COMPUTING?

Cloud computing es un nuevo modelo de prestación de servicios de negocio y tecnología, que permite al

usuario acceder a un catálogo de servicios estandarizados y responder a las necesidades de su negocio, de forma flexible y adaptativa, en caso de

demandas no previsibles o de picos de trabajo, pagando únicamente por el consumo efectuado.

Wikipedia

– Todo el trabajo de escalabilidad, alto rendimiento y alta disponibilidad esta a cargo del proveedor del servicio y totalmente abstraído del cliente – recursos abstraidos.

– Escalabilidad “instantánea”

– Capacidad de procesamiento y almacenamiento “ilimitado” - Capacidad elástica

– Software as Service

– Pago solo por lo que uso

– Dependencia de otras empresas proveedoras

– Ejemplos • Google app engine

• Amazon web services

• Azure de Microsoft

• Rackspace

¿