CMCD と CloudFront による動画の可観測性向上

可観測性は、あらゆるシステムの運用に不可欠です。システムが正しく機能しているか、ユーザーエクスペリエンスに関する洞察を提供できるか、問題が発生したときに通知されるか、根本的な原因を突き止めるのに役立つかを判断する必要があります。しかし、観測可能なビデオストリーミングシステムの構築は、メディアプレーヤー、CDN 、オリジン、ネットワークなど、複数の独立したアーキテクチャーのコンポーネントからデータを収集、相関、分析する必要があるため、お客様にとって困難なものとなります。一般的に、これらのコンポーネントは別々に管理され、観測可能な目的で使用するために独自のデータセット（すなわち、ログとメトリクス）を生成します。CDN はリクエストフローのサーバー側を表します。HTTP はステートレスプロトコルであり、複数のリクエストが同じユーザーセッションを表すとしても、それらを確実にグループ化するために使用できるいかなる種類のアイデンティティも持たないため、セッションの概念を持っていません。動画以外の世界では、コンテンツ所有者はリクエストのセッション化に HTTP Cookieを使用しています。しかし、ビデオプロバイダーは、一部のメディアクライアントでのサポートが不十分なため、ビデオストリーミングでこれに依存することを躊躇します。このため、CDN のログから、同時ビデオセッション数やビデオアセットの人気度などのコンテンツ分析レポートを作成したり、セッションレベルでのトラブルシューティングを実行したりすることは困難です。同様に、サーバーの稼働状況や設置場所、リクエスト処理ロジック、その結果といった CDN の指標も、クライアント側という観点では見逃されています。

これらの独立したデータセットを相関させて、リクエスト処理を完全に可視化するのは簡単なことではありません。ビューアIPアドレスやリクエスト時間などの間接的な指標を使用して、両側からログの相関を実行するには、かなりの計算リソースが必要になります。また、複数のログ収集・保存システム、ダッシュボード、アラートメカニズムを使用することになるかもしれません。そのため、問題をピンポイントで特定したり、問題の根本原因を特定したりするのが困難になり、効果的に行うには高度な専門知識が必要になります。これを簡単にするのは、サーバー側とクライアント側の両方のデータが同じログレコードにマージされ、同じ場所に保存され、同じダッシュボードで可視化、アラート、データ分析の目的で使用されるようにすることでしょう。この記事では、CMCD（Common Media Client Data）仕様と Amazon CloudFront を使用して、ビデオストリーミングで実現する方法について説明します。

CMCD とは？

CMCDは、CTA（Consumer Technology Association）が主催するWAVE（Web Application Video Ecosystem）プロジェクトによって開発されました。CMCD は、メディアプレーヤーが、HTTP リクエストヘッダ、HTTP クエリー引数、または JSON オブジェクトとして、リクエストごとにQoE（Quality of Experience）クライアントサイドメトリクスを伝達する方法を規定しています。メトリクスの全リストを含む CMCD 仕様書は、こちらでご覧いただけます。

CMCD の指標は、お客様が様々なタスクを達成することを可能にします。例を挙げると、

