Diciembre, 2009

El uso del Software Libreen Tuenti

Escalabilidad de grandes plataformas

Tuenti en números

Millones de usuarios72 minutos por persona y día

Tuenti en números

20.000 millones de páginas vistas cada mes+20k / segundo en pico

3 millones sólo móvil cada día+2.5 millones de fotos nuevas cada día

2.500 millones de imágenes servidas  cada día(+6 Gbps, 70k / segundo en pico)

Tuenti en números

+800 servidorespáginas <100ms, totalmente dinámicas

sin pérdida de datossistema robusto y resistente a fallos

¿Cómo lograrlo?

• Escalabilidad de sistemaso CPD, refrigeración, redes, planificación

• Escalabilidad de softwareo ¿La más difícil?

• Escalabilidad de arquitecturao Orquesta software y sistemas

• Monitorización contínuao Solucionar problemas, buscar cuellos de botella,

preveer ampliaciones

Pero ¿qué es escalabilidad?

La escalabilidad NO es velocidad

La escalabilidad NO es ni siquiera throughput

De hecho, hacemos código lento ; )

Pero ¿qué es escalabilidad?

La escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad

para extender el margen de operaciones sin perder calidad, o bien manejar el crecimiento continuo de

trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los

servicios ofrecidos (wikipedia)

Escalabilidad vertical y horizontal

• Vertical:o Mejores máquinaso No existe para crecer por encima de la ley de Moore

• Horizontal:o Más máquinaso Es complicada

¡También se busca la escalabilidad en costes!

100% Software Libre

 

Por qué Software Libre

• Conocimientoo Conocer tus herramientas al detalleo Poderlas mejorar, depurar, corregiro No reinventar la ruedao Poderlas monitorizaro Es un capital de la empresa

• Pequeñas piezas independientes, no grandes aplicaciones

• No vendor lock-in• ¡No hay alternativas!

PHP

• Espíritu de HTTP: Cada petición es independiente• Fácil de programar y evolucionar• Flexible y ampliable• Fácil de desplegar• Ligero• Velocidad aceptable

MySQL

• Rápida• Fiable• No necesitamos nada extra, prácticamente es un

almacén de bytes• No perder de vista forks como Drizzle

Memcache (y otros Key-Value)

• Proporciona cache: Básico para escalar• Rápido• Rápido• Rápido• Se puede utilizar como una capa de almacenamiento

más.

Graphics Magick

• Gran rapidez• Multicore• Múltiples formatos

eJabberd

• Fácil de extender• Protocolo estándar XMPP• Erlan, ergo escalable

IPVS y Ldirector

• Muy rápido y escalable• Direct Routing• Ldirector puede dar quebraderos de cabeza

rrdtool

• Casi un estándar para gráficas de monitorización• Rápido• Tamaño constante de la DB• Un buen gráfico sirve de alerta preventiva

Escalabilidad, paso a paso (1)

• Uno o pocos servidores para toda la aplicación

• Estructura monolítica

• Cuello de botella:lectura de base de datos

El principio

Escalabilidad, paso a paso (2)Replicación

• Arquitectura maestro / esclavo

• División de lecturas y escrituras

• Configuraciones optimizadas

• Cuello de botella:lectura de base de datos

Escalabilidad, paso a paso (3)Memcache

• Cambiamos accesos pesados a BBDD por accesos ligeros a caché

• Reducción brutal de carga en BBDD

• Una página típica tiene 0 - 5 queries, y 100+ accesos a Memcached

• Cuello de botella: Escrituras en la base de datos

Escalabilidad, paso a paso (4)Separación de datos

• División del esquema en bloques lógicos

• Un cluster por cada tipo de dato

• Más complicado de gestionar en código

• Cuello de botella: sobrecarga en un tipo de datos

Escalabilidad, paso a paso (5)Particionado de datos

• Dividir una sola tabla en trozos y ubicarlos en varios clusters

• Escalabilidad casi sin límites

• No es gratis - aumenta la cantidad de código de soporte

• Cuello de botella: volumen de datos

Escalabilidad, paso a paso (6)Archivado de datos

• Almacenar datos que se usan con menor frecuencia en soportes alternativos

• Mantiene el tamaño de las tablas principales dentro de límites manejables

• Flexibilidad a la hora de escoger el soporte alternativo

Escalabilidad, paso a paso (7)Particionado de memcache

• El particionado no se tiene que limitar a bases de datos

• Memcacheds y frontales particionados

• Mejora el rendimiento de red interna

• Esquema cruzado entre memcached y base de datos

Escalabilidad, paso a paso (8)

• Consistencia eventual• Cache como un storage más.

o Cero consultas a DBo Actualización tras cambioso Paginación en cacheo Problemas

ConsistenciaRace conditionsConcurrencia

Memcache como Storage

Escalabilidad, paso a paso (9)

• Client Side Routing

Balanceadores

Pruebas de escalabilidad

• Tremendamente difícil de probaro Pruebas sintéticaso Análisis de consultas SQL, claves de MCo Experienciao Dark launcho Desactivación parcial, ratios, reducción de

listados...

Más allá de tus servidores (1)

• Content Delivery Networkso ¡Todos utilizan software libre!o Coste "bajo"o Utilizar varios

Mover tráfico entre ellos según rendimientoSegún tipo de contenido y requisitos

o Rendimiento muy variable (cold servers, hit ratio)

Más allá de tus servidores (2)

• Aprovechar la AJAX y la web 2.0 para algo más que Marketing:o Client side routingo Client side cachingo Prefetcho Reducir BW transfiriendo sólo datos y sólo

cambioso Mediciones de rendimiento

Escalabilidad de aplicaciones web• Mover la aplicación lo más cerca posible del navegador

1.¡El javascript es lo que más escala!

 

 

Escalabilidad de aplicaciones web• Mover la aplicación lo más cerca posible del navegador

1.¡El javascript es lo que más escala! (excepto IE)• El resto a los frontales

• Menos base de datos:o Deja de ser relacionalo Un storage más

• Cache como storage layer• Más aplicación:

o Relacionar datoso Mantener consistenciao Manejar los diferentes storageo Migrar datos (somos 24/7)o No monolítica, pequeñas piezas, como el SL

gracias

http://jobs.tuenti.com