Origin の接続とシールド

Media CDN を使用すると、コンテンツが Google Cloud、別のクラウド、オンプレミスでホストされている場合でも、送信元インフラストラクチャからコンテンツを簡単に取得できます。

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

送信元の機能は次のとおりです。

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

送信元の要件

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

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

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

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

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

送信元のリダイレクトは、信頼できる送信元のみに制限することをおすすめします。各送信元が EdgeCacheService から提供されるコンテンツを生成するため、リダイレクト チェーン内のすべての送信元を信頼してください。

Origin のシールド

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

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

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

このトポロジの概要は次のとおりです。

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

すべてのレイヤのキャッシュでは、送信元の負荷をさらに軽減するために、リクエストの重複(「結合」)がサポートされています。モニタリングされた実際のワークロードに基づく:

  • 95% を超えるキャッシュ フィルでは、キャッシュ フィルのコストとレイテンシを低減するために、リージョン内の専用「ロングテール」キャッシュ階層が使用されます。
  • 送信元と Google のエッジ インフラストラクチャ間のキャッシュ フィルは、Google のグローバル プライベート バックボーン ネットワークを介して完全に行われます。これにより、キャッシュ フィルのレイテンシが短縮され、信頼性が向上します。どちらもライブ ストリーミング ワークロードに有効なメリットがあります。
  • キャッシュは相互にフィルフィルするので、キャッシュ フィルレートがさらに低下します。
  • Media CDN のキャッシュは大きなストレージ容量であるため、ロングテールのエビクション率を最小限に抑えます。

キャッシュ構成、ユーザー負荷、ワークロード(ライブとオンデマンドなど)、ユーザー分散、提供する「ロングテール」コンテンツの量(コーパスの合計サイズ)に応じて、オフロード率が異なる場合があります。リージョン間でユーザーにサービスを提供できます。

リクエストの折りたたみ

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

Origin Shield と組み合わせることで、送信元の負荷と下りの帯域幅の必要性が軽減され、Media CDN のデフォルトの動作となります。

折りたたみリクエストには、クライアント向けリクエストとキャッシュ フィル リクエストの両方が記録されます。折りたたみセッションの「リーダー」は、送信元の入力リクエストに使用されます。つまり、送信元はそのクライアントのヘッダー(User-Agent を含む)にのみ認識されます。

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

Origin の接続

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

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

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

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

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

プロトコル サポート対象 SSL(TLS)が必要
HTTP/2 はい(デフォルト) あり
HTTPS(HTTP/1.1 over TLS) あり あり
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 元のアドレス ホストヘッダー /
送信元の 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 設定は無視されます。ホストヘッダーはバケット名に基づいて自動的に設定されます。

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

ルートごとの構成のホストヘッダーの書き換えについては、高度なルーティングをご覧ください。送信元ごとのオーバーライド アクションの設定については、例: リダイレクトせずにフェイルオーバーするをご覧ください。

プライベート Cloud Storage バケットの使用

メディア CDN は、インターネットで到達可能な HTTP(S) エンドポイントからコンテンツを pull できます。場合によっては、Media CDN にコンテンツの取得のみを許可し、不正アクセスを防ぐために、認証が必要になることがあります。Cloud Storage は、IAM 権限を通じてこれをサポートしています。

Cloud Storage の送信元では、次のことができます。

  1. 送信元として使用する Cloud Storage バケットに対する objectViewer IAM 権限を Media CDN サービス アカウントに付与します。
  2. allUsers 権限を削除する
  3. (省略可)allAuthenticatedUsers 権限を削除します。

Cloud Storage バケットの権限を変更するには、ストレージ管理者の IAM 役割が必要です。

Media CDN サービス アカウントは Media CDN プロジェクトで所有されており、プロジェクトのサービス アカウントのリストには表示されません。

サービス アカウントは次の形式を持ち、明示的に許可するプロジェクトのメディア CDN リソースへのアクセス権のみを付与します。

service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Media CDN にバケットへのアクセス権を付与するには、Google Cloud Console または gsutil ツールを使用して、サービス アカウントに objectViewer ロールを付与します。

