La multitud Flash y su transmisión en vivo
A medida que los servicios de streaming luchan por un número limitado de espectadores y disminuyen la capacidad de atención, los eventos en vivo, que son un factor probado de participación de la audiencia, se han convertido en un factor importante en la estrategia de contenido de un editor. Sin embargo, por mucho que la transmisión en vivo pueda entregar audiencias de manera confiable, la transmisión confiable de eventos en vivo a escala viene con una serie de desafíos. Las redes de distribución de contenido (CDN) pueden ayudar a proporcionar escalabilidad bajo demanda; sin embargo, incluso las CDN deben optimizarse para la transmisión en vivo. Tal vez el desafío más obvio de transmisión en vivo es la “multitud flash”, este fenómeno ocurre cuando muchos espectadores entran en una transmisión en vivo a la vez, hambrientos de tomar el inicio o la acción de horas extras. Siguiendo el comportamiento típico de la audiencia que hemos observado al transmitir más de 100.000 eventos deportivos, durante el sexto partido de la final de la NBA, la audiencia creció rápidamente de casi nada a la espera de un máximo de 2,04 millones de espectadores en el tercer trimestre. La audiencia saltó de menos de 10.000 sesiones a más de 1 millón en la primera hora y otros 1,5 millones después del medio tiempo, a veces sumando más de 100.000 nuevos espectadores por minuto. Este tipo de escala rápida ejerce presión sobre cualquier CDN. Pero entregar video en vivo es aún más desafiante. Cualquier interrupción puede conducir a una interrupción en la reproducción.
Como ilustra este ejemplo de un evento en vivo reciente en nuestra red, el fenómeno de “multitud flash” hace que servir video a través de una CDN sea más difícil que servir bytes de contenido regulares.
En este artículo, echamos un vistazo a las multitudes de flash y otros desafíos y luego exploramos cómo Verizon Media aprovecha sus muchos años de experiencia en el espacio CDN para resolver algunos de los problemas comunes para nuestros clientes, convirtiéndola en la elección correcta para ofrecer eventos en vivo de alta calidad, ya sean deportes, conciertos, política… o tal vez el primer aterrizaje en Marte.
Por qué el almacenamiento en caché de Live Stream es diferente
La entrega de eventos en vivo a través de Internet implica el uso de uno o más formatos de transmisión ABR (tasa de bits adaptativa), como MPEG-DASH, Apple HLS, Adobe HDS y Microsoft Smooth Streaming. Normalmente se basa en servidores web HTTP estándar como orígenes y CDN para distribuir el contenido a escala.
Nuestra gran CDN global en Verizon Media, ahora Edgio, tiene muchos POP y más de 250 Tbps de capacidad, por lo que podemos escalar fácilmente para manejar grandes picos de tráfico y multitudes flash. Sin embargo, la capacidad y la escala son solo una parte de la ecuación. Lo que es especialmente importante en la transmisión en vivo es lo bien que la CDN puede interactuar con el servidor de origen y los clientes mientras se escala para grandes audiencias de visualización que vienen a la vez.
El perfil de tráfico en vivo es único y claramente diferente de cualquier otra cosa, incluso del VOD, porque durante los eventos en vivo, el codificador publica continuamente nuevos segmentos de medios (duración típica es de 2-10 segundos) en el servidor de origen, y la CDN siempre está obteniendo ese contenido recién lanzado y propagándolo a través de la red. Este proceso toma una cantidad de tiempo distinta a cero; por lo tanto, no se puede evitar cierta latencia. Sin embargo, es crucial que la CDN sea extremadamente eficiente e inteligente para llenar la caché y manejar las solicitudes de los clientes durante y, aún más importante, antes de iniciar el proceso de llenado de caché. Idealmente, la CDN debería ser capaz de mantener la carga en el servidor de origen a un mínimo absoluto, evitando agregar demasiada latencia adicional a toda la canalización de medios. Esto garantiza que los usuarios finales del lado del cliente disfruten de una reproducción fluida y continua.
Nuestra CDN tiene una amplia gama de características que nos permiten maximizar la descarga de origen y mejorar la experiencia del usuario final antes, durante y después de que se complete un proceso de llenado de caché.
Live Stream Cache optimizaciones
Como se muestra en el gráfico a continuación, nuestra plataforma de medios emplea una serie de optimizaciones ajustables para lograr una entrega rápida y confiable para la transmisión en vivo. En las siguientes secciones, explicaremos por qué son importantes y cómo funcionan.
Escudo de origen
En primer lugar, Origin Shield es una capa de almacenamiento en caché adicional entre los servidores CDN edge y el origen. Creamos un origen virtual en uno de los POP que, a su vez, gestiona todas las solicitudes de todas las demás ubicaciones POP. Cuando un servidor de borde CDN recibe una solicitud de un usuario y no puede satisfacer la solicitud de la caché, el servidor de borde obtiene el objeto del pop de escudo en lugar de extraer directamente del origen del cliente. Como CDN global, ofrecemos a los clientes la opción de asignar un solo POP como escudo o un SHIELD POP por región (EE.UU., UE, Asia, etc.).
Origin Shield nos ayuda a proteger el servidor de origen en caso de grandes picos de tráfico y multitudes flash. Sin embargo, puede que no sea suficiente para lidiar con el perfil de tráfico único de la transmisión en vivo.
Uso compartido parcial de caché
En la transmisión en vivo, un patrón típico es que varios clientes soliciten un segmento de la transmisión que aún no está en la caché. Hay un par de maneras en que una CDN puede hacer frente a estas solicitudes. En primer lugar, puede enviar múltiples solicitudes de llenado de caché simultáneas al origen (una por cada solicitud de cliente nuevo), lo que ayuda a minimizar la latencia y optimizar la experiencia del usuario final. Una segunda opción es enviar una sola solicitud de relleno de caché que atienda al primer cliente sin demora, pero que mantenga a los demás esperando hasta que el archivo completo se cargue en la caché (este método tiene como objetivo minimizar la carga en el origen).
Desafortunadamente, ninguna de estas opciones representa una solución particularmente excelente.
En su lugar, nuestro enfoque logra un equilibrio entre estas dos opciones al permitir que un solo relleno de caché ya en vuelo se comparta entre varios clientes que solicitan la misma pieza de contenido ya parcialmente en la caché. El uso compartido parcial de caché permite a otros clientes aprovechar un relleno de caché preexistente, por lo que el contenido de video puede entregarse a varios clientes simultáneamente tan pronto como comience a cargarse en la caché. El resultado: Tiempos de arranque más rápidos, menor latencia y menor carga de origen.
Tiempo de espera de relleno de caché
Hay un intervalo entre cuando el cliente solicita el archivo de vídeo y cuando comienza a cargarse en el POP de CDN. Este punto en el tiempo es muy pequeño (puede suceder en solo unos pocos milisegundos), pero la multitud de flash de streaming en vivo lo convierte en un desafío muy significativo porque podría estar compuesto por cientos o incluso miles de solicitudes. En este caso, la función de uso compartido de caché parcial descrita anteriormente no habría comenzado todavía. Por lo general, esto se considera un caso de esquina, pero es más probable que ocurra con la transmisión en vivo debido a las multitudes flash. En este momento crítico en el tiempo, la CDN podría abrumar el origen al pasar demasiadas solicitudes a la vez.
Varias solicitudes para el mismo archivo se agrupan para evitar este problema, y solo se realiza una sola solicitud al origen. El tiempo de espera de relleno de caché es una sala de espera virtual para mejorar la descarga de origen y hacer frente a multitudes flash. Cuando llegan los encabezados de respuesta HTTP para la solicitud única y esa solicitud comienza a recibir el archivo desde el origen, la caché se puede compartir con todos los usuarios agrupados en espera. El “tiempo de espera” real (milisegundos) es altamente configurable y se puede ajustar en función de las capacidades de origen específicas y las necesidades del cliente.
Spawn Sub-petición para Miss
Cuando varios usuarios solicitan el mismo contenido no almacenado en caché, como se mencionó anteriormente, existe el riesgo de que el primer cliente esté en un dispositivo lento, como un teléfono inteligente con una conexión 3G. Esto perjudica a todos los demás clientes porque una caché normalmente se llena a la velocidad a la que el cliente puede absorber el contenido. Para evitar este escenario, podemos desacoplar nuestro relleno de caché del primer cliente potencialmente lento/fallido y rellenar del origen más rápido (a nuestra velocidad máxima). Esta capacidad también es más confiable porque ahora el relleno de caché continúa incluso si el cliente inicial se desconecta o si algo hace que la conexión se caiga. Describimos este comportamiento como Spawn Sub-Request para Miss. Esta característica también activa un relleno de caché para todo el contenido, satisfaciendo diferentes solicitudes de rango de bytes con solo un viaje al servidor de origen. El tiempo de espera para Miss y el relleno de caché se complementan entre sí en su uso, trabajando juntos para acelerar la transmisión en vivo y mejorar métricas como el tiempo de inicio y el rebúfer del vídeo.
Otras optimizaciones de CDN de Live Streaming
Archivado en caliente
A medida que la audiencia de una transmisión en vivo se expande rápidamente, los servidores de caché que anteriormente manejaban fácilmente la carga a 500K espectadores de repente se ven abrumados cuando la audiencia se triplica o cuadruplica en pocos minutos. Además, los espectadores pueden concentrarse alrededor de un área geográfica específica, típicamente para un evento deportivo o político popular. Para muchas transmisiones deportivas en vivo o campeonatos, es probable que la concentración de espectadores sea significativamente mayor en los mercados que rodean a los equipos participantes.
Cuando esto sucede, los segmentos de transmisión en vivo deben replicarse rápidamente a otros servidores dentro de los POP afectados para ayudar a distribuir la carga.
Hot Filing es el proceso de detectar y replicar automáticamente contenido extremadamente popular, como segmentos de transmisión en vivo, a múltiples servidores de caché en un POP para manejar una gran demanda. Esta es una práctica común entre las redes de distribución de contenido, pero la velocidad a la que estas propagaciones pueden ocurrir en última instancia importa. Esta es un área de enfoque continuo para Edgio. Recientemente hemos reducido nuestra velocidad de replicación de 5 segundos a aproximadamente 1–2 segundos. Además de las transmisiones en vivo, también podemos hacer que otros contenidos sean calientes, como anuncios, dentro de una transmisión en vivo.
Capacidad y ancho de banda
La capacidad y el ancho de banda se refieren a la capacidad adicional en tap para satisfacer las demandas impredecibles de las transmisiones en vivo. Así como no hay sustituto para pulgadas cúbicas para los coches musculares, no hay sustituto para el ancho de banda con CDN. Poner en juego estas y otras estrategias de optimización de caché requiere que la red tenga la capacidad y el ancho de banda para manejar la transmisión en vivo a gran escala mientras equilibra la carga que otros usuarios colocan en ella.
Actualmente, más del 80% del contenido de nuestra red es video, con una buena parte de ese tráfico dedicado a transmisiones en vivo. Hemos entregado más de 125.000 eventos en vivo gestionados en nuestra red. Y a medida que la calidad del contenido continúa mejorando junto con la creciente popularidad de las transmisiones en vivo, estamos en camino de alcanzar los 100 Tbps de capacidad de red para finales de 2019. Nuestra red cuenta con más de 140 POP globales y 5.000 interconexiones o conexiones de última milla.
Todo trabajando juntos
Las fuertes demandas de streaming en vivo llevarán tu tecnología al límite. Entregar un flujo fluido a miles o incluso millones requiere configuraciones especiales de almacenamiento en caché. La combinación de Origin Shield, Partial Cache Sharing, Cache Fill Wait Time, Spawn Sub Request for Miss y Hot Filing son potentes características que se pueden adaptar a su infraestructura y demandas únicas de transmisión en vivo. Permiten que nuestra CDN ofrezca el mejor rendimiento posible para eventos de transmisión en vivo, independientemente de si el objeto ya está en la caché, o solo está parcialmente en la caché, o el relleno de la caché aún no se ha iniciado y aún está pendiente, e incluso en la situación en que la solicitud es realmente la primera solicitud del cliente para un contenido único.
La CDN es un componente esencial en la infraestructura de video en vivo. Su sistema de servidor distribuido ofrece contenido a sus usuarios, ya que considera tanto las ubicaciones geográficas como de red y el origen en sí para entregar contenido de la manera más rápida y confiable posible. Sin embargo, las técnicas para optimizar la CDN para la entrega en vivo difieren considerablemente de otras aplicaciones que también se benefician de una CDN, incluido el vídeo bajo demanda (VOD). Con las optimizaciones de caché correctas y un montón de espacio, la CDN está más que a la altura de hacer frente a las fluctuaciones y variabilidad inherentes a la transmisión en vivo.
Nuestra CDN ofrece capacidades y optimizaciones de distribución de contenido maduras y bien probadas que minimizan la carga en el servidor de origen al tiempo que entregan transmisiones en vivo a los espectadores a escala. Nuestras optimizaciones de almacenamiento en caché de video en vivo, muchas de las cuales son ajustables para clientes individuales, trabajan juntas para proteger las demandas de los espectadores de abrumar su infraestructura de video.
