問題とコンテキスト
あるWebページはブラウザ、CDN、オリジンのリバースプロキシキャッシュを経由します。ユーザーから時折リクエストが遅いという報告が寄せられており、標準化されたレスポンスフィールドを使用して、どのレイヤーでミス、再検証、またはリクエストの合流が発生したかを特定する必要があります。RFC 9211を用いて計画を設計し、本番環境におけるプライバシーおよびキャッシュポイズニングのリスクに対処してください。
面接官が評価するポイント
重要なのは、Cache-Statusが構造化フィールドリスト（structured-field list）であるという点です。各メンバーはリクエストを処理したキャッシュを表し、オリジンに最も近いキャッシュからユーザーに最も近いキャッシュの順に並びます。hitとfwdの違い、転送理由とttl、さらに診断情報の認証と秘匿化（リダクション）について説明できるかが評価されます。
最初に確認すべき明確化のための質問
キャッシュのトポロジーと所有権
ブラウザがフィールドを追加するかどうか、各レイヤーが上流の値を保持するかどうか、CDNおよびリバースプロキシの設定を変更できるチームはどこかを確認します。順序が正しくなければ、リストを確実に解釈することはできません。
デバッグのサンプリングと機密データ
診断情報が内部リクエストに対してのみ有効化されているか、サンプリングレート、およびログの保持期間を確認します。キャッシュキー、テナント識別子、パーソナライズされたレスポンスは機密情報である可能性があり、すべてのクライアントに返却すべきではありません。
鮮度と一貫性の目標
Cache-Control、バリデータ、許容されるstale（古延）期間、およびビジネス上の一貫性要件を確認します。負のttlは、そのレイヤーが古いと判定したことを意味しますが、それ単体で古いバイト列が実際に配信されたことを証明するわけではありません。
30秒の回答フレームワーク
「各キャッシュはリストを保持しながら自身のCache-Statusメンバーを追加し、私はそれをオリジン側からユーザー側に向かって読み取ります。hitは次のホップが不要であったことを意味し、fwdはuri-miss、vary-miss、staleなどの理由を持ち、fwd-status=304は再検証を特定します。認可された内部デバッグのみが詳細やキーを返し、本番の出力はテナントの漏洩やキャッシュポイズニングの手がかりを防ぐために秘匿化されます。」
詳細な解決手順
ステップ 1: 構造化フィールドのパース
Cache-StatusをRFC 8941のリストとしてパースし、各メンバーの識別子とパラメータを読み取ります。部分文字列のチェック（substring check）は使用しないでください。メンバーには引用符付き文字列、並べ替えられたパラメータ、重複したレイヤーが含まれる可能性があります。
ステップ 2: 追加と順序付けルールの定義
レイヤーは既存のフィールドを検出した場合、上流のエビデンスを上書きするのではなく、自身のメンバーを追加します。オリジンに最も近いキャッシュが最初に表示され、ユーザーに最も近いキャッシュが最後に表示されます。欠落しているレイヤーはトポロジーのギャップとして記録し、推測による補完はしません。
ステップ 3: ヒットと転送の解釈
hitは、レイヤーが保存されたデータからリクエストを処理したことを意味します。fwd=uri-missは一致するURIがなかったこと、vary-missはVaryの選択に失敗したこと、staleは選択されたレスポンスが古かったことを意味します。fwd-statusは転送時に意味を持ち、304検証と他のレスポンスを区別します。
ステップ 4: TTL、ストレージ、合流（collapse）の相関
ttlはそのレイヤーの残り鮮度の推定値であり、負の値になることもあります。storedは転送されたレスポンスが保存されたかどうかを示し、collapsedは複数のリクエストが1つの転送を共有したかどうかを示します。これらのフィールドをリクエストID、オリジン時間、ステータスコードと相関させて、テールレイテンシーの原因を解明します。
ステップ 5: パーソナライゼーションとキャッシュキーの処理
認証済み、テナント固有、またはCookieを含むレスポンスについては、まずRFC 9111のキャッシュ可能性を検証します。本番レスポンスではキャッシュの識別情報、ヒットタイプ、大まかなTTLのみを公開し、keyおよび詳細は、ユーザー制御のフラグメントを削除した上で制御されたデバッグチャネルに限定します。
ステップ 6: 安全なサンプリングポリシーの構築
内部リクエストフィールド、有効期間の短い認可、またはエッジ設定によって診断情報を有効化し、デフォルトではパブリックなパスに詳細な出力が出ないようにします。攻撃者がタイミングの挙動を推測したりキャッシュキーを発見したりできないよう、ログをパースして保護します。
ステップ 7: エンドツーエンドの検証
URI-miss、Vary-miss、stale再検証、リクエスト合流、マルチレイヤーヒットのテストケースを作成します。リストの順序、fwd-status、TTLの符号、上流メンバーの保持を確認します。レスポンス、キャッシュログ、オリジントレースを比較し、オブザーバビリティの導入によってキャッシュのセマンティクスが変更されていないことを確認します。
高品質な回答サンプル
私ならブラウザ、CDN、リバースプロキシにCache-Statusを追加させ、それを構造化フィールドパーサーでパースします。まず各レイヤーをhitかfwdに分類し、次に転送理由、fwd-status、ttl、stored、collapsedを使用して遅いリクエストを説明します。内部デバッグのみがkeyやdetailを公開し、パブリックレスポンスは秘匿化された状態を維持します。テストではURI miss、Vary miss、stale 304、リクエスト合流、マルチレイヤーの順序付けをカバーします。
よくある間違い
- 間違い: 最後のメンバーのみを唯一の結果として扱う。 → 理由: リストはキャッシュチェーン全体を記録しているため。 → 対策: オリジンからユーザーまでのすべてのメンバーを説明する。
- 間違い: hitが常にfresh（新鮮）を意味すると仮定する。 → 理由: 明示的なローカルポリシーによって古いレスポンスが配信される場合があるため。 → 対策: ttlをCache-Controlおよび転送状態と組み合わせて判断する。
- 間違い: 上流のCache-Statusを上書きする。 → 理由: 以前のエビデンスが失われるため。 → 対策: メンバーを保持して追加する。
- 間違い: keyやdetailをパブリックに返却する。 → 理由: テナント情報、タイミング、ポイズニングの手がかりが漏洩する可能性があるため。 → 対策: デバッグチャネルに制限し、秘匿化を行う。
フォローアップの質問と回答
フォローアップ 1: hitと304検証はどのように関連していますか？
次のホップに問い合わせることなく再利用された場合はhitです。キャッシュが次のホップで検証を行う必要がある場合はfwdを使用し、fwd-status=304によって次のホップが保存済みの表現を検証したことを示すことができます。
フォローアップ 2: 複数のCache-Statusフィールド行を直接連結できますか？
HTTPフィールドの結合では同名フィールドを単一のリストとして扱いますが、実装では単純な文字列連結ではなく、カンマ、引用符、パラメータを処理するためにRFC 8941パーサーを使用する必要があります。
フォローアップ 3: 負のTTLは古いバイト列がユーザーに届いたことを証明しますか？
いいえ。それはそのレイヤーがレスポンスを古いと計算したことを示しているだけです。そのレイヤーは再検証を行うか、明示的に許可されたstaleポリシーに基づいて配信している可能性があるため、転送およびレスポンスのディレクティブを確認する必要があります。
フォローアップ 4: 一部のユーザーにのみ影響する遅延をどのようにデバッグしますか？
ノード間でメンバー、Varyの選択、TTL、合流率を比較し、地理的情報、Cookie、リクエストフィールドを相関付けます。特定のレイヤーのみで分離して発生しているvary-missは、キー構築のずれや設定の不一致を示唆しています。