• Session ID（sid）は、現在の再生セッションを識別し、何千もの個々のサーバーログラインを1つのユーザーセッションとして解釈し、セッションレベルでのレポートを構築することができます。また、トラブルシューティングの目的でも使用することができます。あるビデオセッションが拒絶反応を起こしている場合、セッション ID はそのセッションに属する個々のリクエストを素早く見つけ出し、調査のためにサポートに提供するのに役立ちます。
• Buffer starvation（bs）は、プレーヤーがリバッファリング状態にあり、リクエストを送信する直前にビデオまたはオーディオの再生が停止したことを示すシグナルです。対処すべき問題があることを示しています。対応するサーバー側のメトリクスを確認することで、CDN サーバーの運用状態を確認し、問題がサーバーに関連しているのか、あるいは根本的な原因が他の場所、例えば特定のネットワークセグメントやオリジンにあるのかを確認することができます。
• Buffer length（bl）、Measured throughput（mtp）、Encoded bitrate（br）、Top bitrate（tb）は、ユーザー体験の質をモニタリングし、視聴者の満足度を知ることができます。例えば、地理的に異なる場所にいる視聴者がどのスループットを利用できるかをモニターし、それに応じてコンテンツのエンコーディングプロファイルを計画することができます。トップビットレートは、視聴者が利用できる最高品質のビットレートを示し、エンコードビットレートは実際に使用されるビットレートを示します。理想的なシナリオでは、両者は同じであるべきで、そうでない場合は、QoE が最高であるとは言えません。これらの指標から総合的な QoE スコアを算出し、CDN のベンチマークに利用することが可能です。
• Content ID （cid）、Object duration（d）、Playback rate（pr）、Streaming format（sf）、Stream type（st）は、コンテンツ分析において、その人気やエンゲージメント時間を測定したり、Geo ロケーション、クライアントデバイスタイプ、時間帯などの様々な次元で表示したりすることができます。

CDN がリクエストを処理すると、これらのメトリクスを含む完全なクエリー文字列とすべてのヘッダーが CDN のログレコードに書き込まれ、対応するサービス品質（QoS）サーバー側のメトリクスと一緒にデータ分析の目的で利用できるようになります。CMCD はメディアプレーヤーによって実装されなければなりませんが、そのほとんどは、ビデオ分析システムへのAPIによって送信されるクライアント側のメトリクスをすでにサポートしているため、CMCD サポートをゼロから開発する必要はありません。その代わり、既存の機能を拡張して、HTTP リクエストに含まれるメトリックスにも対応します。プレーヤーのベンダーが CMCD をすでに実装しているか、または実装する予定があるかどうかを確認することができます。CMCD を使用したリクエストがどのように見えるかを調べるために、この投稿では、CMCD サポートをすでに追加したオープンソースの HLS.js プレーヤーを使用します。しかし、CMCD ベースのソリューションはプレーヤーを問わないはずで、プレーヤーが CMCD の仕様に準拠している限り、他のプレーヤーの使用や新しいプレーヤーの追加はシームレスであるべきです。

HLS.js で CMCD を有効にするには、その設定に cmcd: true パラメータを追加する必要があります。また、コンテンツ固有の統計を可能にする contentId と sessionId を指定するか、後者を HLS.js に自動生成させることができます。デフォルトでは、プレーヤーはクエリー文字列で CMCD を伝達します。また、ヘッダーを使用することもできますが、カスタムヘッダーはプリフライト OPTIONS リクエストをトリガーするため、リクエスト数が増加し、結果として CloudFront のコストとレイテンシーが増加します。したがって、この方法を行うための特別な要件がない限り、この方法は推奨されません。

CMCDを有効にした場合の完全な URL は以下のようになります。

https://drgt2mhriu0nm.cloudfront.net/video/hls/ocean/ocean_Ott_Hls_Ts_Avc_Aac_16x9_1920x1080p_30Hz_8500Kbps_00012.ts?CMCD=bl%3D29900%2Cbr%3D8934%2Cd%3D3000%2Cmtp%3D108400%2Cot%3Dav%2Csf%3Dh%2Csid%3D%221a8cf818-9855-4446-928f-19d47212edac%22%2Ctb%3D8934

例に見られるように、CMCD クエリー引数は CMCD キーワードで始まり、URL エンコードされたキーと値のペアの連結を含んでいます。これをデコードすると、仕様に沿った以下のような CMCD パラメータを見ることができます。

bl=29900,br=8934,d=3000,mtp=108400,ot=av,sf=h,sid=”1a8cf818-9855-4446-928f-19d47212edac”,tb=8934

クエリー文字列は CloudFront のログの cs-uri-query というフィールドに送信されるので、そこから CMCD を抽出して使うというのが次のステップになります。

2種類のCloudFrontのロギングオプション

CloudFrontは2種類のロギングオプションを提供します。

