送信元の概要

Media CDN を使用すると、コンテンツが Google Cloud 内、別のクラウド、またはオンプレミスのいずれでホストされているかに関係なく、送信元インフラストラクチャからコンテンツを取得できます。

各構成には 1 つ以上の送信元を関連付けることができます。送信元の構成により、Media CDN はインフラストラクチャに接続する方法、フェイルオーバー、再試行、タイムアウトの方法、接続時に使用するプロトコルを指定できます。

送信元には次の特徴があります。

  • 送信元はホストごと、ルートごとに定義できます。これにより、1 つの EdgeCacheService リソースを、マニフェスト、動画セグメント、その他の静的コンテンツなどを含む複数の送信元にマッピングできます。
  • 送信元には、HTTP/2、HTTPS、暗号化されていない HTTP/1.1 を介して到達できます。
  • 再試行とフェイルオーバーの動作は送信元ごとに構成され、ハードエラー(接続エラーなど)が発生した場合にサービスをフェイルオーバーしたり、HTTP 404 Not Found または HTTP 429 Too Many Requests レスポンスに基づいて再試行したりできます。
  • Media CDN の背後にある外部アプリケーション ロードバランサを送信元として構成することで、Google Cloud またはオンプレミス内のプライベート リソースにアクセスできます。
  • リダイレクト先の動作は送信元ごとに構成されます。Media CDN を有効にして、他の送信元サーバーへのリダイレクトを追跡できます。

送信元の要件

Media CDN が 1 MiB を超える送信元のレスポンスをキャッシュに保存できるようにするには、指定されていない限り、送信元に HEAD リクエストと GET リクエストの両方のレスポンス ヘッダーに以下を含める必要があります。

  • Last-Modified または ETag HTTP レスポンス ヘッダー(バリデータ)。
  • 有効な HTTP Date ヘッダー。
  • 有効な Content-Length ヘッダー。
  • Range GET リクエストに対する Content-Range レスポンス ヘッダー。Content-Range ヘッダーには、bytes x-y/z の形式で有効な値が必要です(z はオブジェクト サイズ)。

デフォルトの送信元プロトコルは HTTP/2 です。送信元が HTTP/1.1 のみをサポートしている場合は、送信元ごとにプロトコル フィールドを明示的に設定できます。

Origin のシールド

メディア CDN は、可能な限りキャッシュ フィルを最小限に抑えるように設計された、ディープ ティアのエッジ インフラストラクチャを提供します。

キャッシュ インフラストラクチャには、主に 3 つのレイヤがあります。

  1. ディープ エッジ キャッシュ。サービス プロバイダ ネットワーク内でトラフィックの大部分とオフロードを処理します。
  2. Google のピアリング エッジ。何千もの ISP に接続され、エッジ キャッシュの中間層キャッシュとして機能します。エッジ キャッシュが特定の ISP 内にない場合は、ユーザー向けのキャッシュとして機能します。
  3. Google ネットワーク内のロングテール キャッシュは、他のダウンストリーム キャッシュが送信元のそれよりも前からフィルします。これらのキャッシュは、大規模なファンインをサポートし、かなりのキャッシュ ストレージ容量を持ち、送信元のシールドとして機能します。

以下に、このトポロジの概要を示します。

トポロジの概要。
トポロジの概要(クリックして拡大)。

キャッシュのすべてのレイヤは、送信元の負荷をさらに削減するための折りたたみ(または結合)をリクエストします。大規模に確認された実際のワークロードに基づく:

  • キャッシュ フィルの 95% を超える場合は、キャッシュ フィルの費用とレイテンシを削減するために、リージョン内の専用のロングテール キャッシュ ノードを使用します。
  • 送信元と Google 独自のエッジ インフラストラクチャとの間のキャッシュ フィルは、完全に Google のグローバル プライベート バックボーン ネットワーク上で行われます。これにより、キャッシュ フィルのレイテンシが短縮され、信頼性が向上します。これらは、ライブ ストリーミング ワークロードにとってアクティブなメリットです。
  • 可能であれば、キャッシュ同士のクロスフィルを行います。これにより、キャッシュ フィル率をさらに低下させることができます。
  • Media CDN は、キャッシュ全体で大きなストレージ容量を持っているため、ロングテールで人気のないコンテンツであってもエビクション率を最小限に抑えます。

