メディア ワークロードのベスト プラクティス

このページでは、メディア ワークロードに Cloud Storage を使用する際のベスト プラクティスについて説明します。これらのワークロードには多くの場合、Media CDN、Live Stream API、Transcoder API、Video Stitcher API などのさまざまな Google Cloud プロダクトが含まれます。

概要

Google Cloud は、次のタイプのメディア ワークロードを最適化するソリューションを提供します。

  • メディア制作: コンピューティング負荷が高く、ハイ パフォーマンス コンピューティングに GPU を使用することが多い、映画のポストプロダクション（動画編集を含む）などのワークロードが挙げられます。多くの場合、Cloud Storage に存在するメディア関連データは、Compute Engine または Google Kubernetes Engine で実行されているアプリケーションによって処理され、プロセスの出力は Cloud Storage に書き戻されます。これらのワークロードでは、Cloud Storage から GPU のアイドル時間が短いコンピューティング クラスタへの集約的な読み書きのスループットをスケーリングする必要があります。また、読み書きのレイテンシを低くする必要もあります。これはテール レイテンシの短縮に不可欠です。
  • メディア アセット管理: メディア アセットを整理して、効率的な保存、取得、使用を実現します。
  • コンテンツの提供および配信: ビデオ オンデマンド（VoD）やライブ ストリーミング サービスなど、ユーザーに対するメディアのストリーミングが含まれます。VoD の場合、ユーザーがコンテンツ配信ネットワーク（CDN）にキャッシュ保存されていないコンテンツをリクエストすると、コンテンツは Cloud Storage バケットから取得されます。ライブ ストリーミング リクエストの場合、コンテンツは Storage バケットに書き込まれ、CDN から同時に読み取られます。

メディア ワークロードのベスト プラクティス

メディア ワークロードに適用されるベスト プラクティスについては、以降のセクションをご覧ください。

データ転送

Storage Transfer Service を使用して、オンプレミス ソース（ビデオカメラやオンプレミス ストレージなど）から Cloud Storage に 1 TiB を超える未加工のメディア ファイルをアップロードします。Storage Transfer Service を使用すると、オブジェクト ストレージ システムとファイル ストレージ システムの間でデータをシームレスに移動できます。小規模な転送の場合は、転送シナリオに基づいて、Cloud Storage との間でデータを転送するサービスか、ファイル システム間でデータを転送するサービスを選択します。

バケットのロケーション

コンピューティング リソースを必要とするワークロード（メディア制作など）の場合は、コンピューティング リソースと同じリージョンに、またはデュアルリージョンでバケットを作成する必要があります。この方法により、処理ワークロードの読み書きのレイテンシを短縮し、費用や帯域幅を削減することで、パフォーマンスを最適化できます。バケットのロケーションの選択に関するガイダンスについては、バケットのロケーションに関する考慮事項をご覧ください。

ストレージ クラス

選択すべきストレージ クラスは、メディア ワークロードのタイプによって異なります。さまざまなメディア ワークロードに推奨されるストレージ クラスのタイプは次のとおりです。

  • アーカイブ動画などのメディア アセットを管理する場合は、バケットのデフォルトのストレージ クラスを Archive Storage にする必要があります。可用性やアクセスのニーズが異なるオブジェクトには、別のストレージ クラスを指定できます。
  • メディア制作やコンテンツ配信のワークロードでは、Cloud Storage バケットからデータが頻繁に読み取られるため、データを Standard Storage に保存する必要があります。

バケットのストレージ クラスの選択に関するガイダンスについては、ストレージ クラスをご覧ください。

データ ライフサイクル管理

メディア アセットを管理するには、ライフサイクル構成を定義して、バケットのオブジェクト ライフサイクルを管理する必要があります。オブジェクトのライフサイクル管理機能を使用すると、オブジェクトの有効期間（TTL）の設定、非現行バージョンのオブジェクトの保持、費用を管理しやすくするためのオブジェクトのストレージ クラスのダウングレードなど、データのライフサイクルを管理できます。

