in desarrollo web

Notas sobre el taller de Last.fm en el FOWA 2007

Algunas notas desordenadas tomadas el pasado jueves en el taller de Last.fm en el Future Of Web Apps de Londres. Fue un taller de tres horas el tercer día de la conferencia, titulado Scalable LAMP Development for Growing Web Apps. El taller corrió a cargo de Matt Ogle, coordinador del equipo de desarrollo de Last.fm.

  • Su servidor de BD es MySQL y la máquina donde está el maestro tiene actualmente 16 procesadores. Usan InnoDB (no dio detalles pero también, como muchos otros, odia InnoDB). Aunque dijeron que hablarían del tamaño de la BD y el esquema de replicación, al final no lo hicieron (a ver si localizo a Matt para preguntarle estas y otras cosillas).
  • Utilizan TRAC como gestor de proyecto, donde se integra el Subversion, gestión de incidencias y peticiones, etc. Además han hecho un bot de IRC que actualiza un canal de IRC interno con los commits del subversion, las actualizaciones/nuevos tickets, el despliegue de cambios en los servidores en producción y otros indicadores sobre el estado de la plataforma. También lo utilizan para pedirse las cosas unos a otros. Es lo que llaman “osmotic communication”: que toda la empresa esté al loro de lo que pasa en los diferentes rincones.
  • A raiz del interés demostrado por la gente en este bot, lo han liberado.
  • En linea con esto, utilizan metodología SCRUM para el desarrollo: basicamente consiste en iteraciones constantes con sprints relativamente cortos en vez de la planificación de grandes releases. Es decir, en vez de planear cambios radicales que duran meses planean sacar pocas funcionalidades cada dos o tres semanas. Esto lo han adoptado después de sufrir en sus propias carnes lo primero: sacar una release que se retrasa primero una semana, luego un mes, luego se sigue retrasando…
  • Otro punto interesante de esto del SCRUM es la aproximación al trabajo en equipo y las reuniones: se plantea una reunión diaria muy corta, donde se plantea a cada desarrollador tres preguntas: ¿Qué has hecho desde la última reunión SCRUM? ¿Tienes algún obstáculo? ¿Qué harás antes de la próxima reunión SCRUM?
  • People Trump Process. Hay que conseguir que el proceso no estorbe, que las cosas fluyan.
  • Utilizan Perlbal para balancear. Con un servidor con Perlbal son capaces de servir más de 4.000 peticiones/segundo hacia 25 servidores web. Diskless netboot webservers: Los servidores web no tienen la aplicación instalada en el disco duro, sino que la aplicación se despliega a memoria a través de la red (no me quedó muy claro si todo el SO está en memoria -ni siquiera si algo así es posible-). Perlbal permite modificar su configuración en caliente: puedes añadir y quitar nodos sin tener que rearrancar.
  • Utilizan Memcached y lo tienen clusterizado en todos los servidores web, de modo que tienen una Memcache de 25 GB. Su hit ratio es de más del 90%. Es decir, 9 de cada 10 consultas a la BD están en caché, y a la BD solo le llega una de cada diez. Si se añaden más máquinas al cluster de Memcache se invalida la caché, por lo que se sufre un poco hasta que vuelve a estar en caché lo más pedido. Dicen que están trabajando en una modificación para permitir el añadir máquinas sin que se invalide la caché, aunque va lento.
  • Utilizan Lighttpd para servir estáticos (imágenes del site, hojas de estilo). Y MogileFS (un sistema de ficheros distribuido y redundado) para los avatares, las portadas de discos, etc.
  • Compilan los diferentes archivos de CSS y de JS de forma automática en uno de cada para reducir el número de peticiones al servidor web y mejorar la velocidad.
  • Utilizan Rhino para comprobar errores de forma automática en el JS y comprimirlo (es Java).
  • Para monitorización Ganglia y Nagios.
  • Utilizan Hadoop (que implementa el paradigma map/reduce -the application is divided into many small fragments of work, each of which may be executed or reexecuted on any node in the cluster-) para procesar de forma distribuida y paralalela grandes cantidades de información. El ejemplo que puso fue el procesamiento de las listas semanales de los usuarios; antes de Hadoop el proceso tardaba 24 horas y con Hadoop solo 45 minutos.
  • En los primeros días de la compañía, el CEO hacía la comida para todo el mundo (hasta que fueron demasiados).

Dos conclusiones:

  • Brad Fitzpatrick de LiveJournal es el creador (y liberador!) de Memcached, Mogile y Perlbal. Se merece una posición privilegiada en el cielo de los desarrolladores web (y eso que nosotros solo utilizamos el Memcached).
  • Hay un montón de similitudes entre la forma de trabajar de Last.fm (una aplicación web graaande) y la nuestra, que estamos desarrollando una aplicación web mucho más pequeña pero que está creciendo mucho. Eso indica que estamos en el buen camino, supongo (aunque en el momento de escribir este post el site está caído…).