Download - Alto rendimiento y escalabilidad en plataformas Rails: Casos prácticos. Soluciones y trucos
Alto rendimiento y escalabilidad
en plataformas RailsFernando Blat
[email protected] Bosque
[email protected] Blanco
¿Pero esto podemos hacerlo con Rails?
YES, WE CAN!Foto: Peter Yang para Rolling Stone
¿Cómo?
Monitorización!• Logs
• Gráficas
Logs
• Repositorio común de logs (Data mining)
• syslog-ng
• Generación de Informes
• production_log_analyzer
• SlowQueries
Análisis de gráficas
• Identificación de patrones de comportamiento
• Reconocer síntomas
Crisis? What Crisis?
Reconociendo Síntomas• Carga Elevada
Reconociendo Síntomas• Elevado número de conexiones
Reconociendo Síntomas• Slow Queries
Reconociendo Síntomas• IOstat
Reconociendo Síntomas• Uso intensivo de CPU
Reconociendo Síntomas• Swap
Capa Web
• Primero fue Lightp(httpd) con FastCGI
• Luego Apache + Mongrel
• El módulo mod_proxy_balancer de apache no hace balanceo inteligente: round-robin
• Aparece HAProxy
• Entre Apache y Mongrels
• Distribuye las requests en base a las encoladas por los mongrels
Capa Web
• fair_proxy_balancer
• Se mantiene en memoria el nivel de ocupación de los backends
• Balanceo inteligente
• Alta disponibilidad entre servidores web
• Failover
Capa Web
Virtual IP
• Para aprovechar la máquina:
• Varios Dominios
• Instancias Virtuales
• Importante: Configuración del servidor web para entrega de estáticos
Capa Web
Capa de Aplicación
• Almacenamiento en red
• SAN / NAS
• S3
Compartiendo Estáticos
Caché, Caché, Caché!!!!!
Capa de Datos
Capa de Datos• Máquinas dedicadas
• Esquemas Maestro/Esclavo
• Tablas InnoDB:
• Evitar Bloqueos
• Busquedas:
• Eliminar FULL TEXT KEYS
• Indexado con Sphinx
• Importante: Ajuste parámetros de configuración
Capa de Datos• Replicación MySQL no es suficiente
• Failover manual
• Cluster MySQL
• Muy escalable, pero configuración compleja y procesos manuales
• MySQL Proxy
• Replicación DRBD + Replicación MySQL
• Configuración sencilla. Failover automático. Escalable (salvo aplicaciones con muchas consultas de escritura)
Capa de Datos
• Escalado Sencillo
• Failover Automático
• Balanceo de Consultas
Texto
Virtual IP
Esclavos
Activo Pasivo
Entonces, podemos tener alta redundancia para la base de datos?
Virtual IP
Esclavos
Activo Pasivo
Mongrel Cluster
+Mongrel Cluster
+Mongrel Cluster
+
Web
App
Datos
Infraestructura
• Memcached
• Virtualización
Memcached• Sistema de almacenamiento de objetos en
memoria de forma distribuida.
• Fundamental para escalar:
• Sesiones
• Fragmentos
• Consultas lentas
• NGINX + Memcached
Query Memcached
• almacenar resultado de una consulta a base de datos en Memcached
• cada tabla tiene un número de versión y dicha versión se añade a la query y se genera un MD5 como clave de Memcached
• expirar ese número de versión al ejecutar cualquier query que no sea un SELECT
Virtualización
• Mayor aprovechamieno de los recursos de hardware.
• Fácil migración en caso de fallo de una instancia.
• Arranque bajo demanda
• Redundancia y tolerancia a fallos hardware si la instancia se almacena en red
Amazon S3
• Servidores Europa vs USA
• MD5 en nombre de fichero o ETAG para cachear sin tiempo de expiracion.
• http://lcp.s3.amazonaws.com/blat%2Ff%2F5e3d6c54c094b0cfe15d3021dc17fe1e
Amazon EC2
• Máquinas bajo demanda
• Gestión remota con Elastic Cloud y gema Amazon EC2
EC2: evitando regenerar imágenes
• Todo está en modo RO, excepto /usr/local, que es un repositorio de GIT
• enlaces simbólicos donde haga falta
• al arrancar la máquina hace un git pull y se ejecuta un script
• una rama por feature, y merges de ramas para combinar features
Merb
• Comunicación por HTTP y claves para asegurar la autenticidad de los datos.
• No cargamos ningún modelo de ActiveRecord para evitar inconsistencias (DRY!!) y el monothreading
Rompiendo convenciones
Sistemas de colas • Evitar ralentizar la respuesta al usuario:
Importante: cuidado con observers, sweepers, envíos de email, notificaciones remotas...
• Flickr Engineers Do It Offline
• Algunos sistemas:
• Delayed Jobs
• Starling
• ActiveMQ + Ruby Stomp
Datos en memoria
• Carga anticipada de datos
• Base de datos + buffer de datos (Memcached):
• inserción de datos en memoria
• datos más frecuentes en memoria
Renderizado en segundo plano
• el renderizado es una de las tareas más pesadas, superado el cuello de la base de datos
• Erubis: implementación en C puro de ERB con algunas características interesantes: caché, preprocesado, fácil de extender, sintaxis 100% compatible, rápido
• Renderizar en segundo plano y guardar en caché
• Combinar este renderizado con la carga de datos anticipada
Paginación
• Sólo interesan los primeros resultados
• Evitamos mostrar el total exacto de páginas
• Precargamos la página actual y las N siguientes
• Cuando estamos en la N - 1 cargamos la N + 1 y las siguientes
Recursos, referencias y bla, bla ,bla...
• Erubis: http://www.kuwata-lab.com/erubis/
• Flickr Engineers Do It Offline: http://code.flickr.com/blog/2008/09/26/flickr-engineers-do-it-offline/
• Query Memcached: http://github.com/ferblape/query_memcached/tree/master
• ActiveMQ: http://activemq.apache.org/
• Stomp: http://github.com/grempe/stomp/tree/master
• New Relic: http://www.newrelic.com/
• Query Reviewer: http://code.google.com/p/query-reviewer/
• Mongrel Proctitle: http://purefiction.net/mongrel_proctitle/
• Production log analyzer: http://rails-analyzer.rubyforge.org/
• syslog-ng: http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/
• Nginx and Memcached, a 400% boost!: http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/
• MySQL Proxy: http://forge.mysql.com/wiki/MySQL_Proxy
¡Gracias!
no, en serio..¡¡Muchas gracias!!