Joe Stump (Digg) – Escalando Digg y otras Aplicaciones Web
Joe Stump es el Arquitecto Jefe de Digg. Recientemente dio una charla en la Web 2.0 Expo, que al parecer fue muy interesante. No hay vídeo de su presentación, pero si una serie de notas de Kris Jordan, que selecciono y traduzco en este post.30 millones de usuarios, y 13.000 peticiones por segundo. Esto implica una gran cantidad de servidores.
El problema de la Web 2.0
“La Web 2.0 es un asco (para escalar)”. La Web 1.0 era mucho más simple de manejar, ya que símplemente había que poner contenido online. En la Web 2.0, alguien tuvo la brillante idea de que el contenido lo deberían generar los usuarios, por lo que nos encontramos a una gran cantidad de usuarios generando montones de mierda. Otra cosa que odio es AJAX, que permite a los usuarios interactuar de forma más rápida con los servidores, pero también les otorga la capacidad de crear mierda todavía más rápidamente.
Escalado del código
Hacer tu código PHP un 300% más rápido no importa, no es donde se encuentra el cuello de botella. “PHP No escala” – Cal Henderson (Flickr). PHP no escala, Java no escala, Ruby no escala – los lenguajes no escalan.
Escalado como especialización
Escalar es especializarse. Según creces, las soluciones que te ofrecen no se ajustan como necesitas. Tienes que cortar tu base de datos en diferentes trozos y especializarla mucho, hacerla específica a tus necesidades. Muchas veces la gente confunde el comprar máquinas más potentes (scaling up) con escalar a base de más servidores (scaling out). Llega un punto en el que no puedes comprar máquinas más potentes, se hacen muy caras. Toca escalar a base de un montón de “cajitas”, descentralizando, esperando fallos y añadiendo todavía más cajutas. Amazon es uno de los mejores haciendo esto.
El teorema de CAP dice que solo puedes elegir 2 de estas 3 características: fuerte consistencia, alta disponibilidad y tolerancia a particionado. ¿Cuáles son mis opciones? Desnormalizar, consistencia eventual, paralelismo, asincronismo, especialización.
La desnormalización es necesaria en soluciones particionadas y esto se está convirtiendo en un gran problema para Digg. Si no estás usando colas y sistemas de mensajería necesitas mirar gearman y djabberd. Te preguntas por qué las cosas van tan lentas y te acabas dando cuenta de que estás haciendo 5 viajes síncronos a la base de datos. Tienes que hacer estas llamadas de forma asíncrona con llamadas http o con gearman.
Digg utiliza MogileFS para los iconos y fotos. Nuestro nuevo juguete favorito es MemcacheDB que “será el nuevo gran hito en temas de escalado”. Los test iniciales en un portatil llegaron a 15.000 escrituras por segundo.
Técnicas de Cacheado
Ten una cadena de responsabilidad. Nosotros tenemos un tiempo genérico para que los objetos expiren en Digg. El problema es que tenemos un montón de usuarios y muchos usuarios inactivos. Los patrones de Cadena-de-responsabilidad crean una cadena: mysql, memcache, apc, globales de PHP.
Particionado
Particiona tus datos horizontalmente (filas a-f en una máquina) y verticalmente (algunas columnas en una tabla, otras en otra). El particionado horizontal es necesario cuándo tienes muchos datos que necesitas extender en muchos servidores. El escalado vertical: en luigar de modificar tablas, añade una nueva tabla con las columnas que necesites en ella. Esto reduce el ‘downtime’. Abstrae el acceso a los datos de forma que los detalles de particionado se escondan al usuario.
En Digg tenemos problemas similares a los de Twitter: enviar un mensaje a un montón de destinatarios. Kevin Rose tiene 40.000 followers, ni puedes enviar algo a 40.000 personas de forma síncrona. Tenemos de 300.000 a 320.000 diggs cada día, si una persona tiene de media a 100 followers, eso significa 300.000.000 diggs por día.