gsutil iam ch \
serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com:objectViewer gs://BUCKET

特定のバケットの allUsers ロールからすべての権限を削除するには、次のコマンドを実行します。

gsutil iam ch -d allUsers gs://BUCKET

公開アクセスが削除されたことを確認するには、シークレット ブラウザ ウィンドウを開き、https://storage.googleapis.com/BUCKET/object.ext を使用してバケット オブジェクトにアクセスしようとします。

あるプロジェクトの Edge キャッシュ サービスに別のプロジェクトの Cloud Storage バケットへのアクセスを許可するには、そのプロジェクトの Media CDN サービス アカウントにストレージ バケットへのアクセスを許可します。

これを行うには、service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.comPROJECT_NUM が、アクセスを必要とする Edge Cache サービスを含むプロジェクトのプロジェクト番号であることを確認します。特に、異なるメディア CDN 環境(開発、ステージング、本番環境)を持つ複数のプロジェクトや、動画アセットまたはメディア アセットを含む別のプロジェクトがある場合は、複数のプロジェクトでこの手順を繰り返します。

そのルートの署名付きリクエストを有効にしなくても、Cloud Storage 送信元へのアクセスを保護できます。

プライベート Cloud Storage を構成しても、キャッシュに保存されたコンテンツが Media CDN から直接アクセスされることはありません。個々のユーザーに対して署名付きリクエストを発行する方法については、署名付きリクエストをご覧ください。

リクエストの認証

リクエストが Media CDN から発生していることを確認する必要がある場合は、次の 2 つの方法があります。

  1. 接続 IP アドレスが Media CDN のキャッシュ フィル範囲にあることを確認します。これらの範囲はすべての顧客の間で共有されますが、送信元に接続するときは常に Edge Cache サービスで使用されます。
  2. 送信元で検証するトークン値(ランダムな 16 バイト値など)を含むカスタム リクエスト ヘッダーを追加します。送信元は、この値を含まないリクエストを拒否できます。

ルートごとにリクエスト ヘッダーを設定する方法については、カスタム ヘッダーのドキュメントをご覧ください。

次のオリジン リダイレクトを構成する

Media CDN は、キャッシュ フィルにおいて、送信元から返されたリダイレクトを内部でサポートしており、リダイレクト レスポンスをクライアントに直接返すことはありません。メディア CDN が送信元のリダイレクトに従うように構成されている場合、Media CDN はリダイレクト ロケーションからコンテンツを取得してから、リダイレクトされたレスポンスをクライアントに返します。メディア CDN はドメイン間のリダイレクトをたどります。

送信元のリダイレクトは、信頼できる送信元のみに制限することをおすすめします。各送信元が EdgeCacheService から提供されるコンテンツを生成するため、リダイレクト チェーン内のすべての送信元を信頼してください。

次の送信元のリダイレクトを有効にするには、次の構成を EdgeCacheOrigin に追加します。

name: MY_ORIGIN
  originAddress: "DOMAIN_NAME"
  maxAttempts: 2
  originRedirect:
    redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Media CDN は、リダイレクトで指定されたすべてのサーバーに到達するために指定されたプロトコルのみを使用します。Media CDN のすべてのサーバーが、目的のプロトコルをサポートするようリダイレクトされていることを確認します。特に、プロトコルが HTTPS、HTTP/2 または HTTP/3 に設定されている場合、Media CDN は安全でないリダイレクトに従うために HTTP/1.1 接続にフォールバックしません。リダイレクトされた送信元に送信されたホストヘッダーは、リダイレクトされた URL と一致します。Media CDN は、EdgeCacheOrigin 試行ごとに 1 回のリダイレクトを行ってから、最終レスポンスを返すか、再試行またはフェイルオーバーの状態を評価します。

redirectConditions 設定では、Media CDN が各送信元のリダイレクトに従う HTTP レスポンス コードを指定します。

