HTTPキャッシングは理論的には単純です：Cache-Control、ETag、TTLの値が正しければ、クライアントと中間システムは同じレスポンスを再利用します。本番では、アプリケーションはこれらのヘッダーを欠落させたり、誤ったり、過度に制限的に送信することが多いです。その結果、キャッシュ可能なコンテンツがバックエンドに不必要に繰り返しアクセスされます。
静的アセットでさえ、小さなURLの違いがキャッシュ効率を低下させます。同じ製品画像やカタログページがトラッキングパラメータのために異なるオブジェクトとして振る舞うことがあります。Host、クエリ文字列、クライアントヘッダー、または設定ミスのCache-Controlヘッダーがキャッシュヒット率を不必要に下げます。
動的コンテンツでは問題はさらに大きくなります。同じパスがモバイルとデスクトップで異なるレスポンスを返すことがあります；価格は国によって変わる可能性があります；同じエンドポイントがテナントごとに異なるデータを生成できます。キャッシュキーがそのコンテキストを持たなければ、間違ったコンテンツが返されます。キャッシュキーにヘッダーを追加しすぎると、キャッシュがほとんど機能しなくなります。
外部キャッシュまたはCDNソリューションはインターネットエッジで有用ですが、オンプレミス、プライベートAPI、またはソブリンクラウドトラフィックには常に適しているわけではありません。ADCレイヤーでキャッシングを行うには通常、設定ファイル、カスタムルール言語、または別のプロダクトが必要です。
TR7 レスポンスキャッシングはキャッシュプロファイル、条件付きルール、動的キャッシュキー、標準オーバーライドオプションを単一のvService管理モデルの下に統合します。
TR7はキャッシュ動作を4つのレイヤーで管理します：プロファイル、条件、動的キー、制御されたオーバーライド。
キャッシュプロファイルは名前、サイズ、TTL、ETag、デバッグヘッダー設定を1か所に収集します。同じプロファイルを複数のvService間で共有でき、各サービスは独自のキャッシュ制限で管理されます。
各キャッシュルールはFX条件エンジンを通じてパス、メソッド、ヘッダー、クッキー、またはその他の変数にバインドされます。同じバックエンドのパブリックカタログをキャッシュしながら、アプリケーションコードを変更せずにユーザーのカートを除外できます。
国、デバイスタイプ、テナントID、ユーザーセグメント、またはカスタムヘッダーをキャッシュキーに追加できます。同じURLがコンテキストごとに別々のキャッシュスロットに分かれ、キャッシュ速度を保ちながらコンテンツの正確性を強化します。
Host、クエリ文字列、リクエストヘッダー、レスポンスヘッダーチェックをそれぞれ意図的にバイパスできます。設定ミスのバックエンドやトラッキングパラメータがもはやヒット率を下げません。オペレーターはどの標準をいつオーバーライドするかを明示的に決定します。
レスポンスキャッシングはキャッシュプロファイルから動的キーまですべての動作をvServiceレベルで設定可能にします。
各プロファイルは名前、最大サイズ、タイムアウトで定義されます。サイズ制限はサービスごとのキャッシュ使用量を制御下に保ちます。タイムアウトは秒、分、時間単位で設定可能です。同じプロファイルを複数のvServiceに適用することで運用の繰り返しを削減します。
TR7はレスポンスにデバッグヘッダーを追加でき、開発者またはオペレーターがブラウザのNetworkパネルでレスポンスがキャッシュから来たのかバックエンドから来たのかを確認できます。簡単な確認に追加のログツールは不要です — コミッショニングと調整が加速されます。
単一のキャッシュプロファイル内で複数のルールを定義できます。各ルールはパス、メソッド、ヘッダー、クッキー、またはFX条件でトリガーされます。`/assets/*`を長時間キャッシュしながら`/api/cart`を除外できます。1つのvService内の異なるキャッシュ動作を単一のパネルから管理します。
ETagはルールごとに有効化できます。クライアントが同じオブジェクトを再度リクエストしてコンテンツが変更されていない場合、完全なボディではなく検証レスポンスを受信します。これにより帯域幅の消費が削減され、静的アセットと頻繁には変わらないAPIレスポンスで特に効果的です。
動的キャッシングが有効な場合、カスタム変数をキャッシュキーに追加できます。国、デバイスタイプ、テナントID、A/Bテストグループ、またはJWTから抽出した値をすべてキーの一部にできます。同じURLがコンテキスト間でクリーンに分かれます。これによりモダンなAPIとSaaSシナリオでキャッシングが実用的になります。
同じバックエンドが複数のドメイン配下で同一のコンテンツを提供している場合、キャッシュキーからHostを削除できます。`a.example`と`b.example`のようなドメインは同じキャッシュオブジェクトを共有でき、キャッシュの重複が削減されます。このオプションはコンテンツが本当に共有されている場合にのみ使用すべきです。
`utm_source`、キャンペーンコード、アナリティクスパラメータが同じコンテンツを異なるオブジェクトに見せることがあります。クエリの無視が有効な場合、これらのパラメータはキャッシュキーから除外されます。複数のトラッキングパラメータバリアントを持つ同じページがバックエンドに繰り返しアクセスしなくなります。パブリックコンテンツのヒット率が顕著に向上します。
一部のクライアントまたはボットはすべてのリクエストでキャッシングをバイパスしようとするヘッダーを追加します。リクエストチェックの無視でその動作を意図的に無視できます。静的コンテンツとパブリックAPIレスポンスが不必要なバックエンド負荷から保護されます。この設定はセキュリティに敏感なエンドポイントに慎重に適用してください。
バックエンドが誤って`no-store`または過度に制限的なキャッシュヘッダーを送信することがあります。レスポンスチェックの無視でオペレーターはこれらのヘッダーを意図的にバイパスできます。アプリケーションコードを変更せずにキャッシングの恩恵が得られます。このオプションは決定論的で安全なレスポンスにのみ使用すべきです。
標準のHTTPキャッシュ動作はGETとHEADレスポンスに焦点を当てています。TR7はオペレーターがPOSTレスポンスもキャッシュスコープに含めることを許可します。GraphQLクエリがPOST経由で届く場合に特に有用です。ボディハッシュまたは関連するFX変数をキャッシュキーに追加して安全な分離を確保できます。
キャッシュはランタイムメモリに保持されます。設定変更はソフトリロードモデルで適用されます；ランタイム無効化エンドポイントは主張されません。キャッシュプロファイルまたはルールを更新すると関連するキャッシュ動作が更新されます。デバイスが再起動するとキャッシュは空から再び温まり始めます。
キャッシュサイズの制限に達した場合、最も使用頻度が低いまたは古いオブジェクトが退避されます。オペレーターは個々のオブジェクトを手動で管理する必要はありません。サイズ制限により1つのvServiceのキャッシュが他のサービスに影響することを防ぎます。大きなアセットカタログにはプロファイルサイズを増やせます。
レスポンスキャッシングはキャッシュTTL、オブジェクトサイズ、キー設計、無効化モデル、セキュリティ境界と共に計画される必要があります。
キャッシュプロファイルの最大サイズはMBで定義されます；プロファイルごとに最大2048 MBがサポートされます。大きなアセットカタログには大きなプロファイルが適しています；小さなAPIレスポンスキャッシュには低い制限で十分です。
非常に短いTTLはキャッシュスラッシングを引き起こし、キャッシングの利点を低下させます。TR7は不必要な充填・空のサイクルを防ぐために最低10秒を強制します。TTLは各エンドポイントの更新頻度に合わせて調整すべきです。
設計ミスのキャッシュキーはユーザーまたはテナント固有のコンテンツを誤ったコンテキストで返す可能性があります。テナント、国、デバイスタイプ、またはユーザーセグメントによる区別が必要な場合、それらの値を動的キャッシュキーに含める必要があります。機密エンドポイントはデフォルトでキャッシングから除外すべきです。
キャッシュはメモリベースです；デバイスまたはサービスが再起動するとキャッシュは空から始まります。これにより永続ディスクキャッシュの複雑さが排除されます。キャッシュは最初のトラフィックウェーブで再び温まります。
ランタイム無効化エンドポイントは主張されません。キャッシュ動作はプロファイルまたはルールを編集してソフトリロードをトリガーすることで管理されます。特定のエンドポイントの動作を変更するには、関連するキャッシュルールを更新します。
キャッシュプロファイル、タイムアウト、無視オプション、動的キーの変更は監査ログに記録すべきです。誰がどのエンドポイントのキャッシュ動作を変更したかが可視化されます。これはコンプライアンスとインシデント分析に特に重要です。
製品ページとカタログAPIが一定期間キャッシュされます。国をキャッシュキーに追加することで、異なる価格または在庫レベルを持つ市場が正しいコンテンツを受信します。
ニュース、お知らせ、またはパブリックコンテンツエンドポイントを数分間キャッシュできます。クエリの無視によりトラッキングパラメータがヒット率を下げることを防ぎます。
テナントIDまたはカスタムヘッダーをキャッシュキーに追加します。同じパスが異なるテナントに対して別々のキャッシュスロットに安全にルーティングされます。
GraphQLクエリがPOST経由で届いても、決定論的なクエリをキャッシュできます。ボディハッシュまたは関連するFX変数をキャッシュキーに追加して間違ったレスポンスのリスクを最小化します。
CSS、JS、画像、フォントファイルが長いTTLでキャッシュされます。ETagが有効な場合、クライアントは変更されていないコンテンツをリクエストする際に完全なボディのダウンロードをスキップします。
User-Agentファミリーまたはデバイスクラスをキャッシュキーに追加します。同じURLがモバイルとデスクトップ用に別々のキャッシュスロットに保持されます。
レスポンスキャッシングのためのキャッシュプロファイル、条件付きルール、動的キー、RFC準拠のオーバーライドオプション。お客様自身のサービスでのライブセットアップをご案内します。