Als Ausgangspunkt für fast jede Videowiedergabesitzung ist die Wiedergabe-API einer der am stärksten genutzten Brightcove-Services. Sie ist auch einer der ältesten, da sie die Videostreams von Brightcove bereits seit etwa einem Jahrzehnt unterstützt.
In diesem Blogbeitrag erfahren Sie, wie wir den Service komplett neu geschrieben, umgestaltet und transparent ausgetauscht haben, um ihn mit der hohen Verfügbarkeit und Skalierbarkeit in Einklang zu bringen, die Benutzer von Brightcove gewohnt sind.
WAS IST DIE PLAYBACK-API?
Wenn ein Benutzer eine Webseite lädt, die einen Brightcove-Player enthält, erfolgt der erste Aufruf an die Wiedergabe-API, um alle Informationen abzurufen, die zum Herunterladen und Wiedergeben von Videos erforderlich sind.
Die URL, die der Player aufruft, sieht wie folgt aus, mit Variationen, um vordefinierte oder suchbasierte Wiedergabelisten mit mehreren Videos zu ermöglichen:
Im Gegenzug erhält er einen großen JSON-Block, der Metadaten über das Video und URLs für die Videomanifestdateien enthält.
SICHERHEIT
Die Sicherheit dieser API wird durch PolicyKeys gewährleistet, bei denen es sich um kodierte JSON-Blobs handelt, die eine Konto-ID, geografische Erlaubnis- und Ablehnungslisten sowie eine Liste von Domänennamen enthalten können, um sicherzustellen, dass ein bestimmtes Video nur unter bestimmten Umständen wiedergegeben werden kann. Ohne einen dieser Schlüssel wird die Wiedergabe immer abgelehnt.
Diese Einschränkungen können auch im CMS von Brightcove sowohl auf Konto- als auch auf Videoebene gespeichert werden.
WARUM ÄNDERN?
Die erste Version der Wiedergabe-API hat uns lange Zeit gute Dienste geleistet, aber sie war im Vergleich zu den übrigen Dynamic-Delivery-Diensten, die unseren Videowiedergabefluss ausmachen, in die Jahre gekommen. Insbesondere war sie:
- Gehostet in einer einzigen geografischen Region innerhalb der Vereinigten Staaten. Dies bedeutete, dass die Wiedergabe für Benutzer weltweit ausfiel, wenn in dieser Region Probleme auftraten. Außerdem kam es zu einer erheblichen Latenz bei den Videostartzeiten, wenn das Video von Orten wie Australien oder Japan aus aufgerufen wurde.
- Schwierig zu cachen und langsam bei der Wiedergabe von Aktualisierungen. Obwohl es teilweise über ein Content Delivery Network (CDN) bereitgestellt wurde, konnten wir nur eine kurze Zeit zwischenspeichern, um sicherzustellen, dass die Benutzer nicht zu lange warten mussten, um Änderungen an den Video-Metadaten oder Manifesten zu sehen.
- In einer anderen Sprache (Clojure) geschrieben als der Rest der Dynamic-Delivery-Dienste (Go).
- Schwierig zu skaliereninsbesondere für Videos, die Geoblocking oder IP-Whitelisting verwenden. Da wir einen Dienst eines Drittanbieters nutzten, um herauszufinden, woher eine bestimmte Wiedergabeanforderung kam und sie mit den Einschränkungen des Videos abzugleichen, mussten wir das CDN umgehen, wenn diese Einschränkungen genutzt wurden:
Bei der Bereitstellung von Videos verlassen wir uns in hohem Maße auf CDNs, um so viele Inhalte wie möglich zwischenzuspeichern, damit die Betrachter das Video von einem geografisch nahe gelegenen Ort herunterladen können und ein möglichst reibungsloses Streaming-Erlebnis haben. Da die Anforderung der Wiedergabe-API zwischen dem Betrachter und dem Beginn der Wiedergabe des ausgewählten Videos liegt, erhöht sich die Wartezeit für den Betrachter und die Wahrscheinlichkeit, dass er die Seite verlässt, um etwas anderes anzusehen, wenn dieser Inhalt nicht zwischengespeichert wird.
Während das CDN-Caching für Video- oder Audioblöcke relativ einfach ist, wird es komplexer, wenn man versucht, die Antwort einer API zwischenzuspeichern, die eine Anfrage (z. B. "Holen Sie mir Informationen über Video X") auf der Grundlage einer Kombination aus dem Standort des Betrachters, der IP-Adresse, der Website, von der aus das Video angesehen wird, und der Tatsache, ob ein Proxy oder VPN verwendet wird, zulassen oder ablehnen kann.
Außerdem müssen wir sicherstellen, dass wir den clientseitigen Richtlinienschlüssel mit der serverseitigen Kontokonfiguration und den Video-Metadaten kombinieren, um diese Einschränkungen korrekt anzuwenden.
DIE VISION - IMMER ALLES IM CACHE
Wir verwenden Fastly als eines unserer CDNs im Rahmen von Dynamic Delivery, vor allem, weil die leistungsstarke VCL-Sprache es uns ermöglicht, fortgeschrittene Logik auszuführen, ohne eine Anfrage an den Ursprung stellen zu müssen.
Mit der Hinzufügung einer Reihe von Geolocation-Variablen bei jeder Anfrage haben wir ein Design entwickelt, das es uns ermöglicht, Playback-API-Antworten im CDN auf unbestimmte Zeit zwischenzuspeichern und die gesamte Logik rund um den Zugriff auf die Antwort innerhalb von Fastly auszuführen.
Wir haben dies erreicht, indem wir den Ursprung veranlasst haben, alle Daten, die für die Entscheidung über die geografische Beschränkung erforderlich sind, zusammen mit dem Antwortkörper an das CDN zu senden:
Zunächst prüft das CDN, ob sich das angeforderte Video bereits im Zwischenspeicher befindet. Wenn nicht, ruft es die Wiedergabe-API auf, um es abzurufen.
Die Wiedergabe-API ruft dann die CMS-API auf, um alle Informationen über das Video sowie etwaige Anzeigebeschränkungen abzurufen, die möglicherweise auf Video- oder Kontoebene gespeichert sind.
Die Wiedergabe-API dekodiert den Richtlinienschlüssel und überlagert die von der CMS-API ermittelten Einschränkungen mit diesen und gibt diese als HTTP-Header zusammen mit dem Standardantwortkörper zurück.
Fastly wird nun die Antwort an den Betrachter, der sie gerade angefordert hat, zurücksenden oder verweigern und die Antwort und ihre Header im Cache speichern, so dass wir bei der nächsten Anfrage für dieses Video die gesamte Logik innerhalb von Fastly ausführen können und eine Reise zum Ursprung vermeiden.
CACHE-INVALIDIERUNG - EIN EINFACHES PROBLEM
Da wir nun auf unbestimmte Zeit im CDN zwischenspeichern, bestand das nächste Problem darin, diesen Zwischenspeicher bei Bedarf zu bereinigen - zum Beispiel, wenn sich etwas am Video ändert (die Beschreibung wurde bearbeitet, DRM aktiviert, die geografische Einschränkung geändert usw.) oder am Konto, dem das Video gehört (z. B. wenn eine neue IP zur IP-Whitelist hinzugefügt wird).
Der naive Ansatz, den die vorherige Version des Systems verfolgte, bestand darin, einen Header zu setzen, der das CDN aufforderte, nach 20 Minuten eine neue Kopie abzurufen, was bedeutete, dass die Nutzer maximal so lange warten mussten, bis ihre Änderungen übernommen wurden.
Mit unserer neuen Architektur und den Surrogate Keys von Fastly haben wir dies verbessert, um das Beste aus beiden Welten zu erhalten: unbegrenztes Caching und fast sofortige Updates, wenn sich etwas ändert.
Der erste Schritt bestand darin, diese Surrogate Keys zu verwenden. Die Wiedergabe-API gibt ihre Antworten mit dem Surrogate Key-Header zurück, der Fastly anweist, den CDN-Cache-Eintrag mit den darin enthaltenen Werten zu markieren - zum Beispiel Surrogate-Key: video-id-132413 account-id-938456. Dies ermöglicht es uns nun, die Bereinigung entweder einer bestimmten Video-ID oder aller Videos für eine bestimmte Konto-ID mit einem einzigen Fastly-API-Aufruf zu automatisieren.
Als Nächstes haben wir die Wiedergabe-API für einen Änderungsfeed abonniert, den die CMS-API ausgibt und der uns jedes Mal informiert, wenn sich etwas an einem Video oder Konto ändert:
Sobald diese Bereinigung erfolgt ist, erhält die nächste Anfrage eine neue Kopie von der Wiedergabe-API, die alle vorgenommenen Änderungen enthält.
TL;DR - HAT ES FUNKTIONIERT?
Ja!
Mit der neuen Playback-API konnten wir die Beschränkungen des alten Systems überwinden: Sie ist in Go geschrieben, in Containern implementiert und wird in mehreren globalen Regionen bereitgestellt.
Mit der neuen CDN-Architektur sind nun alle Playback-API-Anfragen zwischenspeicherfähig, und wir sehen, dass sich die hohen Cache-Trefferraten in einer erheblich verbesserten "Zeit bis zum ersten Byte" für die Zuschauer niederschlagen, insbesondere in Asien und Australasien. Ein Kunde teilte uns Player-Daten mit, die eine Senkung der Antwortzeiten von durchschnittlich 300 ms auf unter 50 ms zeigen. Das ist großartig - denn jeder ist zufriedener, wenn Videos schnell abgespielt werden.
