Download - Software Libre Y Escalabilidad
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