キャッシュ構成、ユーザー負荷、ワークロード(ライブとオンデマンドなど)、ユーザーの配信、ロングテール コンテンツの量(コーパスの合計サイズ)に応じてオフロード率が異なる場合があります。

リクエストの折りたたみ

リクエストの折りたたみによって、同じキャッシュキーの複数のユーザー ドリブン キャッシュ フィル リクエストが、エッジノードごとにアクティブに 1 つの送信元リクエストに折りたたまれます。

送信元のシールドと併用すると、送信元の負荷と下り(外向き)の帯域幅のニーズをさらに削減できます。これは Media CDN のデフォルトの動作です。

折りたたまれたリクエストでは、クライアント側のリクエストと(折りたたまれた)キャッシュ フィル リクエストの両方がログに記録されます。折りたたみセッションのリーダーは、元のフィル リクエストを行うために使用されます。つまり、送信元には、そのクライアントのみのヘッダー(User-Agent を含む)が表示されます。

同じキャッシュキーを共有しないリクエストは、折りたためません。

Origin の接続

以下のセクションでは、Media CDN が送信元に接続する方法、HTTP リクエストが作成される方法、リクエストを認証する方法について説明します。

サポートされている送信元とプロトコル

Media CDN は、次のような公開アクセス可能な HTTP エンドポイントを送信元として直接サポートしています。

送信元への接続は、安全なトンネルと Google のグローバル バックボーン ネットワークを介して行われます。

次の表に、サポートされている送信元プロトコルの詳細を示します。

プロトコル サポート対象 SSL(TLS)が必要
HTTP/2 はい(デフォルト)
HTTPS(TLS を介した HTTP/1.1)
HTTP/1.1 いいえ

Media CDN はデフォルトで HTTP/2(h2)を使用して送信元に接続します。HTTP/2 と HTTPS にはどちらも、公的に信頼できる有効な TLS(SSL)証明書が必要です。有効な証明書とは、有効期限がなく、公開認証局によって署名され、送信元に送信されたホスト名に一致するサブジェクト代替名を持つ証明書です。

注:

  • 送信元が HTTP/2 をサポートしていない場合は、HTTP(HTTP/1.1)または HTTPS(TLS 経由の HTTP/1.1)に送信元ごとにプロトコルを明示的に設定できます。
  • HTTPS または HTTP/1.1 を送信元プロトコルとして構成する場合、Media CDN は代替プロトコル(HTTP/2 など)をネゴシエートしません。同様に、HTTP/2 を構成するときは、送信元の接続動作を明示的に指定するために、接続は HTTP/1.1 にフォールバックしません。
  • Media CDN は、プロトコルに基づいて正しいポートを自動的に使用します。HTTP の場合はポート 80、HTTPS と HTTP/2 の場合はポート 443 になります。

送信元のリクエスト ヘッダー

送信元に接続すると、Media CDN はデフォルトでクライアント リクエストからの Host ヘッダーを使用します。

次の表に、さまざまな構成シナリオで送信元から受信リクエストで確認できる内容を示します。

クライアント リクエスト EdgeCacheService.hostRewrite EdgeCacheOrigin.hostRewrite originAddress ホストヘッダー /
送信元での TLS SNI
media.example.com なし なし backend.example.com media.example.com
media.example.com service.example.com なし backend.example.com service.example.com
media.example.com なし origin.example.com backend.example.com origin.example.com
media.example.com service.example.com origin.example.com backend.example.com origin.example.com
media.example.com service.example.com origin.example.com gs://vod-content-bucket バケット名に基づいて自動的に設定される

プライマリ送信元とフェイルオーバー送信元が同じ routeRule 構成または hostRewrite 構成を共有している場合は、これらの送信元に同じホストヘッダーが表示されます。

Cloud Storage バケットを送信元として使用する場合、Cloud Storage バケットでは代替ホストヘッダー値がサポートされていないため、hostRewrite 設定は無視されます。ホストヘッダーは、バケット名に基づいて自動的に設定されます。

リクエスト(HTTP/3、HTTP/2、HTTPS リクエストの場合)内の TLS SNI(Server Name Indication)値は、送信元に送信されるホストヘッダーと同じ値に設定されます。

ルートごとの構成のホストヘッダーの書き換えについては、サービスルートの構成をご覧ください。送信元ごとのオーバーライド アクションの設定については、リダイレクトをフォローしない送信元のフェイルオーバーをご覧ください。

