LOG IN SIGN UP
Documentation

大容量ファイルのキャッシュパフォーマンス改善

  Last updated September 03, 2018

Fastly には最大 5GB までの大容量ファイルの配信をサポートするための機能として、 Streaming Miss(ストリーミングミス)と、Large File Support(ラージファイルサポート) という2つの機能が存在します。

Streaming Miss(ストリーミングミス)

ストリーミングミスを有効化すると、オリジンからオブジェクトを取得する際、Fastly サーバーはオリジンからレスポンスを受け取りながら、受け取ったレスポンスをクライアントに送ります。その後、オブジェクト全体のダウンロード完了後に、オブジェクトはキャッシュに書き込まれます。 こうすることでクライアントがレスポンスボディを受け取るまでの時間である first-byte を改善することが出来ます。レスポンスのサイズが大きければ大きいほど、この効果は大きくなります。

ストリーミングミスの設定

設定は簡単です。 VCL の vcl_fetch 内で beresp.do_stream に true を設定して下さい :

  sub vcl_fetch {
    ...
    set beresp.do_stream = true;
    ...
    return(deliver);
  }

上記のVCLは Fastly コントロールパネルの Create a header から以下の設定を行うことでも作成することが出来ます。 Type Cache、 Action Set、Destination do_stream、Source true。 もちろん conditions(条件) を付与することで、ヘッダーを付与する条件を指定することも可能です。

Enable Streaming Miss

制約事項

ストリーミングミスにはいくつかの制約事項があります。

TLS によるオリジンへの接続とコンテンツサイズの制限について

ストリーミングミスは、現在オリジンとの接続に HTTPS (TLS) ををサポートしていません。クライアントへのコンテンツの配信に HTTPS を利用することは出来ますが、オリジンからのコンテンツ取得に HTTPS を利用することは出来ません。そのため、オリジンから HTTPS で取得されるコンテンツサイズの上限は、ストリーミングミス非適用時の上限である 2GB が適用されます。 ストリーミングミスは、現在 HTTPS (TLS) オリジンサーバーを 限定提供版 (Limited Availability) としてのみサポートしております。もしご利用をご希望される場合には、テクニカルアカウントマネージャーもしくは support@fastly.com にご連絡ください。

限定提供版の利用が受け入れられるまでは、ストリーミングミスは、HTTPS (TLS) オリジンサーバーをサポートしません。リクエストされたコンテンツは、クライアントに対して HTTPS で配信をされますが、HTTPS でストリーミングミスによるコンテンツ取得はされません。HTTPS オリジンサーバーからコンテンツを取得するのは、結果としてストリーミングミスを利用しない場合の2GB のサイズに制限されます。

HTTP/1.0 クライアントはストリーミングミスを利用出来ません

HTTP/1.0 によるリクエストでオリジンからコンテンツを取得し、オリジンからのレスポンスヘッダーに Content-Length フィールドが含まれていない場合、ストリーミングミスは無効化され、ストリーミングミス非適用時のサイズ上限が適用されます。

ストリーミングミスが有効なオブジェクトに対して HTTP/1.0 のリクエストが発生した場合、ストリーミングミスが設定されていないリクエストと同様に、オブジェクト全体がダウンロードされてからレスポンスヘッダーやボディの送信が開始されます。

キャッシュヒットした場合はこの影響を受けません。HTTP/1.0 クライアントも HTTP/1.1 クライアント同様に大容量ファイルをキャッシュから受け取ることが出来ます。

ストリーミングミスはオンザフライ (on-the-fly) gzip 圧縮機能と併用することは出来ません

ストリーミングミスは大容量ファイルが圧縮されているかどうかに関わらず利用することが出来ます。ただし、圧縮されていないオブジェクトに対するオンザフライの gizp 圧縮機能と併用することが出来ません。beresp.gzip が VCL で設定されている場合、ストリーミングミスは無効化されます。

ストリーミングミスは ESI (Edge-Side Includes) と併用することは出来ません

ESI によって処理されるレスポンス、ESI テンプレートからインクルードされるレスポンスはストリームすることが出来ません。レスポンスに対して ESI が有効化されているか、<esi:include> によってインクルードされるレスポンスにはストリーミングミスは無効化され、取得可能なファイルサイズの上限はストリーミングミス無効時と同じ 2GB となります。

Large File Support(ラージファイルサポート)

ラージファイルサポートは自動的に有効化されます。特に追加で設定を行う必要はありません。ただし、配信可能なファイルのサイズには上限があり、上限を超えた場合は後述のような動作となります。

ファイルサイズの上限

ストリーミングミスが有効化されている場合、配信可能なファイルサイズの上限はおよそ 5GB (正確には 5,368,578,048 bytes) となります。ストリーミングミスが無効化されている場合、配信可能なファイルサイズはおよそ 2GB (正確には 2,147,352,576 bytes) となります。

問題発生時の挙動

ラージファイルサポートを利用する場合、以下のような問題に遭遇する可能性があります。

ファイルサイズの上限を超えた場合の挙動

オリジンからのレスポンスの Content-Length ヘッダーの値がファイルサイズの上限を超えている場合、Fastly サーバーはすぐに 503 エラーを生成しクライアントに返却します。VCL 内に追加のエラー処理が実装されている場合はこの限りではありません。

Content-Length ヘッダーが付与されていない場合、Fastly はレスポンスボディの取得を開始します。レスポンスボディ取得時にファイルサイズの上限を超えていることを検知した場合、すぐに 503 レスポンスが生成されクライアントに返却されます。繰り返しになりますが、VCL 内に追加のエラー処理が実装されている場合はこの限りではありません。

Content-Length ヘッダーが付与されておらず、ストリーミングミスが有効な場合、Fastly はオリジンからコンテンツを取得しながらクライアントに配信します。この際にファイルサイズの上限を超えたことを Fastly が検知すると、クライアントとの接続は切断されます。正規の接続クローズ時に送信されるはずの 0 サイズのチャンクなしに切断が行われるため、クライアント側ではプロトコル違反を検知します。

オリジンからの読み込み失敗時の挙動

オリジンからのレスポンスヘッダーの読み込みに失敗した場合、ストリーミングミスの有効、無効に関わらず 503 レスポンスが発生します。

オリジンからのレスポンスボディの読み込みに失敗、またはタイムアウトが発生した場合、ストリーミングミスの有効無効によって動作が異なります。 ストリーミングミスが無効な場合は 503 レスポンスが生成されます。 ストリーミングミスが有効な場合、すでにヘッダーが送信されているためエラーレスポンスを送信することが出来ません。そのため、Fastly はクライアントとの接続を切断します。チャンク方式でレスポンスが送信されている場合、正規の接続クローズに必要な 0 サイズのチャンクなしに切断が行われ、クライアント側ではプロトコル違反を検知します。Content-Length が知らされている場合、提示されたバイト数に達成する前に接続が切断されることになります。

これが、HTTP/1.0 クライアントが Content-Length が知らされていない場合にストリーミングミスを利用することが出来ない理由となります。クライアントが Content-Length を知らされておらず、チャンクをサポートしていない場合、クライアントは接続の切断が正しいものなのか上流の問題による突然の接続断なのかを判断することが出来ません。


Back to Top