Como punto de partida de casi todas las sesiones de reproducción de vídeo, la API de reproducción es uno de los servicios de Brightcove más utilizados. También es uno de los más antiguos, ya que ha alimentado las secuencias de vídeo de Brightcove durante casi una década.

En esta entrada de blog veremos cómo reescribimos por completo, rediseñamos y cambiamos de forma transparente el servicio para adecuarlo a los altos niveles de disponibilidad y escalabilidad que los usuarios esperan de Brightcove.

¿QUÉ ES LA API DE REPRODUCCIÓN?

Cuando un usuario carga una página web que contiene un reproductor de Brightcove, la primera llamada que realizará será a la Playback API para recuperar toda la información que necesita para empezar a descargar y reproducir vídeo.

La URL a la que llama el reproductor tiene el siguiente aspecto, con variaciones para permitir listas de reproducción predefinidas o basadas en búsquedas de varios vídeos:

A cambio, recibirá un gran bloque de JSON que contiene metadatos sobre el vídeo y las direcciones URL de los archivos de manifiesto del vídeo.

SEGURIDAD

La seguridad en torno a esta API la proporcionan las PolicyKeys, que son blobs JSON codificados que pueden contener un ID de cuenta, listas geográficas de permisos y denegaciones, y una lista de nombres de dominio para garantizar que un vídeo determinado sólo pueda reproducirse en determinadas circunstancias. Sin una de estas claves, la reproducción siempre será rechazada.

Estas restricciones también pueden almacenarse en el CMS de Brightcove, tanto a nivel de cuenta como de vídeo.

¿POR QUÉ CAMBIARLO?

La primera encarnación de la API de reproducción nos sirvió bien durante mucho tiempo, pero había empezado a mostrar su edad en comparación con el resto de los servicios de entrega dinámica que componen nuestro flujo de reproducción de vídeo. En particular, lo era:

• Alojado en una única región geográfica dentro de Estados Unidos. Esto significaba que la reproducción fallaría para los usuarios de todo el mundo si había problemas en esta región. También añadía mucha latencia a los tiempos de inicio del vídeo cuando se llamaba desde lugares como Australasia o Japón.
• Difícil de almacenar en caché y lento para reflejar las actualizaciones. Aunque estaba parcialmente gestionado por una red de distribución de contenidos (CDN), solo podíamos almacenar en caché durante un breve periodo de tiempo para garantizar que los usuarios no tuvieran que esperar demasiado para ver los cambios en los metadatos o manifiestos de vídeo.
• Escrito en un lenguaje diferente (Clojure) que el resto de los servicios de Entrega Dinámica (Go).
• Difícil de escalarsobre todo en el caso de los vídeos con geobloqueo o listas blancas de IP. Como utilizábamos un servicio de terceros para buscar de dónde procedía una solicitud de reproducción concreta y compararla con las restricciones del vídeo, teníamos que eludir la CDN siempre que se utilizaban estas restricciones:

Cuando distribuimos vídeo, dependemos en gran medida de las CDN para almacenar en caché la mayor cantidad de contenido posible y permitir que los espectadores descarguen el vídeo desde algún lugar geográficamente cercano para que la experiencia de streaming sea lo más fluida posible. Dado que la solicitud de la API de reproducción se interpone entre el espectador y el inicio de la reproducción del vídeo elegido, cuando este contenido no se almacena en caché, aumentamos el tiempo de espera y la probabilidad de que se vayan a ver otra cosa.

Mientras que el almacenamiento en caché CDN es relativamente sencillo para trozos de vídeo o audio, se vuelve más complejo cuando se trata de almacenar en caché la respuesta de una API que potencialmente puede permitir o denegar una solicitud (por ejemplo, "Consígueme información sobre el vídeo X") basándose en una combinación de la ubicación del espectador, la IP, el sitio web desde el que se está viendo el vídeo y si están utilizando o no un proxy o VPN.

Además, tenemos que asegurarnos de que estamos combinando la Clave de Política del lado del cliente y la configuración de la cuenta y los metadatos de vídeo del lado del servidor para aplicar estas restricciones correctamente.

LA VISIÓN - CACHEAR TODO TODO EL TIEMPO