データ アクセス パターンが予測可能な場合は、バケットのライフサイクル構成を設定できます。データのアクセス パターンが不明な場合や予測不能な場合は、バケットの Autoclass 機能を設定できます。Cloud Storage は Autoclass により、頻繁にアクセスされないデータをコールド ストレージ クラスに自動的に移動します。

コンテンツの提供および配信ワークロードのベスト プラクティス

VoD のワークロードでもライブ ストリーミングのワークロードでも、目標は、エンドユーザーの動画プレーヤーで動画を再生する際、再生エラー、再生開始の遅延、バッファリングを回避することです。これらのワークロードでは、多数の同時視聴者を考慮して読み取りをスケーリングする必要もあります。いずれの場合も、顧客トラフィックの読み取りは CDN を経由する必要があります。

コンテンツの提供および配信ワークロードに適用されるベスト プラクティスについては、以降のセクションをご覧ください。

CDN を効果的に使用する

Cloud Storage バケットの前にコンテンツ配信ネットワーク（CDN）を使用すると、コンテンツがキャッシュに保存されてレイテンシが短縮され、帯域幅の効率が高まるため、エンドユーザー エクスペリエンスが向上します。また帯域幅のコストを削減し、リソース使用率を最適化して、パフォーマンスを向上させることで、総所有コスト（TCO）を削減できます。Media CDN を使用すると、Media CDN のキャッシュ フィル費用がゼロになるため、エンドユーザーにコンテンツを配信する際の TCO を削減できます。また、他のサードパーティ CDN のソースとして機能させることができます。他の CDN を使用している場合でも、オリジンからではなくこの Media CDN キャッシュからコンテンツを配信すると、TCO を削減できます。

サードパーティ CDN を使用している場合、CDN Interconnect を使用すると、特定のプロバイダによりさまざまなロケーションで Google のエッジ ネットワークとのダイレクト ピアリング リンクを確立できます。こうしたリンクの 1 つを介して Google Cloudから送信されるネットワーク トラフィックの利点は、サポートされている CDN プロバイダに直接接続できることと、自動で割引料金が適用されることです。認定プロバイダの一覧については、Google 認定サービス プロバイダをご覧ください。

CDN の設定時に構成するオプションは次のとおりです。

オリジン シールドのロケーションを選択する

オリジン シールドのロケーションは、CDN と Cloud Storage の間のキャッシュです。CDN でオリジン シールドのロケーションを選択できる場合、Cloud Storage バケットのリージョンに近いオリジン シールドと、エンドユーザー トラフィックの集中ロケーションに近いオリジン シールドのどちらを選択すればよいのかについては、CDN のガイドラインを参照してください。オリジン シールドは、オリジン サーバーの過負荷を防ぐ保護対策です。オリジン シールドに対応した CDN では、オリジンと CDN の間に追加のキャッシュを設けることで、送信元のオフロードを向上させることができます。たとえば Media CDN は、可能な限りキャッシュ フィルを最小限に抑えるように設計された多層エッジ インフラストラクチャを提供します。

リクエストの結合を有効にする

CDN でリクエストの折りたたみが有効になっていることを確認します。複数のリクエストを 1 つのリクエストにまとめると、Cloud Storage クラス B の運用費用を削減できます。CDN は分散キャッシュを世界中に展開していますが、複数のエンドユーザー リクエストを 1 つのオリジン リクエストにまとめる方法も用意されています。たとえば Media CDN は、同じキャッシュキーの複数のユーザー ドリブン キャッシュ フィル リクエストを、エッジノードごとに 1 つのオリジン リクエストに積極的にまとめることで、バケットに対するリクエストの数を減らします。

CDN の再試行動作を構成する

HTTP 5xx レスポンス コード（502、503、504）を伴うサーバーの問題が発生した場合の、CDN の再試行を構成してください。CDN はオリジンの再試行をサポートしているため、オリジンに対するリクエストが失敗した場合、再試行できます。ほとんどの CDN では、現在のオリジンの再試行回数を指定できます。Media CDN でのオリジン リクエストの再試行については、オリジン リクエストを再試行するをご覧ください。

