martes, abril 14, 2009

Notas sobre la arquitectura de Facebook

martes, abril 14, 2009 por Martín


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.

comments

5 Respuestas a "Notas sobre la arquitectura de Facebook"
Alvaro Sanchez-Mariscal dijo...
11:26

La verdad es que es uno de esos proyectos en los que a cualquiera le hubiese gustado participar en la arquitectura.

Y efectivamente, tiene pinta de que contando con recursos "ilimitados", las cosas son más fáciles.


Anónimo dijo...
15:33

Apasionante. Para que luego critiquen LAMP (aunque yo por si acaso estoy aprendiendo Python ;-)

Otro estudio similar es el caso de Amazon, no menos impresionante. De lo bien que se lo montaron dijeron "pues esto que estamos usando nosotros lo alquilamos" y de ahí los AWS (sobre todo temas de BBDD):

http://www.israelviana.es/blog/Post/17/que-hay-detras-de-amazon-simpledb/

http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html


Jose Manuel Beas dijo...
16:06

Muchas gracias por compartirlo Martín.

Hay un detalle con el que no estoy del todo de acuerdo contigo. Dices que recae la escalabilidad en el hardware, pero a mi me parece que hay varias decisiones de diseño que hacen posible la escalabilidad por hardware (que es más barata hoy día). Me refiero a decisiones como desnormalizar las bases de datos (key-values y no joins llevan a pensar que, obviamente, han desnormalizado su modelo de datos), renunciar a la consistencia de los datos en todo momento y todo lugar, la orientación a servicios (no lo dices, pero creo que es evidente)...


jcesarperez dijo...
18:47

Me ha parecido bestial. Modificaciones a nivel del kernel de Linux, uf...

Todo un detalle que además publiquen productos open-source.

Una cosa: lo de 400 mil desarrolladores es correcto? Me parece una burrada...


Martín dijo...
19:02

@Jose Manuel, no he dicho que recaiga sobre el hardware. Hay una lista de cosas separadas por comas. Lo que quería decir con eso es que es una de estas aplicaciones que escalan a base de gurus de sistemas: hackers del kernel, genios de las dbs, gurus de memcache, super-administradores de red, etc.

Lo cual es una manera fenomenal de escalar, pero diferente de lo que podría intuirse por ejemplo de la arquitectura de Linkedin (http://brigomp.blogspot.com/2007/11/notas-sobre-la-arquitectura-de-linkedin.html).

Pero por supuesto, para poder escalar así a base de sistemas, antes tiene que haber ahí una serie de personas que sepan desacoplar muy bien la aplicación para ofrecer un buen sistema de servicios, un genial sistema de plugins para permitir los cientos de miles de aplicaciones, una fenomenal arquitectura de sharding, etc.

@Julio, No sé si es una errata o no, pero es el número que está en la primera slide de la presentación.