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

送信元の概要

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 つの主要なレイヤがあります。

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

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

Media CDN は、限られた一連の主要なグローバルロケーションを使用して、デフォルトで送信元シールドを提供します。デフォルトのオリジンシールドは、オリジンのロケーションではなく、エンドユーザーのロケーションに基づいて動作します。この方法は、エンドユーザーとオリジンサーバーが同じリージョンにある場合や、グローバルオリジンサーバーが複数のリージョンに配置されている場合に、効果を発揮し、オフロードのメリットを最大限に引き出すことができます。

フレキシブルシールディング

オリジンが 1 つのリージョンに集中しているが、ユーザーがグローバルに分散しているシナリオでは、ユーザーのロケーションに基づくデフォルトのオリジンシールド動作が次のように最適でない可能性があります。

デフォルトのシールドの場所が集中型の配信元から地理的に離れている場合、キャッシュミスのレイテンシが増加する
キャッシュ入力リクエストを集中させるのではなく、複数のグローバルデフォルトシールドロケーションに分散することで、オリジンのオフロードを削減

柔軟なシールドは、通常、一元化されたオリジンの近くに選択されるオリジンシールド用に単一の特定の地理的リージョンを構成することで、これらの制限を克服するのに役立ちます。柔軟なシールドは、構成されたリージョン内またはその近くにあるシールドキャッシュを介して、すべてのキャッシュ入力リクエストをルーティングします。これにより、リージョンに焦点を当てたキャッシュを介して、オリジンに負荷が統合されます。

一元管理されたオリジンと同じ地理的リージョンにフレキシブルシールディングリージョンを構成すると、次の点を最適化できます。

シールドレイヤのキャッシュヒット率
オリジンオフロード
キャッシュミスとキャッシュ不可能なコンテンツのレイテンシ
パフォーマンスの安定性

柔軟なシールドは、Media CDN で構成された任意のオリジンタイプと互換性があります。

リクエストの折りたたみ

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

キャッシュ保存のすべてのレイヤでリクエストの折りたたみ（または統合）がサポートされており、オリジン負荷をさらに軽減できます。大規模な実際のワークロードの観測に基づいて:

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

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

送信元シールドと組み合わせることで、リクエストの折りたたみによって送信元の負荷と下り（外向き）帯域幅のニーズがさらに軽減されます。これは Media CDN のデフォルトの動作です。

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

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

Origin の接続

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

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

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

Identity and Access Management サービスアカウントを介したプライベートバケットを含む Cloud Storage バケット
外部アプリケーションロードバランサ
AWS Signature バージョン 4 を使用するプライベートバケットを含む、Amazon S3 互換バケット
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		`409` や `429` など、再試行可能な `4xx` ステータスコードを再試行します。
NOT_FOUND		HTTP `404` ステータスコードで再試行します。
FORBIDDEN		HTTP `403` ステータスコードで再試行します。

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

フェイルオーバーの動作

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

シナリオ	フェイルオーバーが構成されている	ユーザー向けのステータス
Media CDN は送信元への接続を試み、2 回の試行後に HTTP レスポンスを受信しません（デフォルト）。	いいえ	HTTP `502 Bad Gateway`
Media CDN はプライマリ送信元への接続を試みますが、接続に失敗します（TLS ハンドシェイクエラー）。構成済みのフェイルオーバー送信元に対して試行が行われ、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 によって配信されるコンテンツを生成するためです。