送信元の概要

Media CDN を使用すると、コンテンツが Google Cloud 内、別のクラウド、またはオンプレミスでホストされているかどうかにかかわらず、送信元インフラストラクチャからコンテンツを取得できます。

各構成には、1 つ以上のオリジンを関連付けることができます。送信元の構成では、インフラストラクチャへの接続方法、フェイルオーバー、再試行、タイムアウトのタイミングと方法、接続時に使用するプロトコルを Media CDN に指示します。

オリジンには次の機能があります。

• 送信元はホストごとに、またはルートごとに定義できます。これにより、単一の EdgeCacheService リソースを、マニフェスト、動画セグメント、その他の静的コンテンツを含む複数の送信元にマッピングできます。
• 送信元には、HTTP/2、HTTPS、非暗号化の HTTP/1.1 によって到達できます。
• 再試行とフェイルオーバーの動作は送信元ごとに構成され、ハードエラー（接続エラーなど）が発生した場合にサービスがフェイルオーバーしたり、HTTP 404 Not Found または HTTP 429 Too Many Requests レスポンスに基づいて再試行を実行したりできます。
• Google Cloud またはオンプレミス内のプライベート リソースには、Media CDN の背後に外部アプリケーション ロードバランサを送信元として構成することでアクセスできます。
• リダイレクト フォローの動作は送信元ごとに構成されます。Media CDN を有効にして、他のオリジン サーバーへのリダイレクトに従うようにできます。

送信元の要件

Media CDN が 1 MiB を超える送信元レスポンスをキャッシュに保存できるようにするには、指定されていない限り、送信元に HEAD リクエストと GET リクエストの両方のレスポンス ヘッダーに以下を含める必要があります。

• Last-Modified または ETag HTTP レスポンス ヘッダー（バリデータ）。
• 有効な HTTP Date ヘッダー。
• 有効な Content-Length ヘッダー。
• Range GET リクエストに対する Content-Range レスポンス ヘッダー。Content-Range ヘッダーには、bytes x-y/z 形式の有効な値を指定する必要があります（ここで、z はオブジェクト サイズです）。

デフォルトのオリジン プロトコルは HTTP/2 です。オリジンが HTTP/1.1 のみをサポートしている場合は、オリジンごとにプロトコル フィールドを明示的に設定できます。

Origin のシールド

メディア CDN は、可能な限りキャッシュ フィルを最小限に抑えるように設計された、ディープ ティアのエッジ インフラストラクチャを提供します。

キャッシュ インフラストラクチャには、次の 3 つの主要なレイヤがあります。

1. ディープ エッジ キャッシュ。トラフィックの大部分を処理し、サービス プロバイダのネットワーク内でオフロードします。
2. Google のピアリング エッジ。数千の ISP に接続し、エッジ キャッシュのミッドティア キャッシュとして機能します。また、特定の ISP 内に存在しない場合、ユーザー向けキャッシュとしても機能します。
3. Google のネットワーク内のロングテール キャッシュ。他のダウンストリーム キャッシュが送信元より前にキャッシュに格納します。これらのキャッシュは、大量のファンをサポートし、膨大なキャッシュ ストレージ容量を備え、オリジンのシールドとして機能します。

このトポロジの概要は次のとおりです。

キャッシュのすべてのレイヤは、リクエストの圧縮（または統合）をサポートして、オリジンの負荷をさらに削減します。大規模な実際のワークロードに基づく:

• キャッシュ フィルの 95% 以上は、キャッシュ フィルの費用とレイテンシを削減するために、リージョン内の専用のロングテール キャッシュノードを使用します。
• 送信元と Google 独自のエッジ インフラストラクチャ間のキャッシュ フィルは、すべて Google のグローバル プライベート バックボーン ネットワークを介して行われるため、キャッシュ フィルのレイテンシが短縮され、信頼性が向上します。どちらもライブ ストリーミング ワークロードにとって有効なメリットです。
• キャッシュは、相互にクロスフィルを行い、キャッシュ フィルレートをさらに低下させます。
• Media CDN にはキャッシュ全体に大量のストレージ容量があるため、人気が低いロングテール コンテンツでもエビクション率を最小限に抑えることができます。

キャッシュ構成、ユーザー負荷、ワークロード（ライブとオンデマンドなど）、ユーザーの配信、ロングテール コンテンツの量（コーパスの合計サイズ）に応じてオフロード率が異なる場合があります。