フェイルオーバーとタイムアウト

以降のセクションでは、これらの構成オプションについて説明します。

  • タイムアウト: Media CDN が送信元への接続またはリクエストへの応答を待機する時間を決定します。
  • 再試行: Media CDN が送信元への送信元 HTTP リクエストを再試行するかどうかと、どのような条件で再試行するかを決定します。
  • フェイルオーバー: 最初の送信元が利用できない場合に、Media CDN がフェイルオーバー送信元への接続を試行するか、特定のステータス コードを返すかを決定します。

送信元のタイムアウト

タイムアウトを使用すると、送信元の再試行とフェイルオーバーの動作がトリガーされるタイミングと、後続のクライアント フェイルオーバーをトリガーできるタイミングを構成できます。

Media CDN がサポートする構成可能なタイムアウトは次のとおりです。

  • connectTimeoutmaxAttemptsTimeout は、Media CDN が使用可能なレスポンスを検出するまでの時間を制限します。

    どちらのタイムアウトにも、送信元がヘッダーを返すのと、フェイルオーバーとリダイレクトのどちらを使用するかを決定するのにかかった時間が含まれます。connectTimeout は、送信元の試行ごとに独立して適用されますが、maxAttemptsTimeout には、フェイルオーバーとリダイレクトを含むすべての送信元の試行に接続するために必要な時間が含まれます。リダイレクトに続くと、送信元への接続の試行が新たにカウントされ、構成された送信元に設定されている maxAttempts にカウントされます。

    Media CDN がリダイレクト以外のレスポンス(リダイレクトやフェイルオーバー送信元からなど)を受信すると、readTimeoutresponseTimeout の値が適用されます。リダイレクトされた送信元では、リダイレクトに遭遇した EdgeCacheOrigin に構成された connectTimeoutreadTimeoutresponseTimeout の値が使用されます。

  • responseTimeoutreadTimeout は、ストリーミングされたレスポンスにかかる時間を制御します。Media CDN がアップストリーム レスポンスを使用すると判断した後は、connectTimeoutmaxAttemptsTimeout のいずれも関係ありません。この時点で、readTimeoutresponseTimeout が有効になります。

Media CDN は、各 EdgeCacheOrigin によって設定された maxAttempts に関係なく、すべての送信元について最大 4 回の送信元試行を行います。Media CDN は、プライマリ EdgeCacheOriginmaxAttemptsTimeout 値を使用します。試行ごとのタイムアウト値(connectTimeoutreadTimeoutresponseTimeout)は、各試行の EdgeCacheOrigin に構成されます。

次の表に、タイムアウト フィールドを示します。

フィールド デフォルト 説明
connectTimeout 5 秒

Media CDN がリクエストを開始してから送信元が使用可能になるまでの最大時間。この時間が経過するとMedia CDN はレスポンスが使用可能かどうかを判断します。実際には、connectTimeout はリクエストの作成から DNS ルックアップの実行、TLS handshake、TCP/QUIC 接続の確立、さらには HTTP ステータス コードまでカバーします。

タイムアウトは 1 秒~ 15 秒の値にする必要があります。

maxAttemptsTimeout 15 秒

送信元に対するすべての接続試行の最大時間。この時間を超えるとクライアントにエラーを返します。これにはフェイルオーバー送信元に対する接続も含まれます。レスポンスが返される前にタイムアウトに達すると、HTTP 504 が返されます。

タイムアウトは 1 秒~ 30 秒の値にする必要があります。

この設定は、すべての送信元の接続試行(フェイルオーバー送信元を含む)の合計時間を定義します。これは、クライアントがコンテンツのストリーミング開始を待機する合計時間の上限を設定するためです。最初の maxAttemptsTimeout 値のみが使用されます。ここで、最初のは、指定されたルート用に構成された送信元によって定義されます。

readTimeout 15 秒

1 回の HTTP レスポンスの読み取り間の最大待機時間。readTimeoutresponseTimeout によって制限されます。HTTP レスポンスのすべての読み取りは、responseTimeout によって設定された期限までに完了する必要があります。タイムアウトは 1 秒~ 30 秒の値にする必要があります。レスポンスが完了する前にこのタイムアウトに達すると、レスポンスは切り捨てられ、ログに記録されます。

responseTimeout 30 秒

レスポンスが完了するまでに許容される最大時間。

タイムアウトは 1 秒~ 120 秒の値にする必要があります。