• 標準ログは、リクエスト完了から数分以内に、選択した Amazon Simple Storage Service (Amazon S3) のバケットに配信されます。
• リアルタイムログは、リクエスト完了後数秒以内に Amazon Kinesis Data Streams で選択したデータストリームに配信されます。

これらのオプションの違いについて、より詳しく見ていきましょう。

コスト
CloudFrontでは標準ログは課金されませんが、ログファイルの保存とアクセスには Amazon S3 の料金が発生します。
リアルタイムログは、Kinesis Data Streams の使用料に加え、生成されたログ行数に応じて課金されます。リアルタイムログは一見高価な機能に見えますが、以下の設定項目が変更可能なため、コストを最適化することができます。

• リアルタイムログのサンプリングレート-リアルタイムログ記録を受信するリクエストの割合。
• ログ記録で受信したい特定のフィールド。
• リアルタイムログを受信する特定のキャッシュ動作（パスパターン）。これにより、動画配信用に作成されたキャッシュビヘイビアにのみリアルタイムログを使用することができ、処理および保存のためのログ量を削減することができます。

標準ログでは設定可能な項目はなく、ディストリビューション全体で有効となります。

フィールド
リアルタイムログには、標準ログで利用可能なすべてのフィールドが含まれますが、さらに、c-ip-version（IPv4 または IPv6）、cache-behavior-path-pattern（キャッシュ動作を特定するパスパターン）、cs-accept-encoding（Accept-Encoding　ヘッダー値）、cs-accept（Accept ヘッダー値）といういくつかの追加フィールドを持っています。最近、リアルタイムログに 3 つの新しいログフィールドが追加されました。オリジンの最初のバイトのレイテンシー、オリジンの最後のバイトのレイテンシー、そして ASN（Autonomous System Number） の3つのログフィールドがリアルタイムログに追加され、オリジンとネットワークの両方のパフォーマンスの可視性が向上しました。さらに、リアルタイムログには、標準ログにはない cs-headers（ビューワーリクエストの HTTP ヘッダ（名前と値））フィールドが含まれています。つまり、ヘッダーで CMCD を使用するつもりなら、リアルタイムログが唯一の選択肢となります。また、ログにヘッダーがあることで、CloudFront のヘッダーを記録することができます。これらのヘッダーは、視聴者のデバイスタイプや地理的な位置に関する情報でログを豊かにし、データ分析における追加のディメンションとして機能することができます。

ログ送信先
お客様は、Amazon S3 から標準ログをダウンロードし、分析ツールで処理することができます。標準ログを分析するもう一つの方法は、Amazon Athena を使用することです。
リアルタイムのログを分析するために、お客様は Kinesis Data Stream の出力からデータを利用するようにアプリケーションを設定することができます。アプリケーションは、AWS Lambda 関数、Amazon Kinesis Data Firehose、Amazon Kinesis Data Analytics、またはKinesis Client Libraryを使用するカスタムアプリケーションにすることができます。Kinesis Data Firehose は、OpenSearch、Datadog、Splunk、New Relic、Sumo Logic などの統合済みの配信先にデータを配信できるフルマネージドサービスです。すでにデータ分析システムを使用している場合は、Kinesis Firehose でサポートされているかどうかを確認し、そのオプションを使用することができます。Kinesis Data Firehose は、お客様の Lambda 関数を呼び出して、受信するCloudFront ログを変換し、変換されたデータを配信先に配信することができます。これにより、cs-uri-query フィールドからCMCD メトリクスをオンザフライで解析・抽出し、各パラメータの新しいフィールドを作成することで、分析システムによるレポート構築を容易にします。

次の図は、CloudFrontのロギングオプションの概要を示しています。

図1 – CloudFrontのロギングオプション

ログ配信パイプラインの選択と実装が完了したら、ダッシュボード、レポート、アラームの作成など、観測可能な機能の実装を開始することができます。

