HLSコンテンツステアリングによるグローバルストリーミングの可用性の向上

♪ (HLSコンテンツステアリングによる グローバルストリーミングの可用性の向上)

WWDCにようこそ Appleの HLSストリーミングチームの Zheng Naiweiです 今日のテーマは HLSの新機能 コンテンツステアリングや それがグローバルストリーミングの 可用性をどう改善するかです 今日のネットワーク接続の 規模はグローバルです ストリーミングメディアプロバイダ はコンテンツを 世界中に配信しています しかしコンテンツをグローバルに 配信する上で 業界が解決すべき 課題は膨大です Appleの HLSストリーミングチームでも こうした課題や問題を 認識しており 解決策の提供に 務めています 今日は可用性の問題に フォーカスします 特に ネットワーク混雑緩和と エラー回復についてです これらの問題を 理解するために 例を見てみましょう アジアで人気の ストリーミング業者が 次の3つの国で CDNインフラストラクチャを デプロイするとします 中国 日本 シンガポールです このグラフには 完璧に動作している 状態が示されています 中国のユーザーは 中国のCDNから 日本のユーザーは日本のCDN からストリーミングし 両方のCDNネットワークが 可能な範囲で動作しています では少し変えてみましょう しばらくして 中国のCDNからストリーミング する中国のユーザーが CDNネットワークが オーバーロードするレベルまで 増加したとします 従来のHLS技術では このネットワーク混雑 問題を 完全解決するのは 困難です 新しいユーザーを別のCDNに 割り当てられても 既存のクライアントに 別のCDNを使うよう 指示するのは難しく 既存のトラフィックは 引き続き現在のCDNに オーバーロードします しかし新しいHLS コンテンツステアリング機能では コンテンツ供給者は 自分のステアリング サーバをホストすることで この問題を解決できます これで最新のHLSクライアント で再度チャネルを確立し 最新のCDNポリシーで 更新されます 例えば 既存の中国の クライアントの30%を 日本のCDNに切り替えるよう ポリシー更新を送れます ポリシー更新を受け取った クライアントは 変更を引き受けて ネットワークトラフィックを 日本のCDNにリダイレクトします これで中国のCDNのネットワーク 混雑が緩和されました しかしネットワーク混雑は 多くの可用性問題の たった1つにすぎません ネットワーク障害が 起こったらどうなるでしょうか 別の例を見てみましょう 日本のCDNから日本のユーザー へのネットワークパスに 地域的障害が あったとします 従来のHLS技術では コンテンツ提供者はフォールバック バリアントストリームを マスタープレイリストに リストし それでクライアントが 稼働中のCDNに 達するまでリストを 辿る形になります しかしこのアプローチは コンテンツ供給者が リアルタイムでリストされた CDNの順番や 優先順位を 変えられないという点では 予備的なものに すぎません でもステアリングサーバ があれば クライアントをほぼリアルタイムで 最新のCDN優先順位で 更新することができます 少し戻って より効果的なエラー回復 という点でクライアントを 楽にする方法を見てみましょう ネットワーク障害が起こる前 日本のクライアントは ステアリングサーバから CDN優先順位の更新を 定期的にプルしています 最新の更新では 日本のクライアントは 次のCDN優先リストを受けます そこでは日本のCDNが 再優先され シンガポール 中国と 続きます 現在 日本のユーザーは日本の CDNからストリーミング中です そこでネットワーク障害が 発生すると 日本のCDNは 優先リストから ペナルティとマークされます クライアントは優先リストの 次のCDNに移ります このケースではシンガポールの CDNで ネットワークトラフィックが リダイレクトされます これで日本のユーザーは 配信を中断なく 視聴できるように なりました この例ではHLS新機能 コンテンツステアリングの ハイレベルな概要を お見せしました さらに掘り下げて この機能を皆さまの ストリームへと統合する 方法を説明します これは全ての利用可能な バリアントを複製した 異なるCDN URLの 単純なリストです 先程の説明の通り こういったプレイリストには CDN優先順位の不変かつ 最終的な順番があります コンテンツ供給者は これを再生中に 後で変えることはできません ではコンテンツステアリングのサポートを このプレイリストに追加する 方法を説明します 導入された変更が少ないので 驚かれるかもしれません 実際 この変更には 現行のHLSクライアント との後方互換があります では追加したものを 見ていきましょう 一番顕著なのは 各パスウェイが通常 1つのCDNに対応する 各可変のストリームなのが PATHWAY-ID属性で 可変ストリームを 異なるパスウェイに グループ化できる点です この例では可変ストリームを それぞれ中国と日本 シンガポールのCDNに合わせ CN JP SGのパスウェイに グループ化しています しかしパスウェイには より先端のユースケースを 可能にする異なるCDNからの 可変ストリームが含まれます クライアントがパスウェイを 選択すると そのパスウェイからの 可変ストリームのみが バリアント選択に 適合します CONTENT-STEERINGタグの PATHWAY-ID属性は 再生開始で使う 初期パスウェイを指定します よってこのケースでは クライアントは 初期再生時にCNパスウェイに 属するバリアントストリーム のみを選択できます SERVER-URI属性は コンテンツステアリングサーバの 場所を指定します クライアントはコンテンツ ステアリング更新を このURIからプルします しかしプレイリストにメディア グループが含まれていたら？ 問題ありません それでもコンテンツステアリングを シンプルに有効化できます 各パスウェイに メディアグループを複製し 固有のGROUP-IDで 割り当てるだけです 例えばこのプレイリストの オーディオグループは CNパスウェイの CN-audioに 設定されたGROUP-IDで パスウェイごとに 複製されるなどです HLSクライアントが Content Steeringタグのある マスタープレイリストを ロードすると 微妙に異なるスタートアップ ルーチンをトリガーします まず初期バリアントストリーム 選択の実行時 初期パスウェイからのバリアント ストリームしか使われません その後はいつも通り 選択したバリアントストリーム とそのメディアセグメントの の読み込みと再生を行います しかし通常の再生 ルーチンと並行で クライアントはバックグラウンドで 周期的なSteering Manifest リクエストを開始します Steering Manifest リクエストとはどんなものか 見てみましょう シンプルな HTTP GETリクエストで マスタープレイリストURLに 基づき SERVER-URI属性 からこの解決されたURIに 送信されています ステアリングサーバは Steering Manifestで応答します 例を使ってフォーマットを 分解してみましょう Steering Manifestは JSONドキュメントです ステアリングサーバは カスタムのSteering Manifestを クライアントごとに作れます これでステアリングサーバには 管理型ネットワークトラフィック を作るという素晴らしい ポテンシャルが得られます このSteering Manifestで 最も重要なプロパティは PATHWAY-PRIORITY フィールドです これはプロパティに命令される パスウェイIDの一覧で 最初のものが 再優先されます この例では CNのパスウェイが最も 優先され JP SGと続いています ステアリングサーバから Steering Manifestを 受信次第 クライアントは コンテンツステアリング評価を 実施して別のパスウェイに 切り替えるかどうか 判断します まず クライアントが 選択に不適合な バリアントストリームを 除外します これには ネットワークエラーで バリアントストリームが 含まれます また通常のバリアント 選択と同様に サポートされないコーデックの バリアントストリームもです 選択されるのは 最低1つの適合する バリアントストリームと 全ての適合するパスウェイで 優先順位が最も 高いものです 選択されたパスウェイが 現在使用中の 現在使用中の パスウェイと異なる場合 クライアントはすぐに 新しいパスウェイに切り替えます 適するパスウェイが 選ばれないか 既に選択済みのパスウェイを 使用中の場合 クライアントは何もせず 現在のパスウェイの 使用を続行します 最後に クライアントは ステアリングサーバから 最新の更新をプルするよう 次のSteering Manifest リクエストを スケジュールします ではスケジューリングは どう機能するのでしょうか Steering Manifestを また見てみましょう 次のSteering Manifest リクエスト送信までに クライアントが待機する 秒数を指定する TTLフィールドが あります この例では クライアントが Steering Manifestの パスウェイ優先リストで コンテンツステアリング評価を 行った後 次のSteering Manifestを 300秒 つまり5分で スケジュールします ステアリングサーバが 各Steering Manifestレスポンスで TTL値を変更可能になり クライアントの次の リクエストスケジュールの長さに 影響しているのに 気付いたでしょうか またステアリング サーバにとっては 各クライアントのTTL値 に乱数性を注入して サーバ負荷を分散 できるのも便利です さらに 任意の RELOAD-URIフィールドが クライアントに次の Steering Manifesiを 行う場所を伝えます ステアリングサーバは このフィールドを活用して クライアント別のセッション データ状態を注入し 次のリクエストにエコー バックされるようにできます ここまでコンテンツステアリングの 主な技術について 詳しく見てきました では先程の例に戻り 内部のしくみを 見てみましょう このケースでは 中国のユーザーは全員 Steering Manifestを 再優先されたCN パスウェイで受け取り ユーザー数増加のため 対応する中国CDNで オーバーロードが 起こっています そのためステアリングサーバが 稼働を開始し 中国ユーザーの30%に 別のSteering Manifestを送り 再優先パスウェイは JPに変更されます コンテンツステアリング評価を 実施後 中国のクライアントの 30%は JPパスウェイに切り替え ネットワークトラフィックを 日本のCDNにリダイレクトし 中国CDNのネットワーク 混雑は解決されます 要約すると 今日はコンテンツステアリングの HLS新機能の紹介や その仕組み ストリーム内での統合方法を 説明しました この素晴らしい機能により グローバルストリーミングの 可用性を最適に調整できます 技術的な部分の詳細は 下の動画リンク 「HLS Content Steering Specification」をご覧ください 実はこのプレイリストと Steering Manifest評価も Apple最新のHTTP Live Streaming Toolsで サポートされています HLS Interest IETFフォーラムの 業界の皆様から いただいたフィードバックを もとに改善いたしました 今後もフィードバックや ご意見を大歓迎しています また HLSコンテンツステアリングは 今年のWWDC Seedビルドの 開発者やユーザーの皆様に お使いいただけます そのため より良いグローバル ストリーミングを さらなる可用性で配信し 今すぐHLS Steeringを ご自身のストリーミング に統合し 顧客により優れたストリーミング 体験を提供しましょう ご視聴ありがとうございました ♪