Dentro de twitter: sobre como funciona su equipo de gestión de operaciones

Hace unas semanas fue la Velocity 09 y en blip.tv están disponibles los videos. ¡Vaya montón de conferencias interesantes! El otro día estuve echándole un vistazo a la de Twiter de John Adams: "Fixing Twitter: Improving the Performance and Scalability of the World's Most Popular Micro-Blogging Site"


(perdón que me cargue el blog con este video, tengo que buscar una plantilla más moderna)

Como acostumbro, he tomado unas notas porque me gusta tenerlas por aquí de referencia.

• Su equipo de operaciones está formado por 8 personas. Funcionan más como un equipo de arquitectos de sistemas que como un centro operacional a la usanza. Se encargan de controlar la escalabilidad, el rendimiento, la disponibilidad, la planificación de la capacidad, etc.


• El mantenimiento de servidores está subcontratado con NTT America, así que ellos no tratan con los servidores físicos.


• No utilizan clouds. Lo intentaron pero no es para ellos. Comentan que por ciertas razones, no les funcionó. Uno de los argumentos que esgrimen es que necesitan métricas e información muy exacta.


• Crecer es doloroso. Hay un miedo institucionalizado a cualquier cambio. Así que ellos se rigen por un Mantra común. Buscar el punto más débil y solucionarlo. Después, proceder al siguiente punto más débil.


• Un consejo. Instrumetar todo lo que podáis. Pero ojo con instrumentar demasiado, especialmente con MySQL o Memcache por ejemplo.


• Utilizan herramientas como RRDTool, Ganglia o MRTG. Con el output de estas herramientas crean cuadros de mando. Ahora mismo tienen sobre 1200 métricas. Toda la compañía tiene acceso a los cuadros de mando. También agregan métricas de fuentes externas, por ejemplo de NTT America.



• Para recoger los datos de error, utilizan Google Analytics!


• Monitorizan todos los despliegues. Así pueden correlacionar los despliegues con las estadísticas del sitio web como puede ser la latencia. De esa forma detectan cambios hechos por desarrolladores que pueden tener un fuerte impacto.


• Otro consejo, si no habéis empezado a gestionar vuestra configuración. Hacerlo ya. Vale la pena. Ellos controlan los cambios en los ficheros usando diff y SVN. Tienen hooks de pre-commit y post-commit. Para hacer un cambio siempre debe ir acompañado de un comentario que especifique quien ha aprobado ese cambio. Una vez entra en el SVN se manda un correo a una lista de revisores. Los revisores reciben en su email el diff y aprueban el cambio o no. Si todo el mundo lo aprueba, el cambio se aplica.


• Para la comunicación utilizan Campfire. Muy contentos con el.


• Para atacar los problemas en los diferentes subsistemas utilizan fichas con "planes de ataque". Estás fichas incluyen, el síntoma, cual es el cuello de botella, el vector de elementos afectados y la solución propuesta. Este es un ejemplo:



• CPU, ahora consiguen más por menos. Pasaron de AMD a Intel Xeon y consiguieron un 30% de rendimiento más. Cambiando de dual y quad core a 8 cores consiguieron otro incremento del 40%.


• Rails. Ok, ruby es lento, pero hay formas de contrarestar esto. Tuvieron muchos problemas y mucho análisis que hacer, pero casi siempre el problema era debido, no a ruby sino a otras razones. La caché y la invalidación de la caché es un problema gordo, pero es más de memcache. ActiveRecord sí que les fue un problema ya que genera queries que a veces pueden tener muy mal rendimiento, lo que hace que la base de datos vaya más lenta y que la latencia en las colas se incremente. Otros problemas fueron la corrupción de datos en Memcache y el lag en la replicación de datos.


• El disco duro es la nueva cinta. La Web 2.0 no es posible sin enormes cantidades de memoria RAM. Los gráficos sociales ocupan mucha memoria. Facebook o Twitter, ambos tienen enormes pools de instancias de memcache.


• Twitter es tiempo-real pero hacen muchísimo caching. Utilizan diferentes pools de memcache para diferentes subsistemas para así prevenir la evicción prematura de datos. Los TTL van de 20 a 60 segundos pero para los usuarios que no usan mucho twitter pueden ser mayores. La mayor parte de los timelines se pueden
cachear ya que no varían demasiado. La creación de una página genera de 100 a 300 peticiones de memcache. Han contribuido varias optimizaciones a la librería de memcache de rails. Por ejemplo, cambiaron el algoritmo hash de MD5 a FNV lo que les supuso un aumento del rendimiento de 200x 300x. Han contribuido al Open Source Cache-Money una cache read y write-through para Ruby.

• Pero hay que tener cuidado. Cachear todo no es la mejor política. Ellos han tenido problemas de datos obsoletos, corrupción de las instancias de memcache, corrupción de los hash, etc.


• Utilizan colas de mensajería para la comunicación entre los diferentes demonios. Empezaron a desarrollarlo con Erlang, y les gustó, pero necesitas programadores con experiencia en erlang :S Así que cambiaron a Scala. Crearon Kestrel una solución interna que funciona como memcache.


• Otra de sus experiencias es lo que casi todas las webs de este tamaño comentan. Las bases de datos relacionales no son la panacea. Ellos se han saltado muchas normas porque la consistencia de los datos no resulta un gran problema para el tipo de aplicación que es Twitter.


• Hacen mucho cacheo web. Especialmente en Twitter Search. Utilizan Varnish.


• Muchos problemas con Mongrel al no ser multi-threaded, ya que tanto el tráfico interno como externo consume muchos recursos en forma de instancias de Mongrel. La solución para ellos ha sido mover muchas tareas fuera del ciclo de requests para hacer éste mucho más corto y ahorrar recursos. Muchos demonios externos.


• Sobre MySQL, nada que no se haya contado. Que las bases de datos relacionales no son muy aptas para los grafos sociales. Problemas de replicación. Un buen sharding es muy importante. Matan cualquier query que esté durando demasiado tiempo. Lo utilizan como mecanismo de auto-defensa.

Y eso es más o menos todo. Quizás me haya pasado con las notas, pero me ha parecido una charla muy interesante.