ブライトコーブがFASTLYを使用して最初のバイトまでの時間を短縮する方法
ほぼすべての動画再生セッションの開始点である再生 APIは、ブライトコーブのサービスの中でも最も利用されているものの 1 つです。また、最も古いサービスの 1 つでもあり、ブライトコーブの動画ストリームを約 10 年間支えてきました。
このブログ投稿では、ユーザーがブライトコーブに期待する高レベルの可用性とスケーラビリティを実現するために、サービスを完全に書き直し、再構築し、透過的に入れ替えた方法について説明します。
プレイバック・アピとは何ですか？
ユーザーが Brightcove プレーヤを含む Web ページをロードすると、最初に Playback API を呼び出し、動画のダウンロードと再生を開始するために必要なすべての情報を取得します。
プレーヤーが呼び出すURLは以下のようになり、複数の動画の事前定義または検索ベースのプレイリストを可能にするバリエーションがあります：
その見返りとして、動画に関するメタデータと動画マニフェスト ファイルの URL を含む大きな JSON ブロックを受け取ります。
セキュリティ
この API のセキュリティはPolicyKeys によって提供される。PolicyKeys はエンコードされた JSON blob で、アカウント ID、geo allow および deny リスト、ドメイン名のリストを含むことができ、特定の状況下でのみ特定の動画を再生できるようにする。これらのキーのいずれかがなければ、再生は常に拒否される。
これらの制限は、アカウント単位と動画単位の両方で、ブライトコーブの CMS に保存することもできます。
なぜ変えるのか？
最初のPlayback APIは、長い間、私たちに貢献してくれましたが、私たちのビデオ再生フローを構成する他のDynamic Deliveryサービスと比較すると、老朽化が目立ち始めていました。特に
- 米国内の単一地域でホスティングされている。そのため、この地域で問題が発生した場合、世界中のユーザーが再生に失敗することになる。また、オーストラレーシアや日本のような地域から呼び出された場合、ビデオの起動時間に多くの待ち時間が発生しました。
- キャッシュが難しく、更新の反映が遅い。コンテンツ・デリバリー・ネットワーク（CDN）によって部分的にフロントされていましたが、ユーザーが動画のメタデータやマニフェストの変更を確認するのに長時間待たされることがないように、短時間しかキャッシュできませんでした。
- 他のダイナミック・デリバリー・サービス（Go）とは異なる言語（Clojure）で書かれている。
- 規模拡大が難しい特に、ジオブロッキングやIPホワイトリストを使用している動画の場合。特定の再生リクエストがどこから来ているのかを調べ、動画の制限と照合するためにサードパーティのサービスを使用していたため、これらの制限が使用されているときは常にCDNをバイパスする必要がありました：
動画を配信する場合、視聴者が最もスムーズなストリーミング体験のために地理的に近い場所から動画をダウンロードできるように、できるだけ多くのコンテンツをキャッシュするために CDN に大きく依存しています。Playback API リクエストは視聴者が選択した動画の再生を開始するまでの間にあるため、このコンテンツがキャッシュされていない場合は常に、視聴者の待ち時間が長くなり、他の動画を視聴するために視聴者が離れてしまう可能性が高くなります。
CDNキャッシングは動画や音声のチャンクの場合は比較的簡単だが、視聴者の位置、IP、動画が閲覧されているウェブサイト、プロキシやVPNを使用しているかどうかなどの組み合わせに基づいて、リクエスト（例えば「動画Xに関する情報を取得する」）を許可または拒否できる可能性のあるAPIのレスポンスをキャッシュしようとすると、より複雑になる。
さらに、これらの制限を正しく適用するために、クライアント側のPolicy Keyとサーバ側のアカウント設定および動画メタデータを組み合わせていることを確認する必要があります。
ビジョン - 常にすべてをキャッシュする
特に、Fastlyの強力なVCL言語により、オリジンにリクエストを戻すことなく高度なロジックを実行できるためです。
リクエストごとにジオロケーション変数を追加することで、Playback APIのレスポンスをCDNに無期限にキャッシュし、レスポンスへのアクセスに関するロジックをすべてFastly内で実行できるようなデザインを考えました。
オリジンからCDNに、レスポンスボディとともに、地域制限の決定に必要なすべてのデータを返すようにすることで、これを実現した：
まず、CDNは要求された動画がすでにキャッシュにあるかどうかをチェックする。ない場合は、再生 API を呼び出して動画を取得する。
Playback API は次に CMS API を呼び出し、動画に関するすべての情報と、動画単位またはアカウント単位で保存されている可能性のある視聴制限を取得する。
Playback APIはPolicy Keyをデコードし、CMS APIから発見した制限の上にそれを重ね、標準のレスポンスボディとともにHTTPヘッダーとして返す。
Fastly は、リクエストした視聴者にレスポンスを返すか拒否するかを決定し、レスポンスとそのヘッダーをキャッシュに保存します。これにより、次回この動画に対するリクエストが来たときに、Fastly 内ですべてのロジックを実行し、オリジンへの移動を回避することができます。
キャッシュの無効化 - 簡単な問題
CDNで無期限にキャッシュしていたため、次の問題は、必要なときにキャッシュをパージする方法だった。たとえば、動画に何か変更があったとき（説明文の編集、DRMの有効化、地域制限の変更など）や、動画を所有するアカウントに変更があったとき（IPホワイトリストに新しいIPが追加されたなど）だ。
以前のシステムが取っていた素朴なアプローチは、20分後に新しいコピーをフェッチするようCDNに指示するヘッダーを設定することだった。
私たちの新しいアーキテクチャとFastlyのサロゲート・キーによって、私たちはこれを改善し、無期限のキャッシュと、何かが変更されたときのほぼ即時の更新という、両方の長所を実現しました。
最初のステップは、このSurrogate Keyを使い始めることだった。Playback API は Surrogate Key ヘッダを設定してレスポンスを返します。このヘッダは、CDN キャッシュエントリにどのような値でもタグ付けするよう Fastly に指示します（例：Surrogate-Key: video-id-132413 account-id-938456）。これにより、特定の動画 ID または特定のアカウント ID のすべての動画のパージを、1 回の Fastly API 呼び出しで自動化できるようになります。
次に、CMS API が発行する変更フィードに Playback API をサブスクライブする：
このパージが行われると、次に送られてくるリクエストはPlayback APIから新しいコピーを受け取ることになります。
TL;DR - うまくいったか？
そうだ！
Goで書かれ、コンテナ化され、複数のグローバル・リージョンにデプロイされ、オンデマンドでオートスケールされる。
新しいCDNアーキテクチャでは、すべてのPlayback APIリクエストがキャッシュ可能になり、高いキャッシュヒット率によって、特にアジアとオーストラレーシアの視聴者の「最初のバイトまでの時間」が大幅に改善されています。ある顧客は、平均300msから50ms以下にレスポンスタイムが短縮されたプレーヤーデータを共有しています。動画が高速で再生されるようになれば、誰もがハッピーになれるからです。
