HTTP キャッシュ

ポリシー名

HTTP キャッシュ

概要

API 実装から HTTP 応答を保存する

カテゴリ

最小 Mule バージョン

4.1.0

返される状況コード

このポリシーは、API 実装または API プロキシから HTTP 応答を後で再利用するために保存する方法を提供します。サービスの応答が頻繁には変わらない場合、またコンピューティングコストのかかる処理に対する最適化目的で、このポリシーによってバックエンドに複数回コールを実行することが回避されます。このポリシーはキャッシュの概念を使用してデータを保存し、将来そのデータへの要求があった場合によりすばやく提供できるようにします。

注意:​ Object Store v2 で保持されている値はプレーンテキストではなくバイナリとして表示されます。

このポリシーの保存対象

このポリシーでは、ポリシーで受信したバックエンドからの HTTP 応答全体が保存されます。応答には、状況コード、ヘッダー、ペイロード、セッション変数などが含まれます。このポリシーで受信する前に応答を編集するポリシーがある場合、その変更も受信する応答に反映されて保存されます。キャッシュポリシーを通過した後の応答に変更を加えるポリシーがある場合、その変更は保存されませんが、値がキャッシュから取得されるたびにコピーされます。

各エントリのサイズ制限は 1 MB です。HTTP 応答でコンテンツ長情報が提供されない場合、ポリシーはその制限まで読み取りを試み、制限以内であれば保存し、制限を超えていれば保存せずに処理を続行します。

ポリシーのしくみ

ポリシーは要求を受信すると、応答を保存するためのキーを計算します。同じキーを持つ 2 つ目の要求を受信すると、ポリシーはキャッシュ内にある以前保存した応答を検索して返します。キャッシュ内に一致する応答が見つかった場合、その要求は、キャッシュされたものより後に定義されているポリシー、API 実装、プロキシのいずれにも進みません。

エントリの保存場所

キャッシュとして使用される基礎のストアは、Mule の ObjectStore です。ポリシーの設定とデプロイ場所に応じて、ポリシーはメモリ内、永続、またはファイルベースのオブジェクトストアか、Runtime Manager ObjectStore V2 を使用します。後者の場合、設定された TTL でそのポリシー専用に別途ストアが作成されます。オブジェクトストアへのアクセスについての詳細は、​「Mule 4 のカスタムポリシーのキャッシュ」​を参照してください。

ポリシー設定パラメータ

ポリシー設定に関するトピック:

HTTP Caching Key (HTTP キャッシュキー)

キャッシュは辞書として機能し、そこではキャッシュに保存された各応答がキーと呼ばれる文字列に関連付けられます。ポリシーには、このキーを計算する方法が必要であるため、この項目には String (文字列) 値を返す DataWeave 式が含まれている必要があります。

例: ​#[attributes.headers['key']]

DataWeave 変数についての詳細は、​「DataWeave Variables for Mule Runtime」​(Mule Runtime の DataWeave 変数) および​「Mule メッセージ構造」​を参照してください。

式の評価がパラメータの不足やその他の原因でエラーになった場合、このポリシーは適用されず、要求はポリシーチェーンの次の受け入れ先に渡されます。

注意:​ このパラメータは必須であり、デフォルト値は ​#[attributes.requestPath]​ で、キャッシュのキーが要求のパスであることを意味します。エンドポイントを ​http://myAppUrl.com/my/policy​ としてコールする場合、キーは ​/my/policy​ になります。

Maximum Cache Entries (最大キャッシュエントリ)

これは、キャッシュ内に同時に存在可能な応答の最大数です。この最大値を超えると、キャッシュから FIFO (先入れ先出し) で応答が削除されます。Runtime Manager ではこの設定は無視されます。

この項目も必須で、デフォルト値は 10000 エントリです。

注意:​ Runtime Manager ObjectStore v2 を使用する場合、これは適用されません。

Entry Time To Live (エントリ存続期間)

存続期間 (TTL) 値は秒単位で測定されます。

このパラメータは、応答がキャッシュに保存される秒数を表します。この時間が経過すると、その応答はキャッシュから削除されます。新しい要求を受信し、応答がキャッシュに存在しない場合、新しい応答を計算する必要があります。 Runtime Manager でポリシーと Object Store v2 を使用する場合、この値の編集内容が正しく反映されません。その場合、ポリシーとオブジェクトストアを削除してから新しく適用することをお勧めします。

