--- schema_version: "1" id: c152a5772407855d1c221202667cdbc9e6559189d73590b4ed0e96a94157aa94 title: HTTP キャッシュポリシー collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/gateway/1.10/policies-included-http-caching.md canonical_url: https://docs.mulesoft.com/jp/gateway/1.10/policies-included-http-caching source_site: docs.mulesoft.com content_type: documentation content_hash: 4a1c3a48f2eac03c651598a4ecc1d8e12a988484caf10913c34fb27ad06f2c16 description: MuleSoft Documentation Site release: "1.10" latest: false --- # HTTP キャッシュポリシー

ポリシー名

HTTP キャッシュ

概要

API 実装から HTTP 応答をキャッシュする

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 HTTP キャッシュポリシーでは、HTTP 応答をキャッシュして再利用できます。これらの応答をキャッシュすると、ユーザー要求の応答時間が短縮され、バックエンドの負荷が軽減されます。たとえば、要求に対する応答が変更される可能性の低いエンドポイントをバックエンドで公開する場合、HTTP キャッシュポリシーを使用して、HTTP 応答を再利用し、バックエンド要求処理をバイパスできます。 ポリシー順序で HTTP キャッシュポリシーの後に適用されるポリシーはキャッシュによって提供される応答には適用されません。たとえば、HTTP キャッシュポリシーの後に適用されるレート制限ポリシーでは、アップストリームサービスによって提供される応答のみを制限し、キャッシュによって提供される応答は制限しません。HTTP キャッシュポリシーより前にキャッシュされた応答に必要なすべてのポリシーを適用してください。
HTTP キャッシュポリシーでは、MCP および A2A サーバーインスタンスはサポートされません。
## [](#cpp)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-caching-flex config: httpCachingKey: // REQUIRED, default: "#\[attributes.requestPath\]" maxCacheEntries: // REQUIRED, default: 10000 ttl: // REQUIRED, default: 600 useHttpCacheHeaders: // REQUIRED, default: true invalidationHeader: // OPTIONAL, default: "" requestExpression: // OPTIONAL, default: "#\[attributes.method == 'GET' or attributes.method == 'HEAD'\]" responseExpression: // OPTIONAL, default: "#\[\[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501\] contains attributes.statusCode\]" distributed: // REQUIRED, default: false persistCache: // REQUIRED, default: false
パラメーター 必須または省略可能 デフォルト値 説明

httpCachingKey

必須

#[attributes.requestPath]

DataWeave 式

maxCacheEntries

必須

10000

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。

ttl

必須

600

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。

useHttpCacheHeaders

必須

true

Cache-Control ヘッダーディレクティブの使用を有効にします。

invalidationHeader

省略可能

空の文字列

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーを指定する文字列。

requestExpression

省略可能

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

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。

responseExpression

省略可能

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

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)

distributed

必須

false

クラスター内の各ノードでキャッシュが分散されるように設定

persistCache

必須

false

