alto rendimiento y escalabilidad en plataformas rails: casos prácticos. soluciones y trucos

Alto rendimiento y escalabilidad

en plataformas RailsFernando Blat

blat@lacoctelera.comLuis Bosque

luis.bosque@the-cocktail.comDaniel Blanco

daniel.blanco@the-cocktail.com

¿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!!

¿Quieres trabajar en The Cocktail?

Envíanos tu C.V. a info@the-cocktail.com

http://www.the-cocktail.com