Acabo de leer en menéame sobre los datos de la arquitectura de YouTube. Voy a traducir la primera parte junto a la del servidor web que no deja de ser poco interesante, la de vídeo aunque es la más interesante al no conocer muchos términos no creo que lo tradujese apropiadamente.
La plataforma usada consiste en:
- Apache.
- Python.
- Linux (SuSe).
- MySQL.
- psyco, un compilador python->C dinámico.
- lighttpd para el vídeo en lugar de Apache.
Las estadísticas son increíbles:
- Soporta las peticiones de más de 100 millones de vídeos por día.
- Fue fundado en febrero del 2005.
- En marzo del 2006 había ya 30 millones de vídeos vistos por día.
- En julio del 2006 había 100 millones de vídeos vistos por día.
- 2 administradores de sistema, dos arquitecturas de software escalables.
- 2 desarrolladores, 2 ingenieros de redes, 1 DBA (si no me equivoco, un administrador de bases de datos).
También publican una receta para manejar el rápido crecimiento del sitio:
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}
El bucle se ejecuta varias veces al día.
Servidores web
- NetScalar es usado para balancear la carga y la cache del contenido estático.
- Apache funciona con mod_fast_cgi.
- Las peticiones son encaminadas para ser tratadas con Python por un servidor de aplicaciones.
- El servidor habla con varias bases de datos y otras fuentes de información para recoger toda la información y generar la página HTML.
- Pueden aumentar el nivel de escalabilidad web añadiendo más máquinas.
- La parte de Python habitualmente NO es el cuello de botella, pasa la mayor parte de su tiempo bloqueado en los "RPCs".
- Python permite un desarrollo rápido, flexible y "deployment". Esto resulta critico para seguir siendo competitivos.
- Normalmente los tiempos de carga de las páginas son inferiores a 100ms.
- Se usa psyco, un compilador dinámico python⇒C junto a JIT para enfocar la optimización de los bucles internos.
- Para actividades con un consumo de CPU intensivo como cifrar, se usan extensiones en C.
- Algo de HTML cacheado y previamente generado para renderizar bloques.
- Se usa poco cache en la base de datos.
- Los objetos formados en Python son cacheados.
- Parte de los datos son calculados y enviados a cada aplicación para entonces ser cacheados en su memoria local. Esto es una estrategia poco habitual. La cache más rápida está en tu servidor de aplicaciones y no le lleva mucho tiempo enviar datos precalculados a todos los servidores. Sólo hace falta un agente que vigile los cambios, precalculos y envíos.
Por último en los costes de cada servidor se incluye el precio del ancho de banda, hardware y consumo eléctrico.
Comentarios