Utilizamos Fastly como una de nuestras CDN dentro de Dynamic Delivery, sobre todo cuando su potente lenguaje VCL nos permite realizar lógica avanzada sin tener que hacer una petición de vuelta al origen.

Con la adición de un conjunto de variables de geolocalización en cada solicitud, se nos ocurrió un diseño que nos permitiría almacenar en caché las respuestas de la API de reproducción en la CDN indefinidamente y realizar toda la lógica en torno al acceso a la respuesta dentro de Fastly.

Para ello, hicimos que el origen devolviera a la CDN todos los datos necesarios para tomar decisiones de georestricción, junto con el cuerpo de la respuesta:En primer lugar, la CDN comprueba si el vídeo solicitado ya está en la caché. Si no es así, llama a la API de reproducción para recuperarlo.A continuación, la API de reproducción llama a la API de CMS para recuperar toda la información sobre el vídeo, además de cualquier restricción de visionado que pueda estar almacenada a nivel de vídeo o de cuenta.La API de reproducción descodifica la clave de política y superpone cualquier restricción de la misma sobre las que descubrió de la API de CMS, y luego las devuelve como cabeceras HTTP junto con el cuerpo de la respuesta estándar.Ahora Fastly devolverá o denegará la respuesta al espectador que acaba de solicitarla y almacenará la respuesta y sus cabeceras en la caché, de modo que la próxima vez que llegue una solicitud para este vídeo, podamos hacer toda esa lógica dentro de Fastly y evitar un viaje al origen.

INVALIDACIÓN DE LA CACHÉ: UN PROBLEMA FÁCIL

Ahora que estábamos almacenando indefinidamente en caché en la CDN, el siguiente problema era cómo purgar esa caché cuando fuera necesario, por ejemplo, cuando cambiara algo en el vídeo (se editara su descripción, se activara la DRM, se modificara la restricción geográfica, etc.) o en la cuenta propietaria del vídeo (por ejemplo, se añadiera una nueva IP a la lista blanca de IP).

El enfoque ingenuo que adoptó la iteración anterior del sistema consistía en establecer un encabezado que indicaba a la CDN que recuperara una copia nueva cada 20 minutos, lo que significaba que ese era el tiempo máximo que los usuarios tendrían que esperar para ver reflejados sus cambios.

Con nuestra nueva arquitectura y las Claves Sustitutas de Fastly, mejoramos esto para ofrecernos lo mejor de ambos mundos: almacenamiento en caché indefinido y actualizaciones casi instantáneas cuando algo cambia.

El primer paso fue empezar a utilizar estas claves sustitutas. La API de reproducción devuelve sus respuestas con el encabezado Surrogate Key configurado, que indica a Fastly que etiquete la entrada de la caché de la CDN con los valores que contenga; por ejemplo, Surrogate-Key: video-id-132413 account-id-938456. Esto nos permitirá automatizar la purga de un ID de vídeo específico o de todos los vídeos de un ID de cuenta concreto con una única llamada a la API de Fastly.

A continuación, suscribimos la API de reproducción a un feed de cambios que emite la API de CMS, que nos permite saber cada vez que cambia algo en un vídeo o una cuenta:

Una vez realizada esta purga, la siguiente solicitud recibirá una nueva copia de la API de reproducción que contendrá los cambios realizados.

TL;DR - ¿FUNCIONÓ?

¡Sí!

La nueva API de reproducción nos ha permitido superar las limitaciones del antiguo sistema: está escrita en Go, en contenedores y desplegada en varias regiones del mundo, y se autoescala bajo demanda.

Con la nueva arquitectura CDN, todas las solicitudes de la API de reproducción pueden almacenarse ahora en caché, y estamos viendo que los altos índices de aciertos de la caché se traducen en una gran mejora del "tiempo hasta el primer byte" para los espectadores, sobre todo en Asia y Australasia, con un cliente que comparte datos de reproducción que muestran tiempos de respuesta que han bajado de una media de 300 ms a menos de 50 ms. Lo cual es estupendo, porque todo el mundo es más feliz cuando los vídeos empiezan a reproducirse con rapidez.