コンテンツ配信のロケーションのオプション

CDN にキャッシュ保存されていないデータを Cloud Storage から読み取るワークロード（コンテンツの提供や VoD タイプのコンテンツの配信など）の場合は、バケットのロケーションを選択する際に次の要素を考慮してください。

  • 費用を最適化する場合、バケットを単一リージョンで作成するとストレージ費用が最も低くなります。
  • 可用性を最適化するには、次の点を考慮してください。
    • ほとんどのメディア ワークロードでは、デュアルリージョン バケットを使用することをおすすめします（可用性を高めるためにオブジェクトが 2 つのリージョンに複製されます）。
    • 地理的冗長性を持たせてコンテンツの提供や分析を行う必要があるユースケースでは、可用性を最大限に高めるためにマルチリージョンのバケットを使用します。
  • レイテンシを最適化してネットワーク費用を削減するには、次の点を考慮してください。
    • VoD の場合は、エンドユーザーの大部分がいる地域に最も近いリージョンか、トラフィックが最も集中しているリージョンを選択します。
    • ライブ配信中、バケットはトランスコーダからの書き込みリクエストと、コンテンツをキャッシュに保存してエンドユーザーに配信する CDN からの読み取りリクエストを受信します。ストリーミング パフォーマンスを向上させるには、コード変換に使用されるコンピューティング リソースと同じ場所に配置されているリージョン バケットを選択します。

ライブ配信の動画セグメントの長さを最適化する

ライブ配信の場合、動画セグメントが短いとロングテールの書き込みレイテンシの影響を受けやすくなるため、セグメント サイズを 2 秒以上にすることをおすすめします。ロングテールの書き込みレイテンシとは、アクセス頻度が低いかリクエスト数が少ないコンテンツにおける、書き込みオペレーションの速度の低下または遅延を指します。

バケットのロケーションとエンドユーザーの再生ロケーションの物理的距離は、転送時間に影響します。エンドユーザーがバケットのロケーションから遠い場合は、動画セグメントのサイズを大きくすることをおすすめします。

最適な視聴体験を提供するために、トランスコーダへの書き込みに再試行戦略とリクエスト ヘッジを使用し、Cloud Storage への書き込みの 2 秒を超えるロングテール レイテンシを軽減して、長いバッファリング時間（約 10 秒）を試すことをおすすめします。

QPS を徐々に増やす

Cloud Storage バケットの初期の IO 容量は、書き込みが 1 秒あたり 1,000 オブジェクト、読み取りが 1 秒あたり 5,000 オブジェクトです。ライブ配信ワークロードの場合、ガイドラインの方法では、1 秒あたり 1,000 件の書き込みと 5,000 件の読み取りから開始し、20 分ごとにリクエスト レートを 2 倍に増やすことで、リクエストを徐々にスケーリングします。この方法をとると、Cloud Storage が複数のサーバーに負荷を再分散し、再生の問題が発生する可能性が減ってバケットの可用性とレイテンシが向上します。

QPS が高いライブ配信イベントの場合は、バケットをプレウォーミングするか、バケットの階層型名前空間を有効にすることで、バケットにスケーリングを実装する必要があります。バケットにスケーリングを実装する際は、その前に次のタスクを行う必要があります。

オリジンへの QPS を見積もる

視聴者が 100 万人のライブ配信の場合、CDN は 100 万 QPS を受信します。CDN のキャッシュ ヒット率が 99.0% であると仮定すると、Cloud Storage へのトラフィックは 1% になります。QPS は視聴者数（100 万人）の 1%、つまり 10,000 QPS になります。この値は初期の IO 容量を超えています。

QPS をモニタリングし、スケーリング エラーのトラブルシューティングを行う

