Home Artículos técnicos Optimización de la CDN para Live Streaming
Applications

Optimización de la CDN para Live Streaming

About The Author

Outline

El Flash Crowd y tu Live Stream

A medida que los servicios de streaming luchan por un número limitado de espectadores y disminuyen los intervalos de atención, los eventos en vivo, que son un motor comprobado de la 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 ofrecer audiencias de manera confiable, la transmisión confiable de eventos en vivo a escala viene con un conjunto de desafíos. Las redes de entrega 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 juego final 6 de la NBA, la audiencia creció rápidamente de casi nada en el momento de la despedida a un pico de 2,04 millones de espectadores en el tercer trimestre. La audiencia pasó 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 reciente evento en vivo en nuestra red, el fenómeno de “público 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 flash y otros desafíos y luego exploramos cómo Verizon Media aprovecha sus muchos años de experiencia en el espacio de CDN para resolver algunos de los puntos de dolor comunes para nuestros clientes. haciéndolo la elección correcta para ofrecer eventos en vivo de alta calidad, no importa si se trata de deportes, conciertos, política… o tal vez el primer aterrizaje en Marte.

Por qué Live Stream Caching 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 pops 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 escalan para grandes audiencias que vienen a la vez.

El perfil de tráfico en vivo es único y claramente diferente de cualquier otra cosa, incluso de VOD, porque durante eventos en vivo, el codificador está publicando continuamente nuevos segmentos de medios (la 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 que no es cero; por lo tanto, no se puede evitar cierta latencia. Sin embargo, es crucial que la CDN sea extremadamente eficiente e inteligente al llenar la caché y manejar las solicitudes de los clientes durante y, lo que es aún más importante, antes de iniciar el proceso de llenado de la caché. Idealmente, la CDN debería ser capaz de mantener la carga en el servidor de origen a un mínimo absoluto, evitando añadir 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 completar un proceso de llenado de caché.

Optimizaciones de caché de transmisión en vivo

Como se muestra en el gráfico a continuación, nuestra plataforma de medios emplea una serie de optimizaciones sintonizables 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 de borde CDN y el origen. Creamos un origen virtual en uno de los pops 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 de la ventana emergente 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 no ser suficiente para tratar con el perfil de tráfico único de la transmisión en vivo.

Compartir caché parcial

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 nuevo cliente), lo que ayuda a minimizar la latencia y optimizar la experiencia del usuario final. Una segunda opción es enviar una única solicitud de relleno de caché que sirva al primer cliente sin demora, pero mantiene 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 grande.

En su lugar, nuestro enfoque logra un equilibrio entre estas dos opciones al permitir que un solo relleno de caché ya a bordo se comparta entre varios clientes que solicitan la misma pieza de contenido que ya está parcialmente en la caché. El uso compartido de caché parcial permite a otros clientes aprovechar un relleno de caché preexistente, de modo que el contenido de vídeo se puede entregar 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 CDN. Este punto en el tiempo es muy pequeño (puede ocurrir en solo unos pocos milisegundos), pero la multitud de flash de transmisión 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 Compartir 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, 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 las multitudes de flash. Cuando llegan los encabezados de respuesta HTTP para la solicitud única y una 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 puede ser ajustado en función de las capacidades de origen específicas y las necesidades del cliente.

Spawn Sub-Solicitud para Señorita

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 llenar desde el 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 for Miss Esta característica también desencadena un relleno de caché para todo el contenido, satisfaciendo diferentes solicitudes de rango de bytes con solo un viaje al servidor de origen. Spawn Sub-Request for Miss and Cache Fill Wait Time 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 rebuffering de video.

Otras optimizaciones de CDN de transmisión en vivo

Presentación 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 en 500K espectadores se ven repentinamente 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 pops 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. Este es un área de enfoque continuo para Edgio. Recientemente redujimos nuestra velocidad de replicación de 5 segundos a aproximadamente 1–2 segundos. Aparte de las transmisiones en vivo, también podemos hacer que otros contenidos estén 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 las 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 gestionados en vivo 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 pops globales y 5.000 interconexiones o conexiones de última milla.

Todo trabajando juntos

Las pesadas demandas de transmisión en vivo llevarán su tecnología al límite. La entrega de un flujo fluido a miles o incluso millones requiere configuraciones especiales de almacenamiento en caché. La combinación de Origin Shield, el uso compartido de caché parcial, el tiempo de espera de llenado de caché, la solicitud de subsolicitud de generación para señorita y la presentación en caliente son características potentes que se pueden adaptar a su infraestructura y demandas de transmisión en vivo únicas. Permiten a nuestra CDN ofrecer 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 caché aún no ha comenzado y aún está pendiente e incluso en la situación en la que la solicitud resulta ser realmente la solicitud del primer cliente para una pieza única de contenido.

La CDN es un componente esencial en la infraestructura de video en vivo. Su sistema de servidor distribuido entrega contenido a sus usuarios, ya que considera tanto las ubicaciones geográficas y de red como el propio origen 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 a demanda (VOD). Con las optimizaciones de caché adecuadas y un montón de margen de maniobra, la CDN está más que preparada para hacer frente a las fluctuaciones y la 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.