リクエストの折りたたみ

リクエストの折りたたみによって、同じキャッシュキーの複数のユーザー ドリブン キャッシュ フィル リクエストが、エッジノードごとにアクティブに 1 つの送信元リクエストに折りたたまれます。

送信元のシールドと組み合わせることで、送信元の負荷と下り（外向き）帯域幅の必要性がさらに軽減されます。これは Media CDN のデフォルトの動作です。

折りたたまれたリクエストでは、クライアント側のリクエストと（折りたたまれた）キャッシュ フィル リクエストの両方がログに記録されます。折りたたみセッションのリーダーは、元のフィル リクエストを行うために使用されます。つまり、送信元には、そのクライアントのみのヘッダー（User-Agent を含む）が表示されます。

同じキャッシュキーを共有しないリクエストは、折りたためません。

Origin の接続

以降のセクションでは、Media CDN がオリジンに接続する方法、HTTP リクエストを行う方法、リクエストを認証する方法について説明します。

サポートされているオリジンとプロトコル

Media CDN は、次のような一般公開されている HTTP エンドポイントを送信元として直接サポートしています。

• Cloud Storage バケット（Identity and Access Management サービス アカウントによるプライベート バケットを含む）
• 外部アプリケーション ロードバランサ
• Amazon S3 互換バケット（AWS Signature バージョン 4 を使用する限定公開バケットを含む）
• Azure Blob Storage などの一般公開されている他のオブジェクト ストレージ
• 一般公開されているウェブサーバー（パブリック VM やオンプレミス ホストなど）

オリジンへの接続は、安全なトンネルと Google のグローバル バックボーン ネットワークを経由します。

次の表に、サポートされている送信元プロトコルの詳細を示します。

プロトコル	サポート対象	SSL（TLS）必須
HTTP/2	はい（デフォルト）	はい
HTTPS（TLS 経由の HTTP/1.1）	はい	はい
HTTP/1.1	はい	いいえ

Media CDN は、デフォルトで HTTP/2（h2）を使用して送信元に接続します。HTTP/2 と HTTPS の両方には、一般に信頼されている有効な TLS（SSL）証明書が必要です。有効な証明書とは、有効期限が切れていない、パブリック認証局によって署名されている、送信元に送信されたホスト名と一致するサブジェクト代替名を持つ証明書です。

注:

• 送信元が HTTP/2 をサポートしていない場合は、プロトコルを（送信元ごとに）HTTP（HTTP/1.1）または HTTPS（TLS 経由の HTTP/1.1）に明示的に設定できます。
• 送信元プロトコルとして HTTPS または HTTP/1.1 を構成する場合、Media CDN は代替プロトコル（HTTP/2 など）をネゴシエートしません。同様に、HTTP/2 を構成する場合、送信元の接続動作を明示的にするため、接続は HTTP/1.1 にフォールバックしません。
• Media CDN は、プロトコルに基づいて正しいポート（HTTP の場合はポート 80、HTTPS と HTTP/2 の場合はポート 443）を自動的に使用します。

送信元リクエスト ヘッダー

送信元に接続する場合、Media CDN はデフォルトでクライアント リクエストの Host ヘッダーを使用します。

次の表に、さまざまな構成シナリオで送信されるリクエストでオリジンが確認できる内容を示します。

クライアント リクエスト	EdgeCacheService.hostRewrite	EdgeCacheOrigin.hostRewrite	元のアドレス	ホストヘッダー / 送信元での TLS SNI
media.example.com	なし	なし	backend.example.com	media.example.com
media.example.com	service.example.com	なし	backend.example.com	service.example.com
media.example.com	なし	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	バケット名に基づいて自動的に設定

プライマリ オリジンとすべてのフェイルオーバー オリジンが同じ routeRule または hostRewrite 構成を共有している場合、同じホストヘッダーが表示されます。

Cloud Storage バケットを送信元として使用する場合、代替のホストヘッダー値は Cloud Storage バケットでサポートされていないため、hostRewrite の設定は無視されます。ホストヘッダーは、バケット名に基づいて自動的に設定されます。

リクエストの TLS SNI（Server Name Indication）値（HTTP/3、HTTP/2、HTTPS リクエストの場合）は、送信元に送信されたホストヘッダーと同じ値に設定されます。