レプリカの各再起動間でキャッシュが維持されるように設定
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: http-caching-flex config: httpCachingKey: "#[attributes.requestPath]" maxCacheEntries: 10000 ttl: 500 useHttpCacheHeaders: false requestExpression: "#[attributes.method == 'GET' or attributes.method == 'HEAD']" responseExpression: "#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]" ``` #### [](#分散キャッシュリソースの設定例)分散キャッシュリソースの設定例 分散キャッシュでは、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-caching spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: http-caching-flex config: httpCachingKey: "#\[attributes.method ++ attributes.requestPath\]" useHttpCacheHeaders: true maxCacheEntries: 100 ttl: 600 distributed: true persistCache: true invalidationHeader: AGW-CACHE-CONTROL ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 Required?

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

DataWeave 式。 デフォルト値: #[attributes.requestPath]

はい

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

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。 デフォルト値: 10000

はい

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

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。 デフォルト値: 600

はい

Distributed (分散)

クラスター内の各ノードでキャッシュが分散されるように設定します。 デフォルト値: false

はい

Persistent Cache (永続キャッシュ)

Flex Gateway インスタンスの各再起動間でキャッシュが維持されるように設定します。 デフォルト値: false

はい

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

Cache-Control ヘッダーディレクティブの使用を有効にします。 デフォルト値: true

はい

Invalidation Header (無効化ヘッダー)

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーの名前。

いいえ

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

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。 デフォルト値: #[attributes.method == 'GET' or attributes.method == 'HEAD']

いいえ

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

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)。 デフォルト値: #[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ HTTP 要求がエンドポイントに到達した後の次の処理は、要求がまだキャッシュにないのか (キャッシュミス)、すでにあるのか (キャッシュヒット) によって決まります。 ### [](#キャッシュミス)キャッシュミス キャッシュミスの場合、HTTP キャッシュポリシーは、送信された要求に対する応答がすでにキャッシュされているかどうかをチェックします。要求がバックエンドに到達したら、キャッシュミスの場合にのみプロセスが開始されます。次の図は、このシナリオで発生するイベントのフローを示しています。 ![Web ブラウザーとバックエンドシステム間のデータフローを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/http-policy-cache-miss.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまでポリシーチェーンの他のポリシーを進みます。 3. HTTP キャッシュポリシーは、要求がすでにオブジェクトストアにあるかどうかをチェックします。ない場合は、キャッシュミスプロセスが開始されます。 4. 要求は、他の残りのポリシーのチェーンを引き続き進みます。 5. 要求がバックエンドに到達し、必要なすべての処理を実行します。 6. バックエンドが応答し、応答はポリシーチェーンを戻ります。 7. 応答が HTTP キャッシュポリシーに到達します。 8. キャッシュで再度オブジェクトストアがヒットし、後で再利用できるように要求の​[キー](#key)​を保存しようとします。 9. 応答は、ポリシーチェーンの残りのポリシーを引き続き進みます。 10. 応答がクライアントに返されます。 ### [](#キャッシュヒット)キャッシュヒット キャッシュヒットの場合、HTTP キャッシュポリシーは、オブジェクトストアのキーを検索し、要求に対する応答が​[保存済みエントリ](#stored_entry)​としてすでにキャッシュされていることを検出します。要求がバックエンドに向けてポリシーチェーンを進むことはなく、キャッシュされた応答が再利用されます。 キャッシュヒットの場合、キャッシュ後にポリシーチェーンで実行される必要のあるすべてのポリシーはそれ以降実行されません。 ![API ゲートウェイを介した Web ブラウザーからバックエンドおよびオブジェクトストアへのデータフローを示すフローチャート図](/mulesoft/current/ja-jp/gateway/1.10/_images/http-policy-cache-hit.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまで他のポリシーを通過します。 3. HTTP キャッシュポリシーは、要求がすでにキャッシュにあるかどうかを確認します。 4. オブジェクトストアで​[キー](#key)​が見つかり、保存された応答が返されます。 5. 応答は、最後のポリシーに到達するまでポリシーチェーンの残りのポリシーを引き続き進みます。 6. キャッシュされた応答がクライアントに返されます。 ### [](#stored_entry)保存済みエントリ _保存済みエントリ_​は、キャッシュされた HTTP 応答です。キャッシュには、最大 1 MB のシリアル化可能データと入力ストリームを保存できます。値がこの制限を超えると、読み取りは停止し、値は保存されません。 ### [](#key)HTTP Caching Key (HTTP キャッシュキー) キャッシュは辞書として機能し、そこではキャッシュに保存された各応答が​_キー_​と呼ばれる文字列に関連付けられます。たとえば、式 #\[attributes.headers\['key'\]\] では、​`key`​ というヘッダーがエントリキーとして使用されます。​[定義済みの DataWeave 変数](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support#available-predefined-variables)​を含めて、文字列を返す任意の DataWeave 式を使用できます。 ### [](#キャッシュサイズとエントリ有効期限)キャッシュサイズとエントリ有効期限 キャッシュには、指定された数のエントリを特定の期間保持できます。この数は、​`Maximum Cache Entries`​ プロパティを使用して設定できます。各保存済みエントリは、一定時間キャッシュメモリに保持されます。その後、エントリは期限切れになり、再度処理する必要があります。この有効期限は、​_存続期間_​ (TTL) と呼ばれます。 キャッシュが最大項目保存数に達したときもエントリの有効期限がトリガーされます。このシナリオが発生すると、FIFO (先入れ先出し) 条件を使用してエントリが削除されます。つまり、最も早くキャッシュに到達したエントリは、TTL 値にまだ達していなくても削除されます。 ### [](#分散キャッシュ)分散キャッシュ キャッシュの各エントリは、​`Distributed`​ オプション (表を参照) を使用して、クラスター内の各ノードや Runtime Manager の複数のワーカーで共有できます。このオプションが有効になっていない場合、各ノードには独自のキャッシュメモリが割り当てられます。 ### [](#永続キャッシュ)永続キャッシュ 永続キャッシュでは、Flex レプリカが再起動しても、キャッシュの保存済みエントリを保持できます。 永続的なストアを使用するように設定された HTTP キャッシュポリシーを持つインスタンスのバージョンをアップグレードすると、ポリシーは以前のバージョンで保存されたエントリを維持しようとします。ただし、最悪のシナリオでは、キャッシュ内のエントリが無効になり、新しい要求の到着時にキャッシュが再入力されます。キャッシュ内のエントリのこの操作は自動的に実行され、ユーザーが意識することはありません。 ## [](#http-キャッシュディレクティブ)HTTP キャッシュディレクティブ HTTP キャッシュポリシーは、キャッシュをより詳細に制御するために次のヘッダーを考慮に入れて [RFC-7234](https://tools.ietf.org/html/rfc7234)​ プロトコルのいくつかの HTTP ディレクティブを解釈します。 - `Cache-Control` - `Expires` - `Date` - `Age` ### [](#cache-control)Cache-Control `Cache-Control`​ ヘッダーは要求または応答に存在します。ヘッダーに対して可能な値は次のとおりです。これらの値は、カンマで区切って組み合わせることができます。 - 要求: - `no-cache` 応答は検索されませんが、キャッシュに直接保存されます。 - `no-store` 応答はキャッシュに保存されません。ただし、応答がキャッシュ内にすでに存在する場合は、ポリシーがその応答を返します。 - 応答: - `no-store`​、​`no-cache`​、​`private` どの値でも応答はキャッシュに保存されません。 - `max-age=`​、​`s-maxage=` ``​ プレースホルダーは、応答がキャッシュに残ることができる時間 (秒) を示す有効な整数に置き換える必要があります。両方のパラメーターが定義されている場合、​`max-age`​ よりも ​`s-maxage`​ が優先されます。 ポリシーでグローバル存続期間 (TTL) 値も定義されている場合、ヘッダーで指定されている時間がグローバル TTL よりも少ないと、これらのヘッダー値がポリシーで設定されているグローバル TTL よりも優先されます。 ### [](#expires-有効期限)Expires (有効期限) 存在する場合、このヘッダーでキャッシュ内のエントリの有効期限を指定します。​`max-age`​ ディレクティブまたは ​`s-maxage`​ ディレクティブが指定されている場合、このヘッダーは無視されます。ヘッダー値は [RFC-1123](https://tools.ietf.org/html/rfc1123)​ のとおりに定義する必要があります。 ### [](#date-日付)Date (日付) `date`​ ヘッダーが [RFC-1123](https://tools.ietf.org/html/rfc1123)​ に従って定義されている場合、応答の作成日時が指定されます。定義されていない場合、​`date`​ ヘッダーが要求の受信時刻で追加されます。このヘッダーは、Cache-Control ヘッダーの ​`max-age`​ および ​`s-maxage`​ ディレクティブに定義された値と一緒に使用されます。 ### [](#age-存続期間)Age (存続期間) `age`​ ヘッダーは、date ヘッダーに指定されたキャッシュされている応答の作成以降の経過時間 (秒) を示します。このヘッダーはポリシーによって計算され、キャッシュから取得された各応答に追加されます。 有効期限は、​`cache-control`​、​`date`​、​`expires`​ ヘッダーを使用して計算されます。ただし、計算された有効期限がエントリの TTL 値で指定された存続時間を超える場合、キャッシュエントリの有効期限が切れます。 ### [](#無効化)無効化 HTTP キャッシュポリシーで ​`invalidate`​ ヘッダーが設定されている場合、キャッシュ内のエントリが無効化され、要求が再度処理されます。\[Invalidation Header (無効化ヘッダー)\] 設定のヘッダーの名前を指定して、オプションを有効にします。ヘッダーの値には、​`invalidate`​ オプションのみを設定できます。 このオプションは、キーが現在の要求に一致するエントリを無効化します。 `invalidate-all`​ このオプションは、キャッシュからすべてのエントリを無効化します。 たとえば、ポリシーで要求の次の値が設定されているとします。 - `HTTP Caching Key`​ (HTTP キャッシュキー): "#\[attributes.requestPath\]" - `Invalidation header`​ (無効化ヘッダー): "myInvalidationHeader" 次のコマンドは、キャッシュからキーが "/my/policy" のエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate”` 次の要求は、キャッシュからすべてのエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate-all”` ## [](#条件付きキャッシュ)条件付きキャッシュ 条件付きキャッシュでは、エントリをキャッシュに保存するために満たす必要がある一連の条件を設定できます。条件付きキャッシュパラメーターが設定されていない場合、すべての受信要求の応答がキャッシュに保存されます。設定されている場合、各要求のパラメーターが評価されて、現在の要求の応答を保存する必要があるかどうかが判断されます。 条件付き要求式の場合、デフォルトでは、HTTP メソッドの ​`GET`​ または ​`HEAD`​ による受信要求に対する応答のみがキャッシュされます。条件付き応答式の場合、デフォルトでは、 [RFC-7231](https://tools.ietf.org/html/rfc7231#section-6.1)​ で指定された状況コードのみがキャッシュされます。 デフォルト値についての詳細は、​[「ポリシーのパラメーターの設定」](#cpp)​を参照してください。 ## [](#faq)FAQ **キーの評価がエラーになった場合はどうなりますか?** 特定の要求の式の評価がエラーになった場合、ポリシーは有効にならず、要求はポリシーチェーンの次の受け入れ先に引き続き進みます。 **このポリシーで応答の一部のみを保存できますか?** いいえ。ただし、このポリシーの前に別のポリシーを適用して、応答を変更することはできます。 **あるパラメーターではキャッシュ内で応答を検索するように設定し、別のパラメーターではその逆のアクションを実行するように設定した場合、どうなりますか?** これは、Cache-Control ヘッダーに no-store ディレクティブがある状態で応答をキャッシュに保存するように設定したときと同じになります。 この場合、応答は保存されません。キャッシュに応答を保存したり、キャッシュの応答を検索したりできるようにするには、Cache-Contro ヘッダーとキャッシュの両方を設定する必要があります。 **省略可能なパラメーターを定義しないとどうなりますか?** `invalidation`​ ヘッダーを設定していない場合、要求のキャッシュを無効化できません。 また、要求式や応答式を設定していない場合、キャッシュはすべての要求に対して使用され、すべての応答がキャッシュに保存されます (式 #\[true\])。 **\[Invalidation header (無効化ヘッダー)\] の値を変更できますか?** いいえ。変更できるのはヘッダー名のみです。