注意:​ これは必須パラメータで、デフォルト値は 10 分 (600 秒) です。

Distributed (分散)

Runtime Manager でクラスタまたは複数のワーカーを実行する場合、キャッシュに保存されている値をさまざまなノード間で共有できます。これを実現するには、このオプションをオンにする必要があります。そうしないと、ノードごとに固有のキャッシュが作成されます。Runtime Manager の場合、このオプションを機能させるには、Object Store v2 が有効化されている必要があります。

デフォルトでは、このオプションはオフです。また、キャッシュを分散すると軽微な問題が生じることがありますが無視してかまいません。

Persist Cache (キャッシュの保持)

このボックスをオンにすると、キャッシュに保存されている値はランタイムの再起動後も保持されます。このオプションを Runtime Manager で使用する場合、Runtime Manager のアプリケーションの設定で Object Store V2 を有効化します。

デフォルトでは、このオプションはオフです。

Follow HTTP Caching Directives (HTTP キャッシュディレクティブに従う)

キャッシュをより詳細に制御するために、このポリシーには RFC-7234 からいくつかの HTTP ディレクティブが実装されています。このボックスをオンにすると、ポリシーは次のヘッダーを考慮して、どの応答を保存するか、いつキャッシュを使用するか、いつエントリの期限が切れるかを決定します。

デフォルトでは、このボックスはオンです。

これを機能させるには、次のヘッダーを使用します。

Cache-Control

このヘッダーは要求または応答に存在する可能性があります。値をカンマで区切って組み合わせることができます。次の値があります。

要求:

  • no-cache​ (キャッシュなし): 応答はキャッシュ内で検索されませんが、キャッシュに保存されます。

  • no-store​ (保存なし): 応答はキャッシュに保存されませんが、キャッシュ内にすでに存在する場合はポリシーがその応答を返します。

応答:

  • no-store, no-cache, private​ (保存なし、キャッシュなし、非公開) - これらすべての値が同じ動作を共有します。応答はキャッシュに保存されません。

  • max-age=<integer>, s-maxage=<integer>​ (最大存続期間=<integer>、s 最大存続期間=<integer>) - <integer> 値は整数に置き換える必要があります。キャッシュ内で応答が存続する秒数を示します (両方が定義されている場合、​s-maxage​ が ​max-age​ より優先されます)。この値はポリシーに設定されている グローバル TTL を上書きします。

要求に存在するヘッダーの例: ​Cache-Control: no-cache,no-store

この場合、要求に対してキャッシュで値は検索されず、結果は保存されません。

応答に存在するヘッダーの例: ​Cache-Control: max-age=2, s-maxage=10

この場合、応答は 10 秒間キャッシュされます。

Expires (有効期限)

このヘッダー値は RFC-1123 のとおりに定義する必要があります。

存在する場合、この日付が有効期限の日付です。​max-age​ ディレクティブまたは ​s-maxage​ ディレクティブが指定されている場合、このヘッダーは無視されます。

Date (日付)

このヘッダーが RFC-1123 のとおりに定義されている場合、応答の作成時刻とみなされます。定義されていない場合、date ヘッダーが応答の受信時刻で追加されます。このヘッダーは、Cache-Control ヘッダーの ​max-age​ および ​s-maxage​ ディレクティブに定義された値と一緒に使用されます。

Age (存続期間)

このヘッダーはポリシーによって計算され、キャッシュから取得されて返される各応答に追加されます。date ヘッダーに指定されたキャッシュされている応答の作成以降の秒数を示します。

有効期限は、Cache-Control、Date、および Expiration ヘッダーを使用して計算されます。ただし、計算された有効期限が ​Entry Time To Live (エントリ存続期間)​ で指定された存続時間を超える場合、有効期限はこちらの値に従います。

Invalidation Header (無効化ヘッダー)

このパラメータが定義されている場合、キャッシュ内の値を無効化するために使用されるヘッダーの名前を示します。定義されていない場合、キャッシュからエントリを無効化することはできません。このヘッダーは次の 2 つの値を取ります。

  • invalidate​ (無効化): このオプションを選択すると、現在の要求のキーでキャッシュからエントリが無効化されます。

  • invalidate-all​ (すべて無効化): このオプションを選択すると、キャッシュからすべてのエントリが無効化されます。

