Descubriendo los problemas de HBO Go

Esta semana fue El Segundo episodio de Game of Thrones, yo estaba decidido a dejar el cable, porque ya nunca veo tele, e irme 100% a internet gracias a la magnifica experiencia que estaba teniendo con Netflix. Hoy intenté ver El Segundo episodio en vivo y me di cuenta que no podía acceder a la aplicación, hablar de frustración es poco...

Hace unas horas decidí buscar la razón del problema y me puse a investigar, primero intentando hacer una reproducción desde el navegador y buscar el manifiesto.

Web Console

Esta dirigia a footprint.net, este es un servicio CDN de Level3, al hacer un nmap me doy cuenta que solo resuelve a un registro A en vez de un CNAME. 

Consola

Ahi comenzamos con el primer problema, asignar una carga CDN a una sola IP pública, en vez de un CNAME, hace que no contemos con un ambiente realmente distribuido, esto es una preocupación y debería ser el primer jalon de orejas para Level3. Pero HBO no quizo confiar solamente en un proveedor y también uso los servicios de Cloudflare, de tal forma que su estrategia de distribución es STATIC CloudFlare y DYNAMIC MEDIA Level3, sin embargo a la hora de la verdad ambos fallan. La pregunta es, es culpa únicamente de los CDN?

El site confia en una serie de servicios que no están manejados por el CDN sino directamente por HBO llamados hbopaseo.com

HBO

Y es ahi donde detectamos El Segundo problema, primero el nameserver del dominio hbopaseo.com usa unicast (wikipedia https://es.wikipedia.org/wiki/Unidifusión) eso significa que en caso de muchos usuarios solo un difusor soporta la carga, haciendo un sticky sessions test, vemos que ese único difusor es un servidor DNS standalone, al cambiar la url desde la vista de inspección puedo confirmar que el sitio deja de funcionar por completo, incluso cuando todo lo demás sigue en perfecto estado. El Streaming usa el servicio de Microsoft IIS 8.5 de Transmisión adaptativa, sin embargo, en la entrega el reproductor lo maneja como transmisión fragmentada, lo que hace que se cree un buffer por particiones futuras, es decir, se descarga el capitulo completo en todos los usuarios al mismo tiempo en vez de descargar solo la siguiente secuencia y así sucesivamente.

Al final todos estos son problemas de arquitectura y de una mala aplicación de la tecnología. Algunos aprendizajes para mejorar en las siguientes transmisiones:

  1. Usar la nube, HBO esta confiando 100% en sus servicios on-premises los cuales no tienen la capacidad para manejar la demanda de la serie mas exitosa de la historia, intentan mitigarlos por CDN pero el CDN no hace magia, solo nos ayuda a optimizar las rutas y el consumo total de ancho de banda, igual esto no sirve para los llamados a las APIs que se manejan por un DNS Server en unicast. Los proveedores de nube de hiperescala (Azure, AWS o GCE) siempre tendrán mejor ancho de banda del que jamás podrá tener un centro de datos privado.
  2. Cambiar registros A por CNAME, crear ambientes distribuidos de forma global con DNS distribuido usando Anycast, todo manejado por distribuidores de trafico en topología round robin arriba y un CDN Akamai con restricciones regionales para manejar las geografias permitidas.
  3. Instanciar cada grupo de viewers como containers independientes con su propia PIP generando su propio DNS Name que es destruido al finalizar la sesión esto permite que las visualizaciones se manejen de forma independiente, en casos de problemas estos afectan a grupos reducidos de personas, y se solucionan destruyendo y recreando el contenedor. Los estados de cada viewer se guardaran en un No-SQL con distribución global.
  4. Las imágenes, estilos y JS los tienen en Adobe, yo las pondría Storage account de distintas nubes, con un manejador de trafico encima y un CDN con compresión. 

Hacer transmisión en nube es perfectamente posible, pero no se trata solo de tecnología, se trata también de buenos arquitectos.

 ACLARACION 1: El servicio de CDN de Level3 si esta balanceado, la cuestión es que resuelve inmediatamente a un registro A en vez de a un CNAME, eso responde a que no usan Nested Balancers. Si comparamos con Netflix nos vamos a topar con al menos 3 CNAMES antes de obtener una PIP

ACLARACION 2: Todo este diagnóstico está basado en la información que tenemos, hay cosas a las que obviamente no podemos acceder pero los invito a sugerirlas en los comentarios.