要約

  • 同じ適格なキャッシュオブジェクトへの同時リクエストは取得を共有でき、オリジンの重複作業を減らせる。一方、利用者は待ち行列にも入る。
  • 待つ利用者に使える応答も hit-for-pass マーカーも得られない場合、行列が再形成され、取得が並列ではなく順次進むことがある。
  • 取得回数の減少だけで、総費用の節約や良い配信は証明できない。再利用の正当性、待ち時間、完了した結果を一緒に評価する必要がある。

行列を出ても、仕事はなくならない

一つの取得処理を待っていたリクエストが解放されれば、問題が解けたように見える。しかし、その利用者に応答が届いたとは限らない。個別の取得へ戻る場合もあれば、次の取得の後ろに再び行列を作る場合もある。

Fastly のリクエスト集約を評価するには、この違いが重要だ。重複するオリジン処理を減らすことと、利用者の作業を終えることは同じではない。オリジンへの取得回数が少なくても、未完了の要求が積み上がっている可能性がある。

この記事は顧客の遅延や請求額を測っていない。Fastly が公開する待ち行列と応答処理の分岐から、購入時に何を別々に確認すべきかを考える。集約は有用な仕組みだが、その数字だけでは配信の成否まで判断できない。

重複作業を待つ仕組みで置き換える

Fastly は request collapsing を、同じオブジェクトへの同時リクエストを一つのオリジン要求へまとめ、得られた応答を待つ要求にも使う可能性のある仕組みと説明している。

人気のあるオブジェクトが期限切れになると、利用者がそれぞれ取得を始める方式ではオリジンへの要求が急増し得る。待ちリストは、後から到着した適格な要求を、すでに進む取得へ加える。

応答が再利用できれば、一つの作業で複数の配信を完了できる。重複処理を省き、負荷を平らにする利点がある。その代わり、利用者は同じ取得の進み方を待つ。行列への参加だけで、届く内容が全員に適しているとは決まらない。

これは、同じ見た目の URL に対して CDN 全体に一つの行列があるという説明ではない。適用される配信経路、キャッシュオブジェクト、バリアントが単位となる。Fastly は hit-for-pass が Vary を尊重し、一つのキャッシュアドレスでも異なるバリアントが別の扱いを持てると明記している。

応答もマーカーも使えない分岐

難しいのは、集約済みの取得から、待つ利用者に再利用できる応答が得られず、hit-for-pass マーカーも作れない場合だ。次の要求がオリジンへ向かい、残りの要求はその後ろで新しい待ち行列を作り得る。

同じ条件が繰り返されると、取得は並列ではなく順次進む。Fastly のガイドは、一部の状況で数分に及ぶ待ち時間が発生し得ると警告する。特定顧客の事件や予測ではなく、すべての個人向け応答が必ずそうなるという話でもない。

VCL の参照資料は、一つの条件を明確にしている。beresp.cacheable が false なら、処理が deliver で終わってもオブジェクトは保存されず、hit-for-pass オブジェクトも作られない。解放された二次要求が、すぐ別の行列に入り直すことがある。

ここでは、低い取得回数の意味が二つに分かれる。共有した作業が何人分もの有用な配信を終えた場合と、処理できない要求が待っている場合だ。集計したオリジン数だけでは区別できない。

マーカーは私的な本文の共有ではない

hit-for-pass は、対象のリソースやバリアントを集約せず、それぞれオリジンへ送るためのマーカーである。キャッシュに残すものが、共有する本文ではなく、共有を避ける処理の判断である場合がある。

CDN VCL の応答段階で通過を決める経路では、所定の応答処理状態によってマーカーを作り、待つ利用者に本文を再利用しない形が文書化されている。マーカーの保存を、個人向け応答を他人に配ることと混同してはならない。

Fastly は、オリジン取得前に要求を通過扱いにする経路も区別する。再利用できないと事前に分かっていれば、最初から集約の対象にしない選択がある。判断の時点は行列の形成に関係する。

ただし、VCL の特定制御を、Compute のあらゆるキャッシュインターフェースに共通する説明にはできない。個別取得へ戻した作業は消えず、並列でオリジンへ届くこともある。行列を変えただけで、その処理能力が増えるわけではない。

保存しないことにも複数の意味がある

集約のガイドは、private と指定されていない応答が、max-age=0 や no-cache でもすでに待つ利用者に使える一方、次の要求では再びキャッシュミスになる例を述べている。

この待ちリストの文脈では、取得中の再利用と、後の到着に新鮮な保存オブジェクトを使うことは違う。HTTP 指示の普遍的な同値性を主張するものではない。個人向け内容が新鮮さの期限ゼロだから共有可能になる、という意味でもない。

また、beresp.cacheable が false の分岐と同一にしてはならない。プライバシー、応答の適格性、保存の新鮮さ、待ち行列の進み方は別の事実である。

Fastly の解説ブログは、利用可能なオブジェクトの指標を、キャッシュ可能性と正の残存寿命で定義する。その計数条件を、別ガイドが説明するすべての待ちリスト配信に無断で当てはめるべきではない。

集約が少ないことは失敗とは限らない

ストリーミングミスを有効にすると、オリジンの応答ヘッダーが到着した時点で、利用できるデータがキャッシュに入り始める場合がある。新しい要求が初回の取得と重なる時間の窓は短くなり得る。

したがって、集約の頻度が低くても、オリジンが速く、効率的に処理されている可能性がある。頻度が高いことも、それだけで全員が必要な結果を得た証明にはならない。指標は、その定義と時間の条件を保って読む必要がある。

待ち行列の制御は古い応答にも影響する

CDN VCL の req.hash_ignore_busy は、集約対象から外しながら、新鮮なキャッシュへのヒットを可能なままにする。Fastly は同時に、古いオブジェクトを使えなくし、stale-while-revalidate と stale-if-error の効果を無効にすると説明している。

要求段階の通過とは違い、待ち時間だけを変える無害なスイッチではない。オリジンの並列負荷と、許されていた古い内容による配信経路を一緒に変える可能性がある。この記事のために、こうした設定を操作してはいない。

古い応答を配信することにも正当な境界がある。Fastly のチュートリアルは、許可された時間窓や条件を説明するが、あらゆるエラーで自動的に古い応答へ戻るとは約束していない。古い権限、在庫、価格が常に適切だと示すものでもない。

完了した配信を検収する

短い判断記録には、内容の種類、実際のキャッシュ識別とバリアント、承認された再利用範囲、サービスのインターフェース、失敗分岐、許容できる待ちと新鮮さを残せる。これは編集上の提案であり、Fastly の義務的機能や顧客監査ではない。

オリジン取得の減少が、より多くの有用な応答の完了と適切な待ち時間を伴ったのか。使えない結果の後ろに要求が増えただけなのか。分離すべき仕事は情報の境界を守り、オリジンにも持続可能な負荷だったのか。

公開された仕組みから言えるのは、この限定された検収原則である。集約は、共有した作業が正当な配信を完了するときに価値を持つ。小さくなった取得数は、その結果の代わりにはならない。

出典