送信元を構成する

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_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 サービス アカウントにストレージ バケットへのアクセス権を付与します。

これを行うには、service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com の PROJECT_NUMBER が、アクセスを必要とする 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 が構成されている。
• ロードバランサには、これらのホスト名用に構成された公開鍵証明書（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