この期間は、最初のボディバイトが受信された時点から測定されます。レスポンスが完了する前にこのタイムアウトに達すると、レスポンスは切り捨てられ、ログに記録されます。

以下の例を考えてみましょう。

  • Origin A は「/segments/」へのリクエストと照合されます。maxAttemptsTimeout の値は 5smaxAttempts の値は 1failover_originOrigin B です。connectTimeout 値はデフォルトの 5s です。Origin A に接続しようとして、TLS 証明書が無効なため 1 秒以内に失敗した場合、Origin B への接続が成功するまでの残り時間が最大 4 秒です。

  • Origin C は、「/manifests/*」へのリクエストに一致し、maxAttemptsTimeout の値は 10smaxAttempts の値は 3failover_origin は構成されていません。connectTimeout 値はデフォルトの 5s です。Media CDN は Origin C への接続を最大 3 回試行し、接続が成功するまでに最大 10 秒(maxAttemptsTimeout 上限)かかります。

送信元のリクエストを再試行する

Media CDN は送信元の再試行をサポートし、送信元への失敗したリクエストの再試行を許可します。フェイルオーバー送信元(構成されている場合)を試行する前に現在の送信元を再試行できる回数を指定できます。

  • Media CDN は、構成された maxAttempts 値(デフォルトは 1)までプライマリ送信元に到達しようとします。
  • Media CDN は送信元の接続を最大で 3 回再試行した後、失敗して HTTP 502 Bad Gateway エラーをユーザーに返します。これには、フェイルオーバー送信元の接続も含まれ、この接続は 3 つの上限にカウントされます。
  • 送信元リソースを構成するときに、originAddress フィールドとオプションの failoverOrigin を使用してプライマリ送信元を構成できます。failoverOrigin は別の送信元リソースを指しています。

それぞれの送信元の retryConditions は、再試行をトリガーする失敗の種類を指定します。

条件 デフォルト 説明
CONNECT_FAILURE ✔️ エラー時の再試行には、ルーティング、DNS と TLS handshake のエラー、TCP/UDP タイムアウトが含まれます。
HTTP_5XX 任意の HTTP 5xx ステータス コードで再試行する。
GATEWAY_ERROR 5xx と似ていますが、ステータス コード 502503504 にのみ適用されます。
RETRIABLE_4XX 409429 など、再試行可能な 4xx ステータス コードについて再試行します。
NOT_FOUND HTTP 404 ステータス コードで再試行する。
FORBIDDEN HTTP 403 ステータス コードで再試行する。

送信元間のアクティブなヘルスチェック、ラウンドロビン、負荷認識ステアリングが必要な場合は、プライマリ送信元として外部アプリケーション ロードバランサを構成できます。

フェイルオーバーの動作

次の表に、フェイルオーバーの動作とクライアントが監視するレスポンスを示します。

シナリオ フェイルオーバーが構成済み ユーザー向けのステータス
Media CDN は送信元への接続を試み、2 回の試行後に HTTP レスポンスを受信しません(デフォルト)。 いいえ HTTP 502 Bad Gateway
Media CDN がプライマリ送信元への接続を試み、接続に失敗します(TLS handshake エラー)。構成済みのフェイルオーバー送信元に対して試行が行われ、HTTP 404 エラーが返されます。 HTTP 404 Not Found
Media CDN はプライマリ送信元とフェイルオーバー送信元の両方への接続を試みますが、HTTP ステータス コードを受信しません。 HTTP 502 Bad Gateway

Media CDN が構成された retryConditions に一致するステータス コード(HTTP 404 Not Found エラー、HTTP 429 Too Many Requests エラーなど)を受信し、その後の再試行とフェイルオーバー送信元のリクエストが引き続き失敗する場合は、HTTP 送信元の試行回数を使い切ると、502 Bad Gateway エラーがクライアントに返されます。

送信元のフェイルオーバーのベスト プラクティス

フェイルオーバーまたは負荷分散のために複数の送信元を構成する場合は、メディア コンテンツと VaryETagLast-Modified ヘッダーの動作が送信元間で一貫していることを確認します。

ベスト プラクティスとして、信頼できる送信元にのみ送信元のリダイレクトを構成します。それぞれの送信元が EdgeCacheService によって提供されるコンテンツを生成するため、リダイレクト チェーン内のすべての送信元が信頼できることを確認してください。

次のステップ