ルートごとの構成でホストヘッダーを書き換える方法については、サービス ルートを構成するをご覧ください。オリジンごとのオーバーライド アクションの設定については、リダイレクト フォローなしのオリジン フェイルオーバーをご覧ください。

フェイルオーバーとタイムアウト

以降のセクションでは、これらの構成オプションについて説明します。

• タイムアウト: Media CDN が送信元への接続を待機する時間、またはリクエストに応答する時間を指定します。
• 再試行: Media CDN が送信元への送信元 HTTP リクエストを再試行するかどうか、およびどのような条件で再試行するかを決定します。
• フェイルオーバー: 最初の送信元が使用できない場合、または特定のステータス コードを返した場合に、Media CDN がフェイルオーバー送信元への接続を試みるかどうかを決定します。

オリジンのタイムアウト

タイムアウトを使用すると、送信元の再試行とフェイルオーバーの動作がトリガーされるタイミングと、その後のクライアント フェイルオーバーをトリガーできるタイミングを構成できます。

以下では、Media CDN がサポートする構成可能なタイムアウトについて説明します。

• connectTimeout と maxAttemptsTimeout は、Media CDN が使用可能なレスポンスを検出するのにかかる時間を制限します。

  どちらのタイムアウトにも、オリジンがヘッダーを返す時間と、フェイルオーバーとリダイレクトのどちらを使用するかを決定する時間が含まれます。connectTimeout は、送信元の試行ごとに独立して適用されますが、maxAttemptsTimeout には、フェイルオーバーとリダイレクトを含むすべての送信元の試行に接続するために必要な時間が含まれます。リダイレクト後の接続は、送信元への追加の接続試行としてカウントされ、構成された送信元に設定された maxAttempts にカウントされます。

  Media CDN がリダイレクトまたはフェイルオーバー送信元からのリダイレクト以外のレスポンスに遭遇した場合、readTimeout 値と responseTimeout 値が適用されます。リダイレクトされた送信元は、リダイレクトに遭遇した EdgeCacheOrigin に構成された connectTimeout、readTimeout、responseTimeout の値を使用します。

• responseTimeout と readTimeout は、ストリーミング レスポンスを取得するまでの時間を制御します。Media CDN がアップストリーム レスポンスを使用することを決定した後、connectTimeout も maxAttemptsTimeout も重要ではありません。この時点で、readTimeout と responseTimeout が有効になります。

Media CDN は、各 EdgeCacheOrigin で設定された maxAttempts に関係なく、すべての送信元で最大 4 回の送信元の試行を行います。Media CDN は、プライマリ EdgeCacheOrigin の maxAttemptsTimeout 値を使用します。試行ごとのタイムアウト値（connectTimeout、readTimeout、responseTimeout）は、各試行の EdgeCacheOrigin に構成されます。

次の表に、タイムアウト フィールドの説明を示します。

フィールド	デフォルト	説明
connectTimeout	5 秒	Media CDN がリクエストを開始してから送信元が使用可能になるまでの最大時間。この時間が経過するとMedia CDN はレスポンスが使用可能かどうかを判断します。実際には、connectTimeout はリクエストの作成から DNS ルックアップの実行、TLS handshake、TCP/QUIC 接続の確立、さらには HTTP ステータス コードまでカバーします。 タイムアウトは 1 ～ 15 秒の値にする必要があります。
maxAttemptsTimeout	15 秒	送信元に対するすべての接続試行の最大時間。この時間を超えるとクライアントにエラーを返します。これにはフェイルオーバー送信元に対する接続も含まれます。レスポンスが返される前にタイムアウトに達すると、HTTP 504 が返されます。 タイムアウトは 1 ～ 30 秒の値にする必要があります。 この設定は、すべての送信元の接続試行（フェイルオーバー送信元を含む）の合計時間を定義します。これは、クライアントがコンテンツのストリーミング開始を待機する合計時間の上限を設定するためです。最初の maxAttemptsTimeout 値のみが使用されます。ここで、最初のは、指定されたルート用に構成された送信元によって定義されます。
readTimeout	15 秒	1 回の HTTP レスポンスの読み取り間の最大待機時間。readTimeout は responseTimeout によって制限されます。HTTP レスポンスの読み取りはすべて、responseTimeout で設定された期限までに完了する必要があります。タイムアウトは 1 ～ 30 秒の値にする必要があります。レスポンスが完了する前にこのタイムアウトに達すると、レスポンスは切り捨てられてログに記録されます。
responseTimeout	30 秒	レスポンスの完了を許可する最大時間。 タイムアウトは 1 ～ 120 秒の値にする必要があります。 時間は、最初の本文バイトが受信された時点から測定されます。レスポンスが完了する前にこのタイムアウトに達すると、レスポンスは切り捨てられてログに記録されます。

