送信元を構成する

Media CDN のオリジンはさまざまな方法で構成できます。このページでは、オリジンを構成する方法について説明します。

Cloud Storage バケットを送信元として構成する

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

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

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

これは、バケットがマルチリージョン、デュアルリージョン、リージョンのいずれであるかに関係ありません。

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

低レイテンシのライブ配信など、書き込みレイテンシが重要な場合は、リージョン Cloud Storage エンドポイントをユーザーにできるだけ近づけて構成できます。

リクエストの認証

リクエストが Media CDN から送信されていることを確認するには、次のいずれかのサポートされている方法を使用します。

• 接続 IP アドレスが Media CDN のキャッシュ フィル範囲内であることを確認します。これらの範囲はすべてのお客様で共有されますが、オリジンに接続するときに EdgeCacheService リソースによって常に使用されます。
• オリジンで検証するトークン値（ランダムな 16 バイト値など）を含むカスタム リクエスト ヘッダーを追加します。オリジンは、この値が含まれていないリクエストを拒否できます。

送信元プロトコルを構成する

HTTPS（TLS 経由の HTTP/1.1）または HTTP/1.1（TLS なし）のみをサポートする送信元の場合は、次の手順で protocol フィールドを明示的に設定します。

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

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

限定公開の Cloud Storage バケットを構成する

Media CDN は、インターネットで接続可能なあらゆる HTTP または HTTPS エンドポイントからコンテンツを取り込むことができます。場合によっては、Media CDN にのみコンテンツの取り込みを許可し、不正なアクセスを防止するために、認証を必須にすることをおすすめします。Cloud Storage は IAM 権限でこの要望に対応しています。

Cloud Storage オリジンの場合は、次の操作を行います。

• オリジンとして使用している Cloud Storage バケットに対する objectViewer IAM 権限を Media CDN サービス アカウントに付与します。
• allUsers 権限を削除する
• 省略可: allAuthenticatedUsers 権限を削除します。

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

Media CDN サービス アカウントは Media CDN プロジェクトによって所有されているため、プロジェクトのサービス アカウントのリストには表示されません。

サービス アカウントの形式は次のとおりです。明示的に許可するプロジェクトの Media CDN リソースにのみアクセス権を付与します。

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

Media CDN にバケットへのアクセス権を付与するには、サービス アカウントに objectViewer ロールを付与します。

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
--member=serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
--role=roles/storage.objectViewer

gcloud storage buckets remove-iam-policy-binding コマンドを使用して、特定のバケットの allUsers ロールに付与されている権限を削除します。たとえば、バケットが allUsers に objectViewer ロールを付与している場合は、次のコマンドを使用して付与を削除します。

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
--member=allUsers --role=roles/storage.objectViewer

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

1 つのプロジェクト内の EdgeCacheService リソースが別のプロジェクトの Cloud Storage バケットにアクセスできるようにするには、そのプロジェクトの Media CDN サービス アカウントにストレージ バケットへのアクセス権を付与します。

これを行うには、service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com の PROJECT_NUM が、アクセスが必要な EdgeCacheService リソースを含むプロジェクトのプロジェクト番号であることを確認します。複数のプロジェクトに対してこの操作を繰り返すことができます。特に、一部のプロジェクトに異なる Media CDN 環境（開発環境、ステージング環境、本番環境など）があり、別のプロジェクトに動画またはメディア アセットが含まれている場合は、この操作を繰り返す必要があります。

そのルートで署名付きリクエストを有効にせずに、Cloud Storage オリジンへのアクセスを保護できます。

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

外部アプリケーション ロードバランサを送信元として構成する

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

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

ロードバランサでは、以下に対するバックエンドを構成できます。

• Compute Engine VM インスタンス グループ。
• ネットワーク エンドポイント グループ（Compute Engine VM や Google Kubernetes Engine クラスタなど）。
• サーバーレス ネットワーク エンドポイント グループ（Cloud Run、App Engine、Cloud Run 関数）。

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

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

