Point de départ de presque toutes les sessions de lecture vidéo, l'API de lecture est l'un des services Brightcove les plus utilisés. C'est également l'un des plus anciens, puisqu'il alimente les flux vidéo de Brightcove depuis une dizaine d'années.

Dans cet article de blog, nous verrons comment nous avons complètement réécrit, réarchitecturé et remplacé le service de manière transparente pour l'aligner sur les niveaux élevés de disponibilité et d'évolutivité que les utilisateurs sont en droit d'attendre de Brightcove.

QU'EST-CE QUE L'INTERFACE DE LECTURE ?

Lorsqu'un utilisateur charge une page Web contenant un lecteur Brightcove, le premier appel qu'il effectue est celui de l'API de lecture afin de récupérer toutes les informations nécessaires au téléchargement et à la lecture de la vidéo.

L'URL appelée par le lecteur ressemble à ce qui suit, avec des variations pour permettre des listes de lecture prédéfinies ou basées sur la recherche de plusieurs vidéos :

En retour, il recevra un gros bloc de JSON contenant des métadonnées sur la vidéo et les URL des fichiers manifestes de la vidéo.

SÉCURITÉ

La sécurité de cette API est assurée par les PolicyKeys, qui sont des blobs JSON codés pouvant contenir un identifiant de compte, des listes d'autorisation et de refus géographiques, ainsi qu'une liste de noms de domaine permettant de garantir qu'une vidéo donnée ne peut être lue que dans certaines circonstances. Sans l'une de ces clés, la lecture sera toujours rejetée.

Ces restrictions peuvent également être stockées dans le CMS de Brightcove au niveau de chaque compte et de chaque vidéo.

POURQUOI CHANGER ?

La première incarnation de l'API de lecture nous a bien servis pendant longtemps, mais elle commençait à montrer des signes de fatigue par rapport au reste des services de diffusion dynamique qui composent notre flux de lecture vidéo. En particulier, elle était :

• Hébergé dans une seule région géographique aux États-Unis. Cela signifiait que la lecture échouerait pour les utilisateurs du monde entier en cas de problèmes dans cette région. Cela ajoutait également beaucoup de latence aux temps de démarrage des vidéos lorsqu'elles étaient appelées depuis des pays comme l'Australasie ou le Japon.
• Difficile à mettre en cache et lent à refléter les mises à jour. Bien qu'il soit partiellement pris en charge par un réseau de diffusion de contenu (CDN), nous ne pouvions mettre en cache qu'une courte période afin que les utilisateurs n'aient pas à attendre trop longtemps avant de voir les modifications apportées aux métadonnées ou aux manifestes de la vidéo.
• Écrit dans un langage différent (Clojure) du reste des services de livraison dynamique (Go).
• Difficile à mettre à l'échelleparticulièrement pour les vidéos qui utilisent le géoblocage ou la liste blanche d'adresses IP. Comme nous utilisions un service tiers pour déterminer la provenance d'une requête de lecture particulière et la comparer aux restrictions de la vidéo, nous devions contourner le CDN chaque fois que ces restrictions étaient utilisées :

Lors de la diffusion de vidéos, nous nous appuyons fortement sur les CDN pour mettre en cache autant de contenu que possible afin de permettre aux spectateurs de télécharger la vidéo à partir d'un endroit géographiquement proche pour une expérience de diffusion en continu la plus fluide possible. Étant donné que la requête de l'API de lecture se situe entre le spectateur et le début de la lecture de la vidéo qu'il a choisie, chaque fois que ce contenu n'est pas mis en cache, nous augmentons le temps d'attente du spectateur et le risque qu'il parte voir autre chose.

Si la mise en cache du CDN est relativement simple pour les morceaux de vidéo ou d'audio, elle devient plus complexe lorsqu'il s'agit de mettre en cache la réponse d'une API qui peut potentiellement autoriser ou refuser une demande (par exemple, "Obtenez-moi des informations sur la vidéo X") en fonction d'une combinaison de l'emplacement du spectateur, de son IP, du site web à partir duquel la vidéo est visionnée et de l'utilisation ou non d'un proxy ou d'un réseau privé virtuel (VPN).

En outre, nous devons nous assurer que nous combinons la clé de stratégie côté client, la configuration du compte côté serveur et les métadonnées vidéo pour appliquer ces restrictions correctement.

