La arquitectura de Youtube
Publicado el Martes 07 de Agosto del 2007 @ 16:13 por Armonth.
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 es para nada 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.
4 Comentarios (feed)
-
kuratowsky nos comenta:
La traducción de “deployment” podria ser deplegar.
Saludos
-
Andrew Mitnik nos comenta:
no se me hace nada extraño que google youtube use python, siendo que el creador del lenguaje trabaja en sus filas
Eso sí, muy rápido lenguaje, mucho mejor a mi gusto que PHP. Aunque mucho más difícil, eso sí.
-
Felipe Alfaro Solana nos comenta:
No es NetScalar sino NetScaler (sí, ya sé que la noticia original dice NetScaler).
Los NetScaler no hacen caché de contenido. No son máquinas con tanta capacidad de almacenamiento ni mucho menos: http://www.layer7solutions.com/
Algunas de las características más interesantes de los NetScaler son el DSR o Direct Server Return. Simplificando, se podría decir que es el equivalente a NAT a nivel 2 (MAC) y resulta francamente interesante para aplicaciones muy asimétricas en las que la petición HTTP es muy pequeña y la respuesta muy grande (por ejemplo, descarga de un vídeo).
-
brian nos comenta:
Una buena traducción para deployment es “distribuible”.
