Notas sobre la arquitectura de Facebook

Hace ya unos cuantos días que publicaron en InfoQ una presentación muy interesante sobre la arquitetura de Facebook. Es de esas presentaciones que te enganchan porque está claro que Facebook es la aplicación de moda, así que te quedas mirando para el video con cara de bobo y pensando "ooooh, así que lo hacen así".

He aprovechado para tomar unas notas que comparto con vosotros por aquí:

General

• De vértigo: Mas de 120 millones de usuarios activos, más de 50 mil millones de páginas vistas por mes, más de 10 mil millones de fotos, más de 50 mil aplicaciones de terceros, más de 400 mil desarrolladores, más de mil millones de conexiones.


• Plataforma basada en LAMP. PHP, Memcache y MySQL. Para el resto de servicios que no encajan dentro de este stack crean componentes en diferentes lenguajes. Tienen por ejemplo servicios escritos en C++, Java, erlang, python, ...


• Utilizan PHP básicamente porque es con lo que se empezó y porque es un lenguaje pensado para la web. Pero han tenido muchos problemas con él. Es un lenguaje complicado, dificil de extender, del que incluso los desarrolladores más experimentados escapan. Especialmente molestas les han sido su weak typing que hace difícil el comprender el código y la dificultad de hacer análisis estático.


• Han tenido que mejorar tanto PHP, como memcache buscando escalabilidad. También han hecho mejoras en MySQL

MySQL

• ¿Por qué? Porque es realmente rápido. Lo usan principalmente como un almacenamiento de key-value.


• 500 nodos físicos en cada centro de datos. Distribuyen bases de datos a lo largo de estos nodos. Los datos se distribuyen a lo largo de las bases de datos logicas.


• Utilizan también datawarehousing y periódicamente vuelcan datos a estos sistemas.


• No se hace ninguna join en producción


• La mayor parte del acceso de datos en Facebook es a datos recientes, asi que archivan los datos viejos.


• No han hecho demasiados cambios en MySQL. Un sistema para obtener el id de cualquier elemento (Facebook id -> database id) y la base de datos donde éste se encuentra + un sistema para mejorar el archivado. Han trabajado en resolver las insonsistencia entre las cachés cuando éstas están en diferentes centro de datos (problema habitual de replicación master-slave), etc. Es decir, librerías para facilitar el uso de MySQL.


• Tienen una base de datos con el grafo de contactos. El grafo está distribuido, pero los datos similares (e.g. tú perfil y el de tus amigos) esta collocated.
  
• De empezar de nuevo, seguirían con MySQL. Es una base de datos rápida que les permitió escalar desde el principio.


• No utilizan transacciones distribuidas ya que la consistencia de los datos no es una gran preocupación. De hecho, la mayor parte de los casos de uso no requieren ningún tipo de consistencia.

Memcache

• 25Tb !!


• Latencia media < 200 microsegundos.


• Utilizan multi-gets para obtener múltiples datos cacheados (e.g. fotos) en paralelo.


• Han hecho ligeras mejoras. Memcache sobre UDP ya que originalmente trabajaba sobre TCP que guardaba buffers y consumía demasiada memoria.


• Han modificado también el kernel de Linux para que se comporte mejor con Memcache (e.g. las interrupciones de red originalmente son tratadas sólo por un único core). No creen que la comunidad acepte sus modificaciones. Hack!!! :)

Más notas

• Tienen frameworks de unit tests, y regression test. Pero esto entro un poco mas tarde asi que la cobertura no es tan buena como desearian.


• Algunos límites, como el del número de amigos que se puede tener, están ahí para mejorar la escalabilidad.


• LAMP no es perfecto. En Facebook se pueden crear servicios en muchos lenguajes diferentes. La norma es simple: escoge el mejor lenguaje para la tarea.


• Intentaron migrar el código base a Python un par de veces pero sin éxito.


• Crearon y liberaron Thrift para la creación de servicios en diferentes lenguajes. El rendimiento es mucho mejor que el de otras alternativas como SOAP, CORBA, etc.


• También han liberado el gestor de logs Scribe

Y eso es más o menos todo. Mi impresión después de ver la presentación y conocer más a fondo la arquitectura de Facebook es que Facebook ha sido creado por un grupo de personas con grandes conocimientos de sistemas, no tan preocupados por el software en si mismo. Parece claro que el peso de la escalabilidad recae sobre el hardware, la base de datos, el kernel de Linux, la red, sistemas de redundancia y demás, en lugar de en el lenguaje o la plataforma en si misma.

¿Es esto bueno? Pues no se puede decir que les haya ido mal, ¿no? Aunque las organizaciones en las que estamos el resto de mortales, no tengo yo tan claro que se puedan permitir escalar a base de parches en MySQL, PHP, etc., y servidores a mansalva.

Super-interesante la presentación.