送信元を構成する

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

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

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

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

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 バイトのランダムな値）を含むカスタム リクエスト ヘッダーを追加します。オリジンは、この値を含まないリクエストを拒否できます。

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

送信元が HTTP/2 をサポートしている場合は、プロトコルを明示的に設定する必要はありません。HTTPS（TLS 経由の HTTP/1.1）または HTTP/1.1（TLS なし）のみをサポートする送信元については、次の手順で protocol フィールドを明示的に設定します。

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

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

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

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

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

Cloud Storage バケットの権限を変更するには、ストレージ管理者ロール（roles/storage.admin）が必要です。

Media CDN サービス アカウントは Media CDN プロジェクトによって所有されており、プロジェクトのサービス アカウントのリストには表示されません。サービス アカウントは、明示的に許可するプロジェクトの Media CDN リソースにのみアクセス権を付与します。

サービス アカウントの作成をトリガーするには、少なくとも 1 つの Media CDN リソースを作成する必要があります。ほとんどの場合、これは Cloud Storage バケットに接続されている EdgeCacheOrigin リソースです。

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

PROJECT_NUMBER は、プロジェクト番号に置き換えます。

本番環境の送信元として使用されている既存のストレージ バケットへの公開アクセスを削除する前に、構成が伝播されるまで少なくとも 10 分待ちます。

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 functions）。

動画マニフェストの提供用の外部アプリケーション ロードバランサの送信元と、セグメント ストレージ用の 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 に設定して、暗号化されていない接続にフォールバックできます。これは開発またはテストでのみ行うことをおすすめします。

フレキシブル シールディングのリージョンを構成する

オリジンを作成または更新するときに、柔軟なシールドのリージョンを構成できます。

gcloud edge-cache origins update ORIGIN \
    --origin-address=ADDRESS \
    --flex-shielding=REGION

name: ORIGIN
originAddress: ADDRESS
# ... Other fields
flexShielding:
  flexShieldingRegions:
    - REGION
# ... Other fields

オリジン フェイルオーバーを構成する

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

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

次に、基本的なフェイルオーバー 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 互換バケットを送信元として使用する
• サービスルートを構成する