以下の例を考えてみましょう。

• Origin A は「/segments/」へのリクエストと照合されます。maxAttemptsTimeout の値は 5s、maxAttempts の値は 1、failover_origin、Origin B です。connectTimeout の値はデフォルトの 5s です。Origin A への接続を試みて、TLS 証明書が無効であるために 1 秒以内に失敗した場合、Origin B への接続を成功させるには約 4 秒の猶予があります。

• Origin C は「/manifests/*」へのリクエストと照合されます。maxAttemptsTimeout の値は 10s、maxAttempts の値は 3、failover_origin は構成されていません。connectTimeout 値はデフォルトの 5s です。Media CDN は Origin C への接続を最大 3 回試行し、最大 10 秒（maxAttemptsTimeout の上限）で接続を成功させます。

送信元リクエストを再試行する

Media CDN は送信元の再試行をサポートしているため、送信元へのリクエストが失敗した場合に再試行できます。フェイルオーバー送信元（構成されている場合）を試行する前に、現在の送信元を再試行できる回数を指定できます。

• Media CDN は、構成された maxAttempts 値（デフォルトは 1）までプライマリ送信元に到達しようとします。
• Media CDN は、オリジン接続を最大 3 回再試行した後、失敗して HTTP 502 Bad Gateway エラーをユーザーに返します。これには、3 つの上限にカウントされるフェイルオーバー送信元接続も含まれます。
• オリジン リソースを構成するときに、originAddress フィールドを使用してプライマリ オリジンを構成し、必要に応じて failoverOrigin を構成できます。failoverOrigin は別のオリジン リソースを指しています。

各オリジンの retryConditions には、再試行をトリガーする障害の種類を指定します。

条件	デフォルト	説明
CONNECT_FAILURE	✔️	エラー時の再試行には、ルーティング、DNS と TLS handshake のエラー、TCP/UDP タイムアウトが含まれます。
HTTP_5XX		任意の HTTP 5xx ステータス コードで再試行します。
GATEWAY_ERROR		5xx に似ていますが、ステータス コード 502、503、504 にのみ適用されます。
RETRIABLE_4XX		再試行可能な 4xx ステータス コード（409 や 429 など）に対して再試行します。
NOT_FOUND		HTTP 404 ステータス コードで再試行します。
FORBIDDEN		HTTP 403 ステータス コードで再試行します。

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

フェイルオーバーの動作

次の表に、フェイルオーバーの動作と、クライアントが検出するレスポンスを示します。

シナリオ	フェイルオーバーが構成されている	ユーザー向けのステータス
Media CDN は送信元への接続を試み、2 回の試行後に HTTP レスポンスを受信しません（デフォルト）。	いいえ	HTTP 502 Bad Gateway
Media CDN はプライマリ送信元への接続を試みますが、接続に失敗します（TLS handshake エラー）。構成済みのフェイルオーバー送信元に対して試行が行われ、HTTP 404 エラーが返されます。	はい	HTTP 404 Not Found
Media CDN はプライマリ送信元とフェイルオーバー送信元の両方への接続を試みますが、HTTP ステータス コードを受信しません。	はい	HTTP 502 Bad Gateway

Media CDN が、構成された retryConditions に一致するステータス コード（HTTP 404 Not Found エラーや HTTP 429 Too Many Requests エラーなど）を受信し、その後の再試行とフェイルオーバー送信元リクエストが引き続き失敗した場合、送信元の試行が尽きると、HTTP 502 Bad Gateway エラーがクライアントに返されます。

オリジンのフェイルオーバーのベスト プラクティス

フェイルオーバーまたはロード バランシング用に複数の送信元を構成する場合は、メディア コンテンツと Vary、ETag、Last-Modified ヘッダーの動作が送信元間で一貫していることを確認してください。

ベスト プラクティスとして、信頼できる送信元と制御対象の送信元にのみ送信元リダイレクトを構成します。各オリジンは EdgeCacheService によって配信されるコンテンツを生成するため、リダイレクト チェーン内のすべてのオリジンが信頼できることを確認してください。

次のステップ

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