送信元の概要

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

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

送信元には次の特徴があります。

送信元はホストごと、ルートごとに定義できます。これにより、1 つの EdgeCacheService リソースを、マニフェスト、動画セグメント、その他の静的コンテンツなどを含む複数の送信元にマッピングできます。
送信元には、HTTP/2、HTTPS、暗号化されていない HTTP/1.1 を介して到達できます。
再試行とフェイルオーバーの動作は送信元ごとに構成され、ハードエラー（接続エラーなど）が発生した場合にサービスをフェイルオーバーしたり、HTTP 404 Not Found または HTTP 429 Too Many Requests レスポンスに基づいて再試行したりできます。
Media CDN の背後にある外部アプリケーションロードバランサを送信元として構成することで、Google Cloud またはオンプレミス内のプライベートリソースにアクセスできます。
リダイレクト先の動作は送信元ごとに構成されます。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 ネットワーク内のロングテールキャッシュは、他のダウンストリームキャッシュが送信元のそれよりも前からフィルします。これらのキャッシュは、大規模なファンインをサポートし、かなりのキャッシュストレージ容量を持ち、送信元のシールドとして機能します。

以下に、このトポロジの概要を示します。

キャッシュのすべてのレイヤは、送信元の負荷をさらに削減するための折りたたみ（または結合）をリクエストします。大規模に確認された実際のワークロードに基づく:

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

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

リクエストの折りたたみ

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

送信元のシールドと併用すると、送信元の負荷と下り（外向き）の帯域幅のニーズをさらに削減できます。これは Media CDN のデフォルトの動作です。

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

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

Origin の接続

以下のセクションでは、Media CDN が送信元に接続する方法、HTTP リクエストが作成される方法、リクエストを認証する方法について説明します。

サポートされている送信元とプロトコル

Media CDN は、次のような公開アクセス可能な HTTP エンドポイントを送信元として直接サポートしています。

Cloud Storage バケット（Identity and Access Management サービスアカウントを介したプライベートバケットを含む）
外部アプリケーションロードバランサ
AWS Signature Version 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`	originAddress	ホストヘッダー / 送信元での 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 設定は無視されます。ホストヘッダーは、バケット名に基づいて自動的に設定されます。

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

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

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

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

タイムアウト: 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 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 によって提供されるコンテンツを生成するため、リダイレクトチェーン内のすべての送信元が信頼できることを確認してください。