CloudFront リアルタイムログの Amazon OpenSearch Service への配信を設定する方法の記事が公開されているので、ログの有効化と Kinesis Data Stream の設定方法を学ぶためにお役立てください。また、独自のログ変換とエンリッチメントを作成するためのベースラインとして機能する Lambda 関数も含まれています。この記事では、マネージドサービスとサーバーレスサービスである Amazon Managed Grafana と Amazon Timestream 基づく別のソリューションを紹介します。

CMCD で拡充された CloudFront ログのリアルタイムダッシュボード

図2 – CloudFront のログを表示する Grafana ダッシュボード

ソリューションでは、クエリー文字列によって提供される CMCD メトリクスで拡充された CloudFront のリアルタイムログを使用しています。AWS Lambda 関数は、Kinesis Data Stream の出力にアタッチされています。これはログを解析し、クエリー文字列から新しいフィールドを構築するために CMCD メトリクスを抽出します。その後、Lambda は Timestream データベースにデータを挿入します。データベースに格納されたデータを可視化するために、Amazon Grafana が使用されます。

豊富で強力なデータセットがあれば、ダッシュボードでの表現に無限のバリエーションが生まれます。お客様のあらゆるニーズに対応する単一のバージョンを作成する方法はありません。この投稿では、お客様のニーズに合わせて変更できるサンプルを提供します。例えば、あなたにとって重要でないチャートを削除し、欠けていても役に立つチャートを追加することができます。ソリューションをインストールするには、Github リポジトリからクローンして、Readme にあるインストール手順に従ってください。

Grafana でダッシュボードを作成するためのベストプラクティスによると、ダッシュボードを設計する際に答えるべき最初の質問は、「どんなストーリーを伝えるのか、またはそのゴールは何か」です。ダッシュボードはまた、認識するための労力を減らすものであって、それを増やすものであってはならない：何かを理解するために、どれだけ難しく考える必要があるか？さらに、ダッシュボードのデータソースとして使用する Timestream データベースへのクエリの回数を減らすなど、必要なものだけに料金を支払うようにしなければなりません。このことを念頭に置いて、このソリューションには異なる目的おそらく異なるユーザーによって使用される2つのダッシュボードが含まれています。

QoE ダッシュボードは、リバッファリング率、同時再生数、平均再生時間、スループット測定値、バッファ長、転送バイトなど、QoE とビジネスに関するインサイトを提供します。国、ASN、デバイスタイプ（モバイル、スマートテレビ、デスクトップ）、ストリーミングフォーマット（HLS、DASH）、CloudFront ディストリビューションなど、さまざまなディメンションで QoE を監視することができます。

図3 – QoE ダッシュボードの例

Troubleshooting ダッシュボードは、QoE の問題を監視するだけでなく、問題が発生した場合のトラブルシューティングを支援します。ビデオセッションレベルでリバッファリングの割合を測定する「リバッファリング率」チャートが含まれています。このグラフを使用して、リバッファリング比率の割合が通常値より高くなると、アラームを設定することができます。このアラームは、根本的な原因を見つけるためのトラブルシューティングのトリガーとなります。これを支援するためにダッシュボードでは、バッファが枯渇するシグナルが発生する前に処理されたリクエストの CloudFront ログからの抜粋が表示されます。このデータは、CloudFront のパフォーマンス調査のためのサポートチケットを開くために使用することができます。

図4 Troubleshooting ダッシュボードの例

まとめ

CMCD の利点は、特定のニーズに合わせたカスタム QoE 可観測性を構築でき、根本原因の分析が容易になることです。この投稿では、CMCD 仕様の概要と、CloudFront でどのように使用できるかを説明しました。また、CMCD によって拡充されたCloudFrontのログから構築された Grafana ダッシュボードのサンプルも提供しました。このサンプルには、ログを生成するテストクライアントが含まれており、CMCD の機能に慣れるだけでなく、このデータを使用して新しいインサイトを構築するための検証を行うことができます。

本記事は、「Improving video observability with CMCD and CloudFront」と題された記事の翻訳となります。
翻訳は Solutions Architect の長谷川 純也が担当しました。