LA VISION - CACHER TOUT, TOUT LE TEMPS

Nous utilisons Fastly comme l'un de nos CDN dans le cadre de Dynamic Delivery, en particulier lorsque leur puissant langage VCL nous permet d'exécuter une logique avancée sans avoir à renvoyer une requête à l'origine.

Avec l'ajout d'un ensemble de variables de géolocalisation sur chaque requête, nous avons conçu un design qui nous permettrait de mettre en cache les réponses de l'API Playback au CDN indéfiniment et d'exécuter toute la logique autour de l'accès à la réponse au sein de Fastly.

Pour ce faire, nous avons demandé à l'origine de renvoyer au CDN toutes les données nécessaires à la prise de décisions en matière de géorestriction, ainsi que le corps de la réponse :Tout d'abord, le CDN vérifie si la vidéo demandée se trouve déjà dans le cache. Si ce n'est pas le cas, il appelle l'API de lecture pour la récupérer.L'API de lecture appelle ensuite l'API CMS pour récupérer toutes les informations relatives à la vidéo, ainsi que les éventuelles restrictions de visionnage stockées au niveau de chaque vidéo ou de chaque compte.L'API de lecture décode la clé de politique et superpose les restrictions qu'elle contient à celles qu'elle a découvertes dans l'API du CMS, puis les renvoie sous forme d'en-têtes HTTP avec le corps de la réponse standard.Fastly renverra ou refusera la réponse au spectateur qui vient de la demander et stockera la réponse et ses en-têtes dans le cache. Ainsi, lors de la prochaine requête pour cette vidéo, nous pourrons effectuer toute cette logique au sein de Fastly et éviter un voyage vers l'origine.

L'INVALIDATION DU CACHE - UN PROBLÈME FACILE

Maintenant que nous avons mis en cache indéfiniment au CDN, le problème suivant est de savoir comment purger ce cache lorsque c'est nécessaire - par exemple, lorsque quelque chose change dans la vidéo (sa description est modifiée, les DRM sont activés, les restrictions géographiques sont modifiées, etc.

L'approche naïve adoptée par la précédente itération du système consistait à définir un en-tête indiquant au CDN de récupérer une nouvelle copie au bout de 20 minutes, ce qui signifiait que c'était le temps maximum que les utilisateurs devaient attendre pour que leurs modifications soient prises en compte.

Avec notre nouvelle architecture et les clés de substitution de Fastly, nous avons amélioré cette situation pour obtenir le meilleur des deux mondes : une mise en cache indéfinie et des mises à jour quasi instantanées en cas de changement.

La première étape a été de commencer à utiliser ces clés de substitution. L'API de lecture renvoie ses réponses avec l'en-tête Surrogate Key, qui indique à Fastly de marquer l'entrée du cache CDN avec les valeurs qu'elle contient - par exemple, Surrogate-Key : video-id-132413 account-id-938456. Cela nous permettra maintenant d'automatiser la purge d'un ID vidéo spécifique ou de toutes les vidéos pour un ID de compte particulier avec un seul appel à l'API Fastly.

Ensuite, nous avons abonné l'API de lecture à un flux de modifications émis par l'API CMS, qui nous informe à chaque fois qu'une modification est apportée à une vidéo ou à un compte :

Une fois cette purge effectuée, la demande suivante recevra une nouvelle copie de l'API de lecture contenant les modifications apportées.

TL;DR - CELA A-T-IL FONCTIONNÉ ?

Oui !

La nouvelle API de lecture nous a permis de surmonter les limites de l'ancien système - elle est écrite en Go, conteneurisée et déployée dans plusieurs régions du monde, et s'adapte automatiquement à la demande.

Avec la nouvelle architecture CDN, toutes les requêtes de l'API de lecture peuvent désormais être mises en cache, et nous constatons que les taux de réussite élevés de la mise en cache se traduisent par une amélioration considérable du "temps d'accès au premier octet" pour les téléspectateurs, en particulier en Asie et en Australasie, un client ayant partagé des données de lecture montrant des temps de réponse passés d'une moyenne de 300 ms à moins de 50 ms. Ce qui est formidable, car tout le monde est plus heureux lorsque les vidéos commencent à être lues rapidement.