条件 説明
MOVED_PERMANENTLY レスポンス コード「HTTP 301」のリダイレクトに従う
FOUND レスポンス コード「HTTP 302」のリダイレクトに従う
SEE_OTHER レスポンス コード「HTTP 303」のリダイレクトに従う
TEMPORARY_REDIRECT レスポンス コード「HTTP 307」のリダイレクトに従う
PERMANENT_REDIRECT レスポンス コード「HTTP 308」のリダイレクトに従う

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

以降のセクションでは、構成方法について説明します。

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

送信元のタイムアウトを調整する

タイムアウトを使用すると、再試行とフェイルオーバーの動作をトリガーできます。また、クライアント側のフェイルオーバーをトリガーする前にクライアントが待機する時間を短縮できます。

次に、Media CDN がサポートする構成可能なタイムアウトについて説明します。

  • connectTimeoutmaxAttemptsTimeout は、メディア CDN が使用可能なレスポンスを見つけるまでの時間を制限します。

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

    Media CDN がリダイレクトやフェイルオーバーなどによるリダイレクト以外のレスポンスを検出した場合は、readTimeoutresponseTimeout の値が適用されます。リダイレクトされた送信元では、リダイレクトが発生した EdgeCacheOrigin 用に構成された connectTimeoutreadTimeoutresponseTimeout の値が使用されます。

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

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

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

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

