CMCDv2 : 動画ストリーミングのテレメトリを強化

動画ストリーミング業界でさまざまなエンジニア職を経験する中、同僚たちとよく話題に上った（時には共に嘆いた）のが、作業の重複でした。つまり、社内の各組織がサイロ化し、実質的に同じソフトウェアをそれぞれ開発するために、どれほどの労力が費やされているのかという問題です。

最近では、ストリーミングを構成する主要な要素のオープン化と標準化に向けた優れた取り組みにより、そうした状況が変わり始めています。Fastly が特に関心を寄せているのは、エッジに関わる取り組みです。たとえば、Common Access Tokens による分散型アクセス制御や、Common Media Client Data を活用して、ネットワークパフォーマンスが視聴体験に与える影響を把握する取り組みが挙げられます。

CMCD 標準の Version 2 が最近リリースされたのを機に、Version 1 が成功した理由を振り返るとともに、新バージョンによって広がる可能性を探ってみたいと思います。

CMCD の歩みを簡単に振り返る

CMCD の Version 1 は、ストリーミングサービスに共通する問題に対する洗練された解決策です。動画プレイヤーのログからは、ユーザーがバッファリングや画質の低下を経験したタイミングが分かり、CDN のログからは、ネットワークやオリジンにいつ問題が発生したかが分かります。しかし、この2種類のログは別々の場所に集約されることが多く、特に複数の CDN や再生デバイスにまたがる場合、それらの相関関係を簡単に把握する方法がありませんでした。再生の問題をデバッグする際には、異なるグラフに見られるスパイクとタイムスタンプを突き合わせ、関連性を探る作業が必要になることがよくありました。

CMCD の登場前 : 動画プレイヤーのログと CDN のログが別々に管理

2種類のログは、異なるバケットや、場合によっては異なるストレージプロバイダーに保存されることがよくありました。

CMCDv1 は、マニフェストまたはメディアセグメントに対する HTTP リクエストに含めて送信できるキーと値のペアを標準化しました。これらのペアは解析され、該当するリクエストに関する CDN のほかのログ情報とともに記録されます。これにより、スタック全体にわたってユーザーセッションをより包括的に把握できるようになりました。必要に応じて、個々のセッションを詳しく調査することもできます。

具体的な形式の説明はこの記事の範囲外ですが、dash.js のオープンソースプロジェクトでは、優れたデモページが公開されています。このページでは、ひときわ大きなウサギの動画を見ながら、イベントが発生する様子をリアルタイムで確認できます。

これにより、再生セッションを通じたフルスタックトレーシングが実質的に可能になります。任意の時点でプレイヤーとサーバーに何が起きていたかを把握し、次のような疑問にも答えられるようになりました。

• オリジンのレイテンシ増加が、バッファリングや再生品質の低下につながったか

• バッファの枯渇の発生は CDN の POP によって異なるか

• レイテンシの急増に、ほかのプレイヤーよりもうまく対処できるプレイヤーはあるか

• ASN によってパフォーマンスに違いはあるか

また、次に発生する可能性のあるリクエスト (セグメントやファイルの範囲に対するリクエスト) について、CDN にヒントを提供できます。これにより、プリフェッチを活用して後続のリクエストを高速化できます。

CMCD はオープンで、現在、広く採用されている標準です。そのため、一般的な動画プレイヤーと監視ツールを組み合わせるだけで、すぐにオブザーバビリティを実現できます。

Fastly は、このアーキテクチャにおいてデータの中継役として特に適しています。ユーザーが定義した形式や値を使用して、さまざまなプラットフォームにリアルタイムでログを送信できるため、ライブストリーミングの運用者は、イベント中に発生した問題に迅速に対応し、その原因を診断できます。

導入の参考として、VCL で CMCD の値を解析する例をこちらにご用意しました。

CMCDv2 の新機能

CMCDv2 は同じプロトコルに含まれていますが、実際にはアーキテクチャ上の大きな進化です。Request Mode の成功を足掛かりに、クライアント側の詳細なテレメトリも取り込むことを目指しています。

Version 2 は、Version 1 で導入された CDN リクエストへの情報付加の仕組みと完全な後方互換性を維持しています (この仕組みは現在、Request Mode と呼ばれています)、さらに Response Mode と Event Mode という2つの新しいモードが追加されています。また、新しいモードのデータを動画データと同じ経路で送信する必要がなくなり、クライアントからサードパーティのドメイン（SaaS のメトリクス集約サービスなど）へ直接送信する機能も追加されています。

さらに、2つの新しいモードに加え、CMCDv1 の実運用で得られた知見をもとに、Request Mode に多数のキーと値のペアが追加されています。

このブログ記事ですべてを紹介するのは無理ですが、以下は、特に注目している新しいメトリクスの一部です。