また、次の点も確認する必要があります。

• ロードバランサに、EdgeCacheService リソースに使用されているホスト名に一致するルートがあるか、ロードバランサが送信元として構成されているルートに urlRewrite.hostRewrite が構成されている。
• ロードバランサには、これらのホスト名用に一般に信頼されている SSL（TLS）証明書が構成されています。

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

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

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

送信元のフェイルオーバーを構成する

以降のセクションでは、送信元のフェイルオーバー動作を構成する方法について説明します。

リダイレクト フォローなしの送信元フェイルオーバー

次の例は、基本的なフェイルオーバー EdgeCacheOrigin 構成を示しています。

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN はルートのプライマリ送信元を最大で 3 回再試行した後、フェイルオーバー送信元を試行します。この構成では、プライマリ送信元を 3 回試行した後、Media CDN は FAILOVER_ORIGIN に対して 1 回のリクエストを試みます。フェイルオーバー オリジンも正常に応答しなかった場合、Media CDN はオリジン レスポンスの全体を返すか、ステータス コードが受信されなかった場合は HTTP 502 Bad Gateway レスポンスを返します。

キャッシュ フィルのレイテンシは、再試行の回数とフェイルオーバー イベントの数とともに増加します。 オリジンのタイムアウト値（connectTimeout など）を増やすと、過負荷またはビジー状態のオリジン サーバーが応答するのを待機する時間が長くなるため、キャッシュ フィルのレイテンシがさらに増加します。

次の例は、MY_ORIGIN にフィリング リクエストを送信する構成を示しています。この構成により、Media CDN は接続エラー（DNS、TCP、TLS のエラーなど）、送信元からの HTTP 5xx レスポンス、または HTTP 404 Not Found に対して再試行します。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

リダイレクト フォローによる送信元のフェイルオーバー

たとえば、次の 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 が送信元へのコンタクトの試行 #1 として primary.example.com に接続するとします。primary.example.com が成功のレスポンスを返した場合、Media CDN はそのレスポンスをキャッシュ フィルに使用します。

ここで、primary.example.com が HTTP 302 Found Redirect を Location: b.example.com に返すとします。すると、送信元へのコンタクトの試行 #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.com が HTTP 302 Found Redirect を Location: c.example.com に返した場合、Media CDN は c.example.com へのコンタクトを試みます。この例では、これは SecondaryOrigin に対する試行 #2 で、全体の試行 #4 です。

c.example.com へのコンタクトの試行で成功のレスポンスが返された場合、Media CDN はそのレスポンスをキャッシュ フィルに使用します。試行で Media CDN が従うように構成されているリダイレクトが返された場合、MEDIA CDN は HTTP 502 Bad Gateway エラーを返します。これは、送信元へのコンタクトの最大試行回数を超えたためです。Media CDN は、EdgeCacheOrigin の構成に関係なく、すべての送信元で最大 4 回の試行を行います。最後に、Media CDN が c.example.com へのコンタクトに失敗した場合、Media CDN は 504 Gateway Timeout レスポンスまたは 502 Bad Gateway レスポンスのいずれかを返します。

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

送信元のリダイレクトフォローを構成する

Media CDN は、クライアントに直接リダイレクト レスポンスを返すのではなく、キャッシュ フィル中に送信元から内部的に返されたリダイレクトフォローをサポートします。Media CDN が送信元のリダイレクトに従うように構成されている場合、Media CDN はリダイレクトのロケーションからコンテンツを取得してから、キャッシュしてリダイレクトされたレスポンスをクライアントに返します。 Media 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 レスポンス コードを指定します。

送信元固有のホストリライトまたはヘッダー変更を構成する

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

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.replace を true に設定します。

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

送信元のトラブルシューティング

オリジンが想定どおりに動作しない場合は、オリジンのトラブルシューティング方法をご覧ください。

次のステップ

• 限定公開の Amazon S3 互換バケットを送信元として使用する
• サービス ルートを構成する