Media CDN がリクエストを開始してから送信元が使用可能になるまでの最大時間。この時間が経過するとメディア 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 秒までの値にする必要があります。

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

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

  • 送信元 A は「/segments/」へのリクエストに一致し、maxAttemptsTimeout は 5 秒、maxAttempts は 1、failover_origin は送信元 B として構成されます。connectTimeout はデフォルトで 5 秒に設定されています。送信元 A に接続しようとして、無効な TLS 証明書が原因で 1 秒以内に失敗すると、送信元 B への接続に成功するまでに 4 秒ほどかかります。

  • 送信元 C は「/manifests/*」へのリクエストに一致し、maxAttemptsTimeout は 10 秒、maxAttempts は 3、failover_origin は構成されていません。connectTimeout はデフォルトで 5 秒に設定されています。メディア CDN は送信元 C への接続を最大 3 回試行し、最大 10 秒(maxAttemptsTimeout)で接続できます。

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

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

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

各送信元の retryConditions は、再試行をトリガーする障害のタイプを指定します。

条件 Default 説明
CONNECT_FAILURE ✔️ 障害発生時の再試行には、ルーティング、DNS、TLS handshake エラー、TCP/UDP タイムアウトなどがあります。
HTTP_5XX HTTP 5xx レスポンス コードで再試行します。
GATEWAY_ERROR 5xx に似ていますが、レスポンス コード 502、503、または 504 にのみ適用されます。
RETRIABLE_4XX 再試行可能な 4xx レスポンス コード(409、429 など)を再試行します。
NOT_FOUND HTTP 404 で再試行します。
FORBIDDEN HTTP 403 で再試行します。

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

フェイルオーバーの動作

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

シナリオ フェイルオーバーが構成されている ユーザー向けのステータス
Media CDN は送信元への接続を試行します。2 回試行されると HTTP レスポンスを受信しません(デフォルト)。 なし HTTP/1.1 502(不正なゲートウェイ)
Media CDN がプライマリ送信元に接続を試み、接続に失敗します(TLS handshake エラー)。構成されたフェイルオーバーの送信元に対して試行が行われ、HTTP 404 を返します。 あり HTTP 404(未検出)
Media CDN はプライマリとフェイルオーバーの両方の送信元への接続を試みますが、HTTP ステータス コードを受信しません。 あり HTTP/1.1 502(不正なゲートウェイ)

すべての送信元の接続が失敗した場合、Media CDN は HTTP 502(Bad Gateway)ステータス コードを返します。

Media CDN が受信したステータス コード(HTTP 404(Not Found)や HTTP 429(Too Many Requests)など)が、後続のリクエストが失敗した場合、最後に観測されたステータス コードがクライアントに返されます。

例: リダイレクトなしのフェイルオーバー

基本的なフェイルオーバーの EdgeCacheOrigin 構成は次のとおりです。

  name: FAILOVER_ORIGIN
  originAddress: FAILOVER_DOMAIN_NAME

Media CDN は、ルートの送信元をフェイルオーバー送信元に再試行する前に、最大 3 回再試行します。この構成では、プライマリ送信元を 3 回試行した後、Media CDN は FAILOVER_ORIGIN に対して 1 つのリクエストを試行します。フェイルオーバーの送信元も正常に応答できなかった場合、Media CDN は最後に受信したステータス コードを返すか、ステータス コードを受信しない場合は HTTP 502(不正なゲートウェイ)レスポンスを返します。

キャッシュ フィルのレイテンシは、再試行とフェイルオーバー イベントの数が増えるにつれて増加します。送信元のタイムアウト値(connectTimeout など)を増やすと、送信元サーバーの過負荷やビジー状態の待機時間が長くなるため、キャッシュ フィルのレイテンシにも影響します。

次の例は、フィル リクエストを MY_ORIGIN に送信する構成を示しています。この構成により、メディア CDN は接続エラー(DNS、TCP、TLS などのエラー)、送信元からの HTTP 5xx レスポンス、HTTP 404 を再試行します。2 回試行すると、FAILOVER_ORIGIN にフェイルオーバーします。

設定した送信元で合計 4 回試行されます(元の試行回数と最大 3 回の再試行回数)。送信元ごとに maxAttempts を構成すると、フェイルオーバーの前に再試行する回数を決定できます。

  name: MY_ORIGIN
  originAddress: DOMAIN_NAME
  maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
  failoverOrigin: FAILOVER_ORIGIN
  # what conditions trigger a retry or failover
  retryConditions:
  - CONNECT_FAILURE
  - HTTP_5xx # any HTTP 5xx response
  - NOT_FOUND # retry on a HTTP 404
  timeout:
    maxAttemptsTimeout: 10s # set a deadline for all retries and failover

送信元で送信元固有のホストの書き換えや他のヘッダー固有の変更が必要な場合は、次の originOverrideAction 構成例を使用して設定します。

  name: FAILOVER_ORIGIN
    originAddress: "FAILOVER_ORIGIN_HOST"
    originOverrideAction:
      urlRewrite:
        hostRewrite: "FAILOVER_ORIGIN_HOST"
      headerAction:
        requestHeadersToAdd:
        - headerName: "Authorization"
          headerValue: "AUTH-KEY"
          replace: true

完成した構成は次のとおりです。

  name: MY_ORIGIN
  originAddress: DOMAIN_NAME
  maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
  failoverOrigin: FAILOVER_ORIGIN
  # what conditions trigger a retry or failover
  retryConditions:
  - CONNECT_FAILURE
  - HTTP_5xx # any HTTP 5xx response
  - NOT_FOUND # retry on a HTTP 404
  timeout:
    maxAttemptsTimeout: 10s # set a deadline for all retries and failover
  name: FAILOVER_ORIGIN
    originAddress: "FAILOVER_ORIGIN_HOST"
    originOverrideAction:
      urlRewrite:
        hostRewrite: "FAILOVER_ORIGIN_HOST"
      headerAction:
        requestHeadersToAdd:
        - headerName: "Authorization"
          headerValue: "AUTH-KEY"
          replace: true

前の例では、originOverrideAction.hostRewrite 設定は、この送信元を指すルートに構成されている既存のヘッダー書き換えよりも優先されます。

特定の送信元からリクエストされた、送信元ごとの一意の requestHeadersToAdd ヘッダーを使用できます。一般的なユースケースでは、静的な Authorization ヘッダーを追加します。これらのヘッダー操作は送信元リクエスト中に実行されるため、送信元ごとに追加されたヘッダーは、同じフィールド名の既存のヘッダーに置換または追加されます。デフォルトでは、Media CDN は既存のヘッダーに追加します。既存のヘッダーを置き換えるには、headerAction.replacetrue に設定します。

例: リダイレクトによるフェイルオーバー

たとえば、次の EdgeCacheOrigin リソースを構成し、EdgeCacheService リソースのルートがキャッシュ フィルに PrimaryOrigin を使用するように構成したとします。

name: PrimaryOrigin
  originAddress: "primary.example.com"
  maxAttempts: 2
  failoverOrigin: "SecondaryOrigin"
  retryConditions: [CONNECT_FAILURE]
  originRedirect:
    redirectConditions: [FOUND, TEMPORARY_REDIRECT]
name: SecondaryOrigin
  originAddress: "secondary.example.com"
  maxAttempts: 3
  originRedirect:
    redirectConditions: [FOUND, TEMPORARY_REDIRECT]

この例では、Media CDN がキャッシュ フィルを実行すると、Media CDN は PrimaryOrigin の構成を読み取り、それに応じて応答します。

Media CDN が primary.example.com に接続し、送信元に接続を試みたとします。primary.example.com が成功のレスポンスを返すと、Media CDN はそのレスポンスをキャッシュ フィルに使用します。

primary.example.comLocation: b.example.com への HTTP 302 Found リダイレクトを返すとします。次に、2 番目の試行で送信元に接続すると、Media CDN は b.example.com へのリダイレクトに従います。この場合、Media CDN は次の処理を行います。

  • b.example.com が成功のレスポンスを返すと、Media CDN はそのレスポンスをキャッシュ フィルに使用します。
  • b.example.com からリダイレクトまたは失敗のレスポンスが返された場合、Media CDN は構成済みの SecondaryOrigin にフェイルオーバーします。これは、この例では PrimaryOrigin が 2 つの maxAttempts 用に構成されているためです。

Media CDN が SecondaryOrigin にフェイルオーバーすると、Media CDN は SecondaryOrigin 構成を使用して secondary.example.com への接続を試みます。これは、1 番目の接続元に試行して、3 番目の接続を試行します。

この場合、Media CDN は次の処理を行います。

  • secondary.example.com が成功のレスポンスを返すと、Media CDN はそのレスポンスをキャッシュ フィルに使用します。
  • secondary.example.comLocation: c.example.com への HTTP 302 Found リダイレクトを返す場合、Media CDN は c.example.com に接続しようとします。この例では、SecondaryOrigin に対する試行 #2 で、全体として試行 #4 です。

c.example.com に接続しようとして正常なレスポンスが返された場合、Media CDN はそのレスポンスをキャッシュ フィルに使用します。Media CDN が構成しているリダイレクトを返されると、送信元への最大試行回数を超えたため 502 Bad Gateway(不正なゲートウェイ)エラーが返されます。Media CDN は、EdgeCacheOrigin の構成に関係なく、すべての送信元で最大 4 回の試行を行います。最後に、Media CDN が c.example.com に接続できない場合、Media CDN は 504 Gateway Timeout または 502 Bad Gateway レスポンスを返します。

送信元間のヘルスチェック、ラウンドロビン、負荷対応ステアリングが必要な場合は、外部 HTTP(S) ロードバランサをプライマリ送信元として構成できます。

送信元の構成

以下のセクションでは、Cloud Storage バケットと外部 HTTP(S) ロードバランサの送信元を含む、共通の送信元タイプを構成する方法について説明します。

Cloud Storage の統合

Media CDN は、コンテンツのバックエンドとして Cloud Storage バケットをサポートしています。各サービスは、ホスト、パス、その他のリクエスト属性のルートを構成することで、複数のバケットを参照できます。

Cloud Storage バケットは、送信元リソースの作成時に送信元アドレスとして gs://my-bucket などのバケット URL を使用して構成されます。

コンソール

  1. Google Cloud Console で、[メディア CDN の送信元] ページに移動します。

    Media CDN 送信元に移動

  2. [Create origin] をクリックします。

  3. 送信元の名前を入力します。例: cloud-storage-origin

  4. 送信元の説明を入力します(省略可)。

  5. [送信元アドレス] で [Google Cloud Storage バケットを選択] を選択します。

  6. Cloud Storage バケットを参照します。

  7. Cloud Storage の場合は、デフォルトのプロトコルとポートの設定をそのまま使用します。

  8. (省略可)この送信元がアクセス不能になった場合に試してみるフェイルオーバーの送信元を選択します。このフィールドは後で更新できます。

  9. [再試行条件] を選択します。

  10. [最大試行回数] で、この送信元からキャッシュへの最大入力回数を選択します。

  11. (省略可)タイムアウトを調整します。

    1. [接続タイムアウト] で、送信元の接続が確立されるまでの最大待機時間を選択します。
    2. [レスポンスのタイムアウト] で、レスポンスを完了できる最大時間を選択します。
    3. [読み取りタイムアウト] で、1 つの HTTP 接続またはストリームの読み取り間の最大待機時間を選択します。
  12. (省略可)この送信元のラベルを 1 つ以上入力します。

  13. [Create origin] をクリックします。

gcloud

gcloud edge-cache origins create コマンドを使用します。

gcloud edge-cache origins create cloud-storage-origin --origin-address="gs://my-bucket"
Create request issued for: [cloud-storage-origin]

originAddress: "gs://my-bucket"

バケットがマルチリージョン、デュアルリージョン、リージョンのいずれでも同じです。

サービスを構成するときに、ビデオ オンデマンド コンテンツを 1 つのバケットにルーティングし、ライブ ストリーミング コンテンツを 2 番目のバケットにルーティングできます。各ワークフローを異なるチームで管理する場合に役立ちます。同様に、eu-media.example.com を EU にあるマルチリージョンの Cloud Storage バケットにルーティングしてキャッシュ フィルのレイテンシを短縮し、us-media.example.com(またはパス、ヘッダーまたはクエリ パラメータ)を米国ベースのストレージ バケットに送信します。

メディア CDN バケット
メディア CDN バケット(クリックして拡大)

低レイテンシのライブ ストリーミングなど、書き込みレイテンシが重要な場合は、可能な限りユーザーに近いリージョンの Cloud Storage エンドポイントを構成できます。

送信元として外部 HTTP(S) ロードバランサを使用する

Compute Engine、GKE、オンプレミスの送信元でアクティブなヘルスチェック、ラウンドロビン、負荷認識のステアリングが必要な場合は、送信元として、外部 HTTP(S) ロードバランサを構成することができます。

これにより、Media CDN の背後でライブ ストリーミング パッケージャを構成したり、Traffic Director によって管理されている Envoy プロキシのグループを構成してオンプレミスインフラストラクチャに接続したりできます。

ロードバランサを使用すると、次の目的でバックエンドを構成できます。

動画マニフェストを提供するための外部 HTTP(S) ロードバランサの送信元と、セグメント ストレージ用の Cloud Storage の送信元を組み合わせたアーキテクチャは次のようになります。2 つの送信元は異なるルートにマッピングされています。

エッジ キャッシュのデプロイ
Edge キャッシュのデプロイ(クリックして拡大)

外部 HTTP(S) ロードバランサを送信元として構成するには、IP アドレスまたはパブリック ホスト名を指定して、ロードバランサの転送ルールを指す送信元リソースを作成する必要があります。SSL(TLS)証明書と最新の HTTP バージョン(HTTP/2 と HTTP/3)で必要になるため、公開ホスト名(ドメイン名)を使用することをおすすめします。

また、次の点も確認してください。

  • ロードバランサには、Edge Cache サービスに使用するホスト名と一致するルートがあります。
  • (または)ロードバランサが送信元として構成されているルートの urlRewrite.hostRewrite を構成していること。
  • ロードバランサには、これらのホスト名に対して構成されている公的に信頼できる SSL(TLS)証明書がある。

たとえば、ロードバランサの転送ルールを指すパブリック ドメイン名が origin-packager.example.com の場合、originAddress をこの名前に設定して送信元を作成します。

コンソール

  1. Google Cloud Console の [メディア CDN] ページに移動します。
    Media CDN に移動
  2. [送信元] タブをクリックします。
  3. [Create origin] をクリックします。
  4. 送信元の名前を入力します。例: load-balancer-origin
  5. 送信元の説明を入力します(省略可)。
  6. [送信元アドレス] で [Specify FQDN or IP address] を選択します。
  7. Google Cloud ロードバランサの FQDN または IP アドレスを入力します。
  8. Media CDN が送信元に接続するプロトコルとポートを選択します。
  9. (省略可)この送信元がアクセス不能になった場合に試してみるフェイルオーバーの送信元を選択します。このフィールドは後で更新できます。
  10. [再試行条件] を選択します。
  11. [最大試行回数] で、この送信元からキャッシュへの最大入力回数を選択します。
  12. (省略可)タイムアウトを調整します。
    1. [接続タイムアウト] で、送信元の接続が確立されるまでの最大待機時間を選択します。
    2. [レスポンスのタイムアウト] で、レスポンスを完了できる最大時間を選択します。
    3. [読み取りタイムアウト] で、1 つの HTTP 接続またはストリームの読み取り間の最大待機時間を選択します。
  13. (省略可)この送信元のラベルを 1 つ以上入力します。
  14. [Create origin] をクリックします。

gcloud

gcloud edge-cache origins コマンドを使用します。

gcloud edge-cache origins create lb-origin --origin-address="origin-packager.example.com"
Create request issued for: [lb-origin]

originAddress: "origin-packager.example.com"

転送ルールの IP アドレスを送信元アドレスとして使用する場合、またはロードバランサに SSL 証明書が添付されていない場合は、プロトコルを HTTP に設定して暗号化されていないようにフォールバックできます。この操作は、開発またはテスト目的でのみ行うことをおすすめします。

送信元プロトコルの構成

HTTPS のみ(HTTP/1.1 over TLS)または HTTP/1.1(TLS なし)のみをサポートする送信元の場合、protocol フィールドを明示的に設定します。

コンソール

  1. Google Cloud Console の [メディア CDN] ページに移動します。
    Media CDN に移動
  2. [送信元] タブをクリックします。
  3. 送信元を選択して、[編集] をクリックします。
  4. プロトコルとして [HTTPS] または [HTTP] を選択します。
  5. [HTTP] を選択した場合は、ポート 80 を選択します。
  6. [送信元を更新] をクリックします。

gcloud

gcloud edge-cache origins コマンドを使用します。

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

このコマンドを実行すると、送信元が更新され、次のような結果が返されます。

Update request issued for: [LEGACY_ORIGIN]
protocol: HTTPS

送信元で HTTP/2 がサポートされている場合は、プロトコルを明示的に設定する必要はありません。

接続のトラブルシューティング

HTTP 502(ゲートウェイ タイムアウト)や HTTP 500(内部サーバーエラー)などの HTTP 50x エラーが発生する場合は、次の点を考慮してください。

  • 送信元ホスト名が Google Public DNS で解決され、解決された IP アドレスが期待どおりであることをテストします。DNS レコードを最近変更した場合、リゾルバがキャッシュに古いアドレスを残す可能性があります。

  • 送信元がわずかHTTP/1.1 をサポートし、HTTP/2 をサポートしていない場合は、protocol使用する送信元のフィールドHTTPまたはHTTPSこれは、HTTP2 を置き換えるものです。特に指定しない限り、メディア CDN は HTTP/1.1 接続にフォールバックしません。

  • Cloud Logging のリクエストログに正しい送信元 IP アドレスが含まれていることを確認します。

  • 送信元に有効な(公的に信頼できる)期限切れでない SSL(TLS)証明書があることを確認します。

  • HTTP/2 トレーラーはサポートされていません。また、配信元サーバーへのリクエストには「TE」リクエスト ヘッダーが含まれていません。レスポンスに含まれるトレーラーは、キャッシュ保存やクライアントに返されません。

送信元のフェイルオーバーのトラブルシューティング

送信元のフェイルオーバーが期待どおりに機能しない場合は、次の点を検討します。

  • フェイルオーバー送信元で、適切なホストヘッダーの書き換えが構成されていることを確認してください。

  • プライマリ オリジンが、オリジンのリダイレクトとフェイルオーバーに対応するのに十分な maxAttemptsTimeoutmaxAttemptstimeouts で構成されていることを確認します。送信元のリダイレクトは、maxAttempts 設定に対して別の接続試行としてカウントされます。

次のステップ