• Buffer Target Size (バッファの目標サイズ) : バッファサイズを単なる数値として扱うのではなく、理想的なサイズと比較して分析できます。動画プレイヤーの実装、デバイス、コンテンツの種類によって、目標とするバッファサイズが大きく異なる場合があるため、これは重要です。

• Absolute / Relative Degradation Metrics (絶対的／相対的な品質低下メトリクス) : 動画の再生中に一度だけ3秒間再生が停止する場合と、セグメントごとに再生が停止する場合とでは、ユーザーの視聴体験は大きく異なります。新しいメトリクスの多くは、こうしたケースの違いをより明確に区別できるようにすることに重点を置いています。

• Sub-Content Differentiation (サブコンテンツの区別) : メインコンテンツから広告への切り替え時には、再生の問題が発生することがよくあります。CMCDv2 により、コンテンツの種類を区別し、問題が発生している箇所を正確に把握できます。

Response Mode

Response Mode は、Request Mode でメディアリクエストとともに送られるデータを補完する役割を果たします。クライアントが CDN から動画・音声データのチャンクを受信し終えた後に動作します。これにより、Time To First Body Byte (最初のボディバイトを受信するまでの時間)、Time To Last Byte (最後のバイトを受信するまでの時間)、HTTP Response Code (HTTP レスポンスコード) など、リクエスト時点では取得できなかった情報をクライアントから報告できるようになります。

これらのフィールドの多くは CDN のログでも確認できます。しかし、プレイヤー側でこれらの情報を取得し、外部エンドポイントに直接送信できれば、複数の CDN を利用する構成などで役立ちます。たとえば、各 CDN のログを正規化・集約する手間を省けるほか、リアルタイムのログ出力に対応していない CDN を利用する場合にも有効です。

Event Mode

新たな取り組みの大部分は Event Mode に集中しており、初期バージョンが抱えていた主な制約のひとつを解消することを目的としています。その制約とは、再生セッション中には、一時停止、バックグラウンドへの移行、手動での画質切り替えなど、非同期に発生するさまざまな関連イベントがあるにもかかわらず、情報の記録がメディアリクエストに紐付いていたことです。この新しいモードでは、こうしたイベントやユーザーが任意に定義したイベントを、それらが発生した正確なタイミングで記録できます。つまり、HTTP リクエストの発生タイミングに縛られることなく、イベントそのものを記録できるようになります。

従来、こうしたイベントは、プレイヤーごとに定義されたメトリクスに記録されていました。しかし、メトリクスの名前やパラメーターは使用するプレイヤーによって異なるため、CDN のメトリクスと簡単に関連付けることができませんでした。CMCDv1 が生まれた理由をここまで読んできた方には、聞き覚えのある話ではないでしょうか！

この新しいモードを試してみたいものの、オリジンに到達する新たなイベントの量や、イベントを取り込むための新しいデータパイプラインの構築が懸念される場合は、Fastly の Beacon Termination が有力な選択肢となります。Beacon Termination を利用すれば、イベントによって増加する負荷を受け止め、イベントをフィルタリングしたうえで、利用しているサードパーティーのデータツールに転送できます。

では、CMCDv2 をすべきか？

答えは少し複雑です！十分に実用可能ですが、次の点に留意してください。

• これは標準に対する大幅な追加であり、比較的新しい機能でもあるため、プレイヤーやモニタリングツールによるデフォルトでのサポートは現在も発展途上です。ただし、SVTA の common-media-library はすでに対応しており、現在も活発に開発が進められています。そのため、hls.js や dash.js などのプレイヤーライブラリは、デフォルトでサポートされます。

• Event Mode では、実用的な知見を引き出すために分析すべきデータが大幅に増えるだけでなく、その意味を解釈することも複雑になる可能性があります。ログの記録方法やデータパイプラインを見直す必要が出てくるかもしれません。また、まだサンプリングを導入していない場合は、その導入を検討するか、少なくとも記録するイベントを慎重に選ぶ必要があります。

• Event Mode を使用してメトリクスをサードパーティーの収集エンドポイントに直接送信する場合、広告ブロッカーによってメトリクスが遮断される可能性が高くなります。その結果、データに偏りや欠落が生じる可能性があります。

導入を決める前に、もう少し具体的に理解しておきたい場合は、再生セッション中に発生する Event Mode のイベントの種類を確認できるデモページをご覧ください。

ストリーミングスタックへの CMCDv2 の導入に興味がありますか？ Event Mode では、記録するデータを選ぶ必要があるほか、そのデータの送信先やルーティング方法についても新たに検討する必要があります。お客様の環境におけるログ記録、ビーコンの終端処理、複数 CDN 間の正規化について検討する際は、Fastly チームにご相談ください。