リクエスト共有 (Request collapsing)

Last updated August 01, 2018

ここでは、高度なサービス設定をするときに頻繁に使われる、リクエスト共有( Request Collapsing )について説明します。

注意: Varnish および VCL 言語に記載されている高度な知識を前提としています。

基本事項

リクエスト共有 (Request Collapsing) は、単一のFastly データセンター内でキャッシュミスが同時に発生する際に、オリジンサーバへのリクエストを 1 つに束ねることを意味します。オリジンサーバーが当該の 1 リクエストを処理している間、その他のリクエストはキューに入り完了を待ちます。リクエスト共有 (Request Collapsing) には 2 種類あります:

単一のキャッシュサーバーにおけるリクエスト共有
単一のデータセンター内におけるキャッシュサーバ間のリクエスト共有

各キャッシュサーバーは、同じハッシュ値のリクエストを自動的にキューに保存し、オリジンサーバーへは 1 つのリクエストのみが送信されます。　この動作は、vcl_recv において req.hash_ignore_busy を true にすることで無効にできます。

データセンター内において、すべてのキャッシュサーバーがすべてのキャッシュオブジェクトを保持しているわけではありません。各データセンター内で 2 台のキャッシュサーバーのみがキャッシュオブジェクトを保持しています: 1 台は主系として、もう 1 台は副系として稼働します。これら 2 台のサーバーのみがオリジンサーバーから実際にコンテンツを取得します。

動作内容

Fastly が利用している Varnish では、通常 1 つのリクエストにおける各 VCL サブルーチンはそれぞれ別のキャッシュサーバー上で実行されます。1 つのリクエストに対し、エッジのキャッシュサーバーとクラスターノードのシールドキャッシュサーバーの両方が存在します(場合によっては、1 台のキャッシュサーバーが両方の役割を担います)。エッジのキャッシュサーバーは HTTP リクエストをクライアントから受信し、同じデータセンター内にあるクラスターノードのシールドキャッシュサーバーをハッシュ値から決定します。この時、もしエッジのキャッシュサーバー自身が、キャッシュオブジェクトを持つシールドキャッシュサーバーであると判定された場合、このサーバはエッジのキャッシュサーバーとクラスターノードのシールドキャッシュサーバーの両方の役割を担います。

エッジのキャッシュサーバーとクラスターノードのシールドキャッシュサーバーそれぞれで実行される VCL サブルーチンは以下の通りです:

エッジのキャッシュサーバー: vcl_recv, vcl_deliver, vcl_log, vcl_error
クラスターノードのシールドキャッシュサーバー: vcl_miss, vcl_hit, vcl_fetch, vcl_error

キャッシュサーバーがエッジのキャッシュサーバーかクラスターノードのシールドキャッシュサーバーかの判定方法

VCL を実行しているサーバーがエッジのキャッシュサーバーの場合は fastly_info.is_cluster_edge 変数が true に、クラスターノードのシールドキャッシュサーバーの場合は false になります。

注意事項

リクエスト共有 (Request Collapsing) を利用する場合は、以下の制限についてご注意ください:

いかなる req.http.* ヘッダーも、クラスターノードのシールドキャッシュサーバーからエッジのキャッシュサーバーへは引き継がれません。状態の管理にヘッダーを利用するような高度な設定を行う際には、この点に注意してください。もし req.http.* ヘッダーを、クラスターノードのシールドキャッシュサーバーで実行されるサブルーチン内で設定した場合、この変更はエッジのキャッシュサーバーには引き継がれません。
オリジンサーバーへ送られたリクエスト処理に時間がかかると、同じオブジェクトに対する他の複数のリクエストが遅延もしくは失敗する可能性があります。これは 1 つのオブジェクトに対する複数のリクエストが 1 つのリクエストに束ねられるためであり、そのためオリジンへのリクエストの結果によって、全てが成功、または失敗することになります。