Escalando Twitter

Una charla tomando café me ha llevado a leerme realmente el problema de escalabilidad de twitter. Ya hace tiempo que hubo mucho bombo en internet, sobre el problema. Dado que pareció entenderse que Rails no escalaba y hubo gente que se lo tomó a mal, lo normal en estos casos.

No quiero entrar en ese debate antiguo, más bien quería ver que problemas tenían, y que soluciones encontraron. Algo que me ha sorprendido bastante es el índice de Alexa presentado en las trasparencias. Si consideráis que no es fiable, no os preocupéis por eso, sólo estamos mirando e investigando, dar por hecho que lo es e imaginaros que haríais; y luego pensad si vuestras ideas son buenas soluciones.

Me ha inquietado bastante que en un par de meses el orden de magnitud se incrementase brutalmente. Vamos que se ha multiplicado por 10, aunque realmente me entra la duda de cómo interpretar la unidad que sale en el índice de la gráfica de Alexa.

Lo realmente curioso es lo que les llevó a la conclusión; realmente mejorar el modelo de datos, las querys que se lanzan, crear índices, mejorar el rendimiento en general de la aplicación, etc; bueno, son las primeras cosas que a priori se te ocurren.

Pero hay algunas anotaciones remarcables:

>> Controla tu aplicación. Cuando pones tu aplicación en un servidor para dar servicio a muchas personas, tienes que saber qué está pasando. Hay cosas tan evidentes como el número de visitas, los errores que se están produciendo, lo más visitado, etc. Hasta los tiempos empleados para acceder a determinadas opciones, cuales son los ataques que se están produciendo, el estado de tus servidores (logs, espacio en disco, servicios caidos, nodos caidos…), etc. Existen miles de cosas que tienes que administrar y otras tantas que debes controlar y ser avisado en cuanto se produzcan determinadas alertas.

>> Cachea, cachea, cachea: No conviertas tu base de datos en tu cuello de botella, e intenta cachear toda la información que puedas necesitar y vuelva a solicitarse, evitando peticiones innecesarias a tu base de datos.

Las estadísticas que existían:

# Over 350,000 users. The actual numbers are as always, very super super top secret.
# 600 requests per second.
# Average 200-300 connections per second. Spiking to 800 connections per second.
# MySQL handled 2,400 requests per second.
# 180 Rails instances. Uses Mongrel as the “web” server.
# 1 MySQL Server (one big 8 core box) and 1 slave. Slave is read only for statistics and reporting.
# 30+ processes for handling odd jobs.
# 8 Sun X4100s.
# Process a request in 200 milliseconds in Rails.
# Average time spent in the database is 50-100 milliseconds.
# Over 16 GB of memcached.

Más datos sobre otras arquitecturas en High Scalability.