Software Libre Y Escalabilidad
- 2. El uso del Software Libre en Tuenti Escalabilidad de grandes plataformas
- 3. Tuenti en números Millones de usuarios 72 minutos por persona y día
- 4. 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)
- 5. Tuenti en números +800 servidores páginas <100ms, totalmente dinámicas sin pérdida de datos sistema robusto y resistente a fallos
- 6. ¿Cómo lograrlo? Escalabilidad de sistemas CPD, refrigeración, redes, planificación Escalabilidad de software ¿La más difícil? Escalabilidad de arquitectura Orquesta software y sistemas Monitorización contínua Solucionar problemas, buscar cuellos de botella, preveer ampliaciones
- 7. Pero ¿qué es escalabilidad? La escalabilidad NO es velocidad La escalabilidad NO es ni siquiera throughput De hecho, hacemos código lento ; )
- 8. 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)
- 9. Escalabilidad vertical y horizontal Vertical: Mejores máquinas No existe para crecer por encima de la ley de Moore Horizontal: Más máquinas Es complicada ¡También se busca la escalabilidad en costes!
- 11. Por qué Software Libre Conocimiento Conocer tus herramientas al detalle Poderlas mejorar, depurar, corregir No reinventar la rueda Poderlas monitorizar Es un capital de la empresa Pequeñas piezas independientes, no grandes aplicaciones No vendor lock-in ¡No hay alternativas!
- 12. 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
- 13. MySQL Rápida Fiable No necesitamos nada extra, prácticamente es un almacén de bytes No perder de vista forks como Drizzle
- 14. 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.
- 15. Graphics Magick Gran rapidez Multicore Múltiples formatos
- 16. eJabberd Fácil de extender Protocolo estándar XMPP Erlan, ergo escalable
- 17. IPVS y Ldirector Muy rápido y escalable Direct Routing Ldirector puede dar quebraderos de cabeza
- 18. 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
- 19. Escalabilidad, paso a paso (1) El principio Uno o pocos servidores para toda la aplicación Estructura monolítica Cuello de botella: lectura de base de datos
- 20. 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
- 21. 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
- 22. 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
- 23. 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
- 24. 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
- 25. 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
- 26. Escalabilidad, paso a paso (8) Consistencia eventual Cache como un storage más. Cero consultas a DB Actualización tras cambios Paginación en cache Problemas Consistencia Race conditions Concurrencia Memcache como Storage
- 27. Escalabilidad, paso a paso (9) Client Side Routing Balanceadores
- 28. Pruebas de escalabilidad Tremendamente difícil de probar Pruebas sintéticas Análisis de consultas SQL, claves de MC Experiencia Dark launch Desactivación parcial, ratios, reducción de listados...
- 29. Más allá de tus servidores (1) Content Delivery Networks ¡Todos utilizan software libre! Coste "bajo" Utilizar varios Mover tráfico entre ellos según rendimiento Según tipo de contenido y requisitos Rendimiento muy variable (cold servers, hit ratio)
- 30. Más allá de tus servidores (2) Aprovechar la AJAX y la web 2.0 para algo más que Marketing: Client side routing Client side caching Prefetch Reducir BW transfiriendo sólo datos y sólo cambios Mediciones de rendimiento
- 31. Escalabilidad de aplicaciones web Mover la aplicación lo más cerca posible del navegador ¡El javascript es lo que más escala!
- 33. Escalabilidad de aplicaciones web Mover la aplicación lo más cerca posible del navegador ¡El javascript es lo que más escala! (excepto IE) El resto a los frontales Menos base de datos: Deja de ser relacional Un storage más Cache como storage layer Más aplicación: Relacionar datos Mantener consistencia Manejar los diferentes storage Migrar datos (somos 24/7) No monolítica, pequeñas piezas, como el SL