このページは Cloud Translation API によって翻訳されました。

送信元を構成する

Media CDN の送信元は、さまざまな方法で構成できます。このページでは、送信元の構成方法について説明します。

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

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

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

コンソール

Google Cloud コンソールで、[Media CDN] の [送信元] ページに移動します。

[送信元] に移動
[オリジンを作成] をクリックします。
送信元の名前を入力します。例: cloud-storage-origin。
（省略可）説明を入力します。
[送信元のアドレス] で [Google Cloud Storage バケットを選択] を選択します。
Cloud Storage バケットを参照して選択します。
Cloud Storage の場合は、デフォルトのプロトコルとポート設定をそのまま使用します。
省略可: 送信元のリクエストヘッダーが、クライアントによって送信されたヘッダーやルートレベルのヘッダーアクションによって操作されたヘッダーよりも優先されるようにするようにオーバーライドするには、次の操作を行います。
1. [送信元のオーバーライドを有効にする] を選択します。
2. [ヘッダー] セクションで、1 つ以上の名前と値のペアを追加してヘッダーを指定します。
省略可: この送信元が到達不能になった場合に試行するフェイルオーバー送信元を選択します。このフィールドは後で更新できます。
[リダイレクト条件] を選択します。
[再試行条件] を選択します。
[最大試行回数] で、この送信元からキャッシュフィルを試行する最大回数を選択します。
省略可: 次のタイムアウト値を指定します。
1. [接続のタイムアウト] で、送信元の接続が確立されるまでの最大待機時間を選択します。
2. [レスポンスのタイムアウト] で、レスポンスが完了するまでの最大時間を選択します。
3. [読み取りタイムアウト] で、1 つの HTTP 接続またはストリームの読み取り間の最大待機時間を選択します。
省略可: [ラベルを追加] をクリックし、1 つ以上の Key-Value ペアを指定します。
[オリジンを作成] をクリックします。

gcloud

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

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

次のように置き換えます。

ORIGIN: 新しい送信元の名前
ADDRESS: バケット名（例: gs://my-bucket）

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

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

Media CDN バケット。 — Media CDN バケット（クリックして拡大）。

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

リクエストの認証

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

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

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

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

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

コンソール

Google Cloud コンソールで、[Media CDN] の [送信元] ページに移動します。

[送信元] に移動
送信元を選択して [編集] をクリックします。
プロトコルとして [HTTPS] または [HTTP] を選択します。HTTP の場合は、ポートも 80 として指定します。
[送信元を更新] をクリックします。

gcloud

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

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

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

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

Media CDN は、インターネットで到達可能な HTTP または HTTPS エンドポイントからコンテンツを pull できます。場合によっては、Media CDN にコンテンツの pull のみを許可し、不正アクセスを防ぐために認証を要求することもできます。Cloud Storage は IAM 権限でこの要望に対応しています。

Cloud Storage 送信元の場合は、次の操作を行います。

Media CDN サービスアカウントに、送信元として使用する Cloud Storage バケットに対する objectViewer IAM 権限を付与します。
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 を使用してバケットオブジェクトにアクセスを試みます。

あるプロジェクト内の 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 をこの名前に設定して送信元を作成する必要があります。

コンソール

Google Cloud コンソールで、[Media CDN] の [送信元] ページに移動します。

[送信元] に移動
[オリジンを作成] をクリックします。
送信元の名前を入力します。例: load-balancer-origin。
（省略可）説明を入力します。
[送信元アドレス] で [FQDN または IP アドレスを指定] を選択します。
Google Cloud ロードバランサの FQDN または IP アドレスを入力します。
省略可: この送信元が到達不能になった場合に試行するフェイルオーバー送信元を選択します。このフィールドは後で更新できます。
[再試行条件] を選択します。
[最大試行回数] で、この送信元からキャッシュフィルを試行する最大回数を選択します。
省略可: 次のタイムアウト値を指定します。
1. [接続のタイムアウト] で、送信元の接続が確立されるまでの最大待機時間を選択します。
2. [レスポンスのタイムアウト] で、レスポンスが完了するまでの最大時間を選択します。
3. [読み取りタイムアウト] で、1 つの HTTP 接続またはストリームの読み取り間の最大待機時間を選択します。
省略可: [ラベルを追加] をクリックし、1 つ以上の Key-Value ペアを指定します。
[オリジンを作成] をクリックします。

gcloud

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

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

次のように置き換えます。

LB_ORIGIN: 送信元の名前
LB_ADDRESS: FQDN または IP アドレス（例: origin-packager.example.com）

転送ルールの 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

送信元で送信元固有のホストの書き換えまたはヘッダーの変更が必要な場合は、次の 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.replace を true に設定します。

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

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

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 レスポンスコードを指定します。

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

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

送信元が意図したとおりに動作しない場合は、送信元のトラブルシューティングの方法を確認します。

送信元を構成する

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

コンソール

gcloud

リクエストの認証

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

コンソール

gcloud

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

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

コンソール

gcloud

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

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

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

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

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

次のステップ

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