Media CDN では、Google の広範なロギング インフラストラクチャと低レイテンシのログ配信を使用して、リクエストごとのログを 1 つの再生イベントに関連付けることができます。これにより、再生の全期間にわたって、エッジ ロケーション、ネットワーク状態、送信元の選択、エラーなど、トラフィックがどのように処理されたかを理解できます。
次のように実現されます。
- クライアントが生成した再生 ID を複数のリクエスト間で指定できる。
- Cloud Logging と統合して、再生と個々のリクエスト全体でクエリを実行する。
- BigQuery または選択したプラットフォームを使用してエクスポートとクエリを実行する。スケーリングされたデータ分析により、再生の全期間のレイテンシ合計と配信形式を確認できます。
再生トレースをほぼリアルタイムのログと組み合わせることで、再生セッションと全体的なエクスペリエンスの品質をロケーション、ストリーム、クライアント ネットワーク別に関連付けて、問題に迅速に対処できます。
再生をトレースする
複数のリクエストをユーザー向けの再生セッションに関連付けるには、クライアントでその再生の ID を生成します。再生トレースは、関連するすべてのリクエストログにヘッダーまたはクエリ パラメータの値を含めることで機能します。
Shaka、ExoPlayer、Apple の AVPlayer などのプレーヤーを使用すると、再生開始イベントをフックし、クエリ パラメータやストリーミング メディアソースに対して行われたリクエストへの HTTP ヘッダーを追加できます。
ヘッダーとクエリ パラメータは次のように定義されます。
- HTTP リクエスト ヘッダー:
Playback-Trace-ID - URL クエリ パラメータ:
playback-trace-id=
両方のヘッダーがリクエスト内に存在する場合、HTTP ヘッダーがクエリ パラメータの代わりに使用されます。
- 再生 ID は 12 バイト（96 ビット）以上、32 バイト（256 ビット）以下のもので、ランダムなソースから生成されたものである必要があります。
- 12 バイト未満の再生 ID はログに記録されません。これは競合を回避するためです。
- 32 バイトを超える再生 ID は、最初の 32 バイトに切り捨てられます。
再生 ID は、7 日間全体で一意でなければなりません。7 日間が経過した後、再生 ID が再利用されるか競合した場合、各リクエストのセットは個別の再生として扱われます。
例: Shaka Player で再生 ID を生成する
大規模な再生トレースを利用するには、ユーザー動画再生のそれぞれに、セグメント（および必要に応じてマニフェスト）に対して行われたすべてのリクエストの再生 ID を含める必要があります。集計された統計情報をロールアップするには、この再生 ID が再生内のすべてのリクエストで同じである必要があります。
次の例では、以下を実行します。
- 動画の読み込み時に再生 ID を生成します。
- マニフェストではなく、セグメントの取得時にのみ送信します。
既存の再生 ID（コンテンツ マネジメント システムやクライアント側の分析から提供される ID など）を使用する場合は、playbackSessionId にその値を入力します。
let playbackSessionId;
player.addEventListener('loading', () => {
const randomBuffer = crypto.getRandomValues(new Uint8Array(16));
playbackSessionId = shaka.util.Uint8ArrayUtils.toBase64(randomBuffer);
});
player.getNetworkingEngine().registerRequestFilter((type, request) => {
// Remove this "type" check if you want the header on every request.
// Alternately, you can check the request.uris array to send the
// header to some servers and not others.
if (type == shaka.net.NetworkingEngine.RequestType.SEGMENT) {
request.headers['CPN'] = playbackSessionId;
}
});