QPS をモニタリングし、スケーリング エラーのトラブルシューティングを行う必要があります。詳細については、Cloud Storage でのモニタリングの概要をご覧ください。読み取りと書き込みのリクエストをモニタリングするには、Google Cloud コンソールで、それぞれ「Read / List / Get リクエスト数の合計」グラフと「書き込みリクエスト数の合計」グラフを確認します。前のセクションで説明した徐々に増やすガイドラインよりも速くバケットの QPS をスケーリングすると、「429 Too many requests」エラーが発生する可能性があります。エラーを解決する方法については、429 Too many requests をご覧ください。

以降のセクションでは、オリジンへの QPS を見積もった後、バケットをスケーリングして QPS を高める方法について説明します。

バケットをプレウォーミングすることで、バケットに QPS スケーリングを実装する

バケットをプレウォーミングすることで、ライブ配信イベントの前にスケーリング プロセスを迅速化できます。ライブ配信イベントの前に、バケットに合成トラフィック（イベントで CDN のオリジン サーバーが受け取ると予想される最大 QPS に、CDN の予想キャッシュ ヒット率を考慮して 50% のバッファを加えたもの）を生成します。たとえば、オリジンへの QPS の見積もりが 10,000 の場合、イベントに向けてオリジンを準備するにあたり、シミュレート トラフィックの目標は 1 秒あたり 15,000 件になります。

トラフィックのシミュレーションには、以前のイベントのライブフィード ファイル（セグメントやマニフェストなど）またはテストファイルを使用できます。ウォームアップ プロセス全体で個別のファイルを用意してください。

このシミュレート トラフィックを生成するときは、1 秒あたり 5,000 リクエストから開始し、目標に達するまで徐々に増加させるという段階的なスケーリング アプローチをとります。推定負荷に達するよう、イベントの前に十分な時間を確保してください。たとえば、1 秒あたり 5,000 リクエストから始めて 20 分ごとに負荷を 2 倍にする場合、1 秒あたり 15,000 リクエストに達するまでには、約 30 分かかります。

オリジン サーバーは、トラフィックが安定するまで容量を維持します。オリジン サーバーの容量は、24 時間かけてベースライン レベルまで徐々に減少します。オリジン サーバーでライブ配信イベントの間に数時間のギャップがある場合は、各イベントの前にトラフィックをシミュレートすることをおすすめします。

階層型名前空間が有効になっているバケットを使用して初期 QPS を高める

階層型名前空間が有効になっている Cloud Storage バケットでは、HNS が有効になっていないバケットと比較して、初期 QPS が最大 8 倍になります。初期 QPS が高いと、データ集約型ワークロードのスケーリングが容易になり、スループットが向上します。階層型名前空間が有効になっているバケットの制限事項については、制限事項をご覧ください。

QPS をスケーリングする際、動画セグメントに連続した名前を付けないようにする

QPS をスケーリングする際、リクエストは複数のサーバーに再分配されます。しかし、すべてのオブジェクトでランダム化されていない接頭辞や連続した接頭辞が使用されていると、パフォーマンスのボトルネックが発生する可能性があります。そのため最適な負荷分散を実現するには、連続した名前ではなく完全にランダムな名前を使用します。ただし、連番やタイムスタンプをオブジェクト名の一部として使用する場合は、連番やタイムスタンプの前にハッシュ値を追加して、オブジェクト名をランダムなものにしてください。たとえば、使用する元のオブジェクト名が my-bucket/2016-05-10-12-00-00/file1 の場合、元のオブジェクト名の MD5 ハッシュを計算し、ハッシュの最初の 6 文字をオブジェクト名の接頭辞として追加します。新しいオブジェクトは my-bucket/2fa764-2016-05-10-12-00-00/file1. になります。詳細については、命名規則を使って負荷をキーの範囲に均等に分散するをご覧ください。動画セグメントに連続した名前を付けざるを得ない場合は、階層型名前空間が有効になっているバケットを使用して QPS を高めます。

ライブ配信ごとに異なるバケットを使用する

同時ライブ配信の場合、ライブ配信ごとに異なるバケットを使用すると、バケットの IO 上限に達することなく、読み取りと書き込みの負荷を効果的にスケーリングできます。また、スケーリングの遅延による大きな外れ値のレイテンシを短縮できます。

次のステップ