リクエスト共有 (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 台のキャッシュサーバーがこの両方の役割を担います)。エッジノードは HTTP リクエストをクライアントから受信し、同じデータセンター内にあるクラスターノードをハッシュ値から決定します。この時、もしエッジノード自身が、キャッシュオブジェクトを持つクラスタノードであると判定された場合、このサーバはエッジノードとクラスターノードの両方の役割を担います。

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

エッジノード: vcl_recv, vcl_deliver, vcl_log, vcl_error
クラスターノード: vcl_miss, vcl_hit, vcl_fetch, vcl_error

エッジノードかクラスターノードかの判定方法

リクエストが別のクラスターノードに転送された場合、bereq.is_clustering 変数が true になります。

注意事項

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

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