このヘッダーが要求に存在する場合、少なくとも要求内に存在するキーで無効化されるため、キャッシュ内で既存の結果が検索されることはありません。

このパラメータは省略可能で、デフォルトでは定義されていません。

例:

ポリシーで ​HTTP Caching Key (HTTP キャッシュキー)​ に #[attributes.requestPath]、Invalidation Header (無効化ヘッダー) に myInvalidationHeader の値があるとすると、次の要求の場合、

curl http://myAppUrl.com/my/policy -H“myInvalidationHeader:invalidate”

このコマンドは、キャッシュからキーが "/my/policy" のエントリを無効化します。一方、次の要求の場合、

curl http://myAppUrl.com/my/policy -H“myInvalidationHeader:invalidate-all”

このコマンドは、キャッシュからすべてのエントリを無効化します。

Conditional Request Caching Expression (条件付き要求キャッシュ式)

この項目には、応答を評価して Boolean を返す DataWeave 式が含まれます。
要求が式と一致した場合、式は True を返し、ポリシーはキャッシュに要求を保存します。 要求が他の値の場合、式は False を返し、要求はキャッシュに保存されません。

DataWeave 変数についての詳細は、​「DataWeave Variables for Mule Runtime」​(Mule Runtime の DataWeave 変数) および​「Mule メッセージ構造」​を参照してください。

このパラメータは省略可能で、デフォルト値は次のとおりです。

#[attributes.method == 'GET' or attributes.method == 'HEAD']

これは、デフォルトでは、HTTP メソッドの GET または HEAD による受信要求に対する応答のみがキャッシュされるという意味です。

Conditional Response Caching Expression (条件付き応答キャッシュ式)

この項目には、応答を評価して Boolean を返す DataWeave 式が含まれます。
応答が式と一致した場合、式は True を返し、ポリシーはキャッシュに応答を保存します。
応答が他の値の場合、式は False を返し、応答はキャッシュに保存されません。

DataWeave 変数についての詳細は、​「DataWeave Variables for Mule Runtime」​(Mule Runtime の DataWeave 変数) および​「Mule メッセージ構造」​を参照してください。

このパラメータは省略可能で、デフォルト値は次のとおりです。

#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

これは、デフォルトでは、​RFC-7231 で指定された状況コードのみがキャッシュされるという意味です。

FAQ

あるパラメータではキャッシュ内で応答を検索するように指定し、別のパラメータではその逆を指定した場合、どうなりますか?

応答式で結果を保存するように指定したが、​Cache-Control​ ヘッダーに ​no-store​ ディレクティブがある場合と同じになります。

応答は保存されません。応答が保存またはキャッシュで検索されるためには、すべての条件に適合する必要があります。キャッシュの介在を拒否する条件が 1 つでもあれば、キャッシュに対する保存や検索は行われません。

このポリシーで応答の一部のみを保存できますか?

いいえ。ただし、このポリシーの前に別のポリシーを適用して、応答を変更することはできます。

Runtime Manager では、どのように動作が異なりますか?

  • [Distributed (分散)] チェックボックスがオンの場合、常に保持されます。

  • Runtime Manager では [Maximum Cache Entries (最大キャッシュエントリ)] が適用されません。

  • Object Store V2 の使用時にはポリシーの TTL の編集内容が正しく反映されません。この値を変更するには、ポリシーを削除して新しいポリシーを適用します。

Runtime Manager でポリシーを使用するには何らかの設定が必要ですか?

はい。キャッシュを分散または保持するには、Runtime Manager で Object Store を v2 に設定する必要があります。

キャッシュに保存する際、どのデータ型がサポートされますか?

Java の Serializable と入力ストリームはキャッシュできます。入力ストリームの場合、キャッシュエントリの最大サイズ制限 1 MB まで読み取られます。値がこの制限を超えると、読み取りは停止し、保存は行われません。

省略可能なパラメータを定義しないとどうなりますか?

  • Invalidation Header (無効化ヘッダー) を設定しないと、要求でキャッシュを無効化できません。

  • 要求式または応答式を設定しないと、キャッシュはすべての要求に対して使用され、式 ​#[true]​ を設定した場合と同様にそれぞれの応答がすべてキャッシュに保存されます。

Invalidation Header (無効化ヘッダー) の値を変更できますか?

いいえ。変更できるのはヘッダー名のみです。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub