Llevo tiempo con ganas de hablar sobre la arquitectura de los principales portales de video por Internet, existen grandes diferencias entre lo que se conoce como VOD (Video bajo demanda) y LIVE (video en directo). El video bajo demanda es como una gran cola en un cine, da servicio en función del número de taquilleras que tiene, esto es lo que hace por ejemplo YouTube a quien dedicaremos un post muy pronto.

Otras empresas como Netfix o Justin.tv tienen una papeleta mucho más difícil, el video en directo obliga a tener una latencia <250 milisegundos, por lo que si en algún momento te quedas sin ancho de banda porque por ejemplo entran muchos usuarios de golpe, TODOS los usuarios notarán un glich o salto en el video. Esto es un #epicFail de manual, por eso tienen que ser capaces de estar siempre por delante de las necesidades de: ancho de banda y procesamiento de sus clientes, lo que obliga a sobredimensionar y buscarse arquitecturas capaces de escalar en momentos críticos sin interrumpir el servicio.

Hoy empezaremos por JustinTV, empiezo por ella porque ofrece tanto video en directo como grabado. Justin se está centrando en de forma muy inteligente en los nichos de deportes y videojuegos, lo que está disparando su popularidad. Este post es una libre traducción donde he metido la tijera en varios párrafos, como siempre si quieres saber más, tienes la fuente al final.

El futuro es tiempo real, es directo… al menos eso dicen. Poco a poco se está convirtiendo en una realidad. Las búsquedas en google, los tweets, la realidad aumentada, los eventos, todo está disponible de forma inmediata en nuestras pantallas. Uno de los mayores retos para la inmediatez es el video en directo, imagina los recursos necesarios para ofrecer video en directo, Tod Hoff entrevistó a uno de los fundadores de JustinTV para averiguarlo.

El post tiene casi un año y medio por lo que seguramente las cifras sean superiores, pero en marzo de 2010 tenían 30 millones de usuarios únicos al mes, subían 30 horas de video/minuto. 7 Horas más que Youtube, una locura. Era una aproximación completamente diferente mientras que YouTube procesaba y almacenaba el video, Justin no podía permitirse saltos o una conexión inestable. Quizás el mejor ejemplo de esto es Google, antes eran “un poco vagos” y actualizaban sus índices cada mes. Esto es un modelo “batch”, requiere gran capacidad de entrada/salida pero no necesariamente una baja latencia. Pero como dice Dylan los tiempos han cambiado, ahora Google utiliza Caffeine y se actualiza continuamente, deben soportar la avalancha de usuarios que utilizan sus aplicaciones como Gmail, donde la latencia importa. Bienvenidos a los problemas :D

La Plataforma

  • Twice: un sistema de caché web
  • XFS: sistema de archivos
  • HAProxy: software de balanceo de carga
  • LVS y Idirecord: para alta disponibilidad
  • Ruby on Rails: servidor de aplicaciones
  • Nginx: Servidor web
  • PostgreSQL: base de datos de usuarios y otros metadatos
  • MongoDB: base de datos para herramientas de análisis interno
  • MemcachedDB: para manejar datos que se sobreescriben muchas veces como el contador de visualizaciones
  • Syslog-ng: servicio de logs
  • RabitMQ: Tareas del sistema (crones?)
  • Puppet: distribución de linux para construir servidores
  • Wowza: servidor de streaming + un montón de módulos escritos en Java
  • Usher: servidor para reproducir el video con la lógica del negocio
  • Amazon S3: para almacenar las imágenes thumbnails

Las cifras

  • 4 datacenters en USA
  • Más de 2000 conexiones entrantes simultáneas
  • Recibe más de 30 horas de video nuevas por minuto
  • 30 millones de usuarios únicos al mes
  • La media de tráfico son 45Gb/sg. Picos de 110Gbps con un máximo de 500Gps
  • Más de 200 servidores de video con equipos de consumo. Cada uno capaz de enviar 1Gbps.
  • 100TB de almacenamiento por semana
  • Delay menor de <250 milisegundos para permitir conversación e interacción en tiempo real

Las claves

  1. ¿Por qué el video en directo es tan difícil? Parece que todo lo que necesitas es un montón de ancho de banda, lo cargas todo en memoria y lo distribuyes. Simple. Pues va a ser que no porque:
    • El video no puede dar tirones ni cargar. Youtube puede ofrecer 10Gb de video por una salida de 8Gb. Esto funciona porque tienen buffer, pero si excedes tu ancho de banda con LIVE video incluso en una fracción de segundo, TODOS tus usuarios verán la carga del buffer a la vez. Lo que te obliga a sobredimensionar como ya decíamos al principio.
    • Si sobrepasas las capacidades del CDN dejará de funcionar, Usher maneja las peticiones de entrada para calcular los recursos.
  2. Usher fue creado para gestionar el balanceo de carga, autentificación y otras funciones cuando vas a ver un video. El mayor problema es la distribución cuando muchos usuarios quieren ver el mismo video. Usher se encarga de calcular cuantos servidores son necesarios para retransmitir cada stream para que el servicio sea óptimo, duplicando en tiempo real el video para que pueda emitirse desde otro datacenter en función de:
    • La carga del datacenter
    • La carga de cada uno de los servidores
    • Optimización por latencia
    • La lista de los servidores donde el video está disponible
    • Tu dirección IP, para conocer tu IP y saber si hay algún servidor disponible con tu ISP
  3. Cada servidor puede “hacer push o empujar” el video que se está subiendo en directo o emitir un video grabado, esto permite añadir nodos nuevos o aumentar la infraestructura de forma automatizada.
  4. Multicast: la mayoría de los ISPs lo tienen bloqueado a la hora de descargar, Justin probó distintas soluciones de forma local pero tampoco hubo un ahorro significativo de los costes, piensa que cada video suele seguir el principio del long tail.
  5. Empezaron con AWS, luego Akamai y han terminado en sus propios datacenters: AWS es caro y la red era demasiado lenta para sus necesidades. El video en directo requiere muchos recursos, donde la velocidad y una baja latencia son puntos claves. Con AWS no tienes control sobre esos factores, los costes de la nube se volvían insalvables al final. En 2009 hicieron cuentas, el coste en CDN por usuario era 0.135$, en AWS 0.0074$ mientras que si montaban su propio datacenter bajaba a 0.017$. La solución estaba clara.

En próximos post seguiremos aprendiendo más sobre su arquitectura y sobre la de otras empresas como Youtube.
Fuente original



    También te puede interesar:

    This is some text prior to the author information. You can change this text from the admin section of WP-Gravatar  I´m a spanish entrepreneur focused in cloud computing and video surveillance sollutions, presently working on www.vidium.es