Media CDN の送信元はさまざまな方法で構成できます。このページでは、送信元を構成する方法について説明します。
Cloud Storage バケットを送信元として構成する
Media CDN は、コンテンツのバックエンドとして Cloud Storage バケットをサポートしています。各サービスは、ホスト、パス、その他のリクエスト属性のルートを構成することで、複数のバケットを参照できます。
Cloud Storage バケットは、送信元リソースの作成時にバケット URL（gs://my-bucket など）を送信元アドレスとして使用して構成されます。
コンソール
コンソールで、[Media CDN] ページに移動します。 Google Cloud
[送信元] タブをクリックします。
[オリジンを作成] をクリックします。
送信元の名前を入力します。例:
cloud-storage-origin。（省略可）説明を入力します。
[送信元のアドレス] で [Google Cloud Storage バケットを選択] を選択します。
Cloud Storage バケットを参照して選択します。
Cloud Storage の場合は、デフォルトのプロトコルとポートの設定を保持します。
省略可: 送信元のリクエスト ヘッダー が、クライアントによって送信されたヘッダーや ルートレベルのヘッダー アクションによって操作されたヘッダーよりも優先されるようにするようにオーバーライドするには、次の操作を行います。
- [送信元のオーバーライドを有効にする] を選択します。
- [ヘッダー] セクションで、1 つ以上の名前と値のペアを追加してヘッダーを指定します。
省略可: この送信元に到達できない場合に試行するフェイルオーバー オリジンを選択します。このフィールドは後で更新できます。
リダイレクト条件を選択します。
再試行条件を選択します。
[**最大試行回数**] で、この送信元からのキャッシュ フィルを試行する最大回数を選択します。
省略可: 次のタイムアウト 値を指定します。
- [**接続タイムアウト**] で、 送信元接続が確立されるまで待機する最大時間を選択します。
- [**レスポンス タイムアウト**] で、レスポンスが完了するまでの最大時間を選択します。
- [**読み取りタイムアウト**] で、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 リージョン（または、パス、ヘッダー、またはクエリ パラメータに一致する）を、米国ベースのストレージ バケットにルーティングします。
低レイテンシのライブ ストリーミングなど、書き込みレイテンシが重要な場合は、できるだけユーザーに近いリージョンの Cloud Storage エンドポイントを構成できます。
リクエストの認証
リクエストが Media CDN から送信されていることを確認するには、次のいずれかのサポートされている方法を使用します。
- 接続元の IP アドレスが Media CDN のキャッシュ フィル範囲内であることを確認します。これらの範囲はすべてのお客様で共有されますが、送信元に接続するときは常に
EdgeCacheServiceリソースによって使用されます。 - 送信元で検証するトークン値（16 バイトのランダムな値など）を含むカスタム リクエスト ヘッダーを追加します。これにより、送信元はこの値を含まないリクエストを拒否できます。
送信元プロトコルを構成する
送信元が HTTP/2 をサポートしている場合は、プロトコルを明示的に設定する必要はありません。
HTTPS（TLS 経由の HTTP/1.1）または HTTP/1.1（TLS なし）のみをサポートする送信元の場合は、次の操作を行って protocol フィールドを明示的に設定します。
コンソール
コンソールで、[Media CDN] ページに移動します。 Google Cloud
[送信元] タブをクリックします。
送信元を選択して [編集] をクリックします。
プロトコルとして [HTTPS] または [HTTP] を選択します。[HTTP] の場合は、ポートを
80と指定します。[送信元を更新] をクリックします。
gcloud
gcloud edge-cache origins update コマンドを使用します。
gcloud edge-cache origins update LEGACY_ORIGIN \
--protocol=HTTPS
LEGACY_ORIGIN は、送信元の名前に置き換えます。
限定公開の Cloud Storage バケットを構成する
Media CDN は、インターネットで接続可能なあらゆる HTTP または HTTPS エンドポイントからコンテンツを取り込むことができます。場合によっては、Media CDN にのみコンテンツの取り込みを許可し、不正なアクセスを防止するために、認証を必須にすることがあります。Cloud Storage は IAM 権限でこの要望に対応しています。
Cloud Storage 送信元の場合は、次の操作を行います。
- 送信元として使用している Cloud Storage バケットに対する
objectViewerIAM 権限を 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_NUMBER@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 サービス アカウントにストレージ バケットへのアクセス権を付与します。
これを行うには、PROJECT_NUMBER が
service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com の
アクセスを必要とする 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 がこの名前に設定された送信元を作成する必要があります。
コンソール
コンソールで、[Media CDN] ページに移動します。 Google Cloud
[送信元] タブをクリックします。
[オリジンを作成] をクリックします。
送信元の名前を入力します。例:
load-balancer-origin。（省略可）説明を入力します。
[送信元のアドレス] で [FQDN または IP アドレスを指定] を選択します。
ロードバランサの FQDN または IP アドレスを入力します。 Google Cloud
省略可: この送信元に到達できない場合に試行するフェイルオーバー オリジンを選択します。このフィールドは後で更新できます。
再試行条件を選択します。
[**最大試行回数**] で、この送信元からのキャッシュ フィルを試行する最大回数を選択します。
省略可: 次のタイムアウト 値を指定します。
- [**接続タイムアウト**] で、 送信元接続が確立されるまで待機する最大時間を選択します。
- [**レスポンス タイムアウト**] で、レスポンスが完了するまでの最大時間を選択します。
- [**読み取りタイムアウト**] で、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 に設定して、暗号化されていない接続にフォールバックできます。これは、開発またはテストでのみ行うことをおすすめします。
フレキシブル シールディングのリージョンを構成する
送信元を作成または更新するときに、フレキシブル シールディング のリージョンを構成できます。
コンソール
コンソールで、[Media CDN] ページに移動します。 Google Cloud
[送信元] タブをクリックします。
更新する送信元の名前をクリックします。
編集モードに切り替えるには、[編集] ボタンをクリックします。
[送信元コントロール] セクションの [送信元のシールド] で、 [フレキシブル シールディング（カスタム）] を選択します。最も近いリージョンが自動的に選択されます。最も近いリージョンがリストにない場合は、使用可能なリージョンのリストから手動で値を選択します。有効な値は
africa_south1とme_central1です。変更を保存するには、[送信元を更新] をクリックします。
シールディングをデフォルトの送信元シールディングに戻すには、送信元を更新して [送信元のシールド（デフォルト）] を選択します。
gcloud
既存の送信元のリージョンにフレキシブル シールディングを構成するには、
gcloud edge-cache origins update コマンドを使用します。
gcloud edge-cache origins update ORIGIN \
--origin-address=ADDRESS \
--flex-shielding=REGION
次のように置き換えます。
ORIGIN: 送信元の名前ADDRESS: 送信元のアドレスREGION: 送信元のシールドのリージョン。有効な値はafrica_south1とme_central1です。
シールディングをデフォルトの送信元シールディングに戻すには、flex-shielding オプションを空に設定した後、同じコマンドを実行します。
yaml
既存の送信元のリージョンに送信元のシールドを構成するには、flexShielding セクションを EdgeCacheOrigin リソース構成に追加します。
name: ORIGIN
originAddress: ADDRESS
# ... Other fields
flexShielding:
flexShieldingRegions:
- REGION
# ... Other fields
次のように置き換えます。
ORIGIN: 送信元の名前ADDRESS: 送信元のアドレスREGION: 送信元のシールドのリージョン。有効な値はafrica_south1とme_central1です。
送信元のシールドをデフォルトに戻すには、flexShielding セクションを削除します。
送信元のフェイルオーバーを構成する
以降のセクションでは、オリジン フェイルオーバー動作を構成する方法について説明します。
リダイレクト フォローなしの送信元のフェイルオーバー
基本的なフェイルオーバー 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が HTTP302 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 ステータス コードを返します。これは、送信元へのコンタクトの最大試行回数を超えたためです。
EdgeCacheOrigin の構成に関係なく、Media CDN はすべての送信元に対して最大 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 のリダイレクトに従う |
送信元固有のホストの書き換えまたはヘッダーの変更を構成する
送信元で送信元固有のホストの書き換えまたはヘッダーの変更が必要な場合は、次の 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 に設定します。
ルートごとにリクエスト ヘッダーを設定する方法については、 カスタム ヘッダーを設定するをご覧ください。
送信元のトラブルシューティング
送信元が想定どおりに動作しない場合は、送信元の トラブルシューティング方法を確認してください。