このページの内容は Apigee と Apigee ハイブリッドに該当します。
Apigee Edge のドキュメントを表示する。
このトピックでは、PopulateCache ポリシー、LookupCache ポリシー、InvalidateCache ポリシー、ResponseCache ポリシーなどのポリシーの基礎となるキャッシュの仕組みについて説明します。
キャッシュとは
キャッシュ ポリシーを実行すると、有効期間の短い L1 キャッシュが作成されます。1 秒経過した後、キャッシュに保存されたアイテムにアクセスしなかった場合、そのアイテムはデータベースに保持され、キャッシュが期限切れになるまで、環境にデプロイされたすべての Message Processor で利用できるようになります。キャッシュ ポリシーで有効期限を直接構成します。
メモリ内キャッシュ レベルと永続キャッシュ レベル
共有キャッシュと環境キャッシュはどちらも、次の図に示すように、メモリ内レベルおよび永続性レベルの 2 レベルからなるシステムで構築されます。ポリシーは、2 つのレベルを単一フレームワークと見なして両方とやり取りします。Apigee によって、このレベル間の関係が管理されます。
- レベル 1 はメモリ内キャッシュ（L1）であり、迅速なアクセスの確保を目的とします。各メッセージ処理（MP）ノードは、リクエストに素早く応答できるよう、独自のメモリ内キャッシュを備えています。
- L1 は有効期間が短い（1 秒）、メモリ内キャッシュです。
- メモリの上限に達すると、Agipee はメモリからキャッシュ エントリを削除して（ただし L2 永続性キャッシュに引き続き保持されます）、メモリを他の目的に使用できるようにします。
- L1 は有効期間が短い 1 秒間のキャッシュを備えており、同じキャッシュキーを使用した同時リクエストの高速ルックアップを実行できます。
- メモリ内キャッシュの下のレベル 2 は永続キャッシュ（L2）です。すべてのメッセージ処理ノードが、永続性キャッシュ エントリの保存用に 1 つのキャッシュ データストア（Cassandra）を共有します。
- メモリ内キャッシュの上限に達するなどして L1 キャッシュから削除された場合でも、この場所にキャッシュ エントリが存続します。
- 永続性キャッシュは、複数の Message Processor（異なるリージョンに存在する場合を含む）間で共有されるため、キャッシュ データのリクエストを受信したのがどのノードであっても、キャッシュ エントリにアクセスできます。
- 特定のサイズのエントリのみがキャッシュに保存可能で、その他のキャッシュの上限が適用されます。キャッシュの制限の管理をご覧ください。
- L2 のキャッシュ コンテンツは、AES-256 アルゴリズムで暗号化されています。データはランタイムで使用する前に復号され、L2 に書き込まれる前に暗号化されます。そのため、暗号化処理はユーザーに表示されません。
ポリシーでのキャッシュの使い方
以下では、キャッシュ ポリシーが機能するときに、Apigee がキャッシュ エントリを処理する方法について説明します。
- ポリシーがキャッシュに新しいエントリを書き込む場合（PopulateCache ポリシーまたは ResponseCache ポリシー）:
- Apigee は、リクエストを処理した Message Processor でのみ、エントリをメモリ内 L1 キャッシュに書き込みます。エントリの有効期限が切れる前に Message Processor のメモリ上限に達した場合、Apigee によって L1 キャッシュからエントリが削除されます。
- Apigee によって、エントリは L2 キャッシュにも書き込まれます。
- ポリシーがキャッシュから読み取る場合（LookupCache ポリシーまたは ResponseCache ポリシー）:
- Apigee は最初に、リクエストを処理するメッセージ プロセッサのメモリ内 L1 キャッシュでエントリを探します。
- 該当するメモリ内エントリがない場合、Apigee は L2 永続キャッシュでエントリを検索します。
- エントリが永続キャッシュにない場合:
- LookupCache ポリシー: キャッシュから値は取得されません。
- ResponseCache ポリシー: Apigee によってターゲットから実際のレスポンスがクライアントに返され、エントリは期限切れになるか、無効になるまでキャッシュに保存されます。
- 既存のキャッシュ エントリがポリシーによって更新または無効化された場合（InvalidateCache ポリシー、PopulateCache ポリシー、ResponseCache ポリシー）:
- リクエストを受信した Message Processor は、1 秒間のメモリ内 L1 キャッシュからエントリを削除し、L2 キャッシュからもエントリを削除します。
- 更新または無効化後も、他の Message Processor がメモリ内 L1 キャッシュに保持される可能性があります。
- L1 は 1 秒後に期限切れになるように構成されているため、L1 からエントリを削除するために削除 / 更新のイベントは必要ありません。
キャッシュの制限の管理
キャッシュのいくつかの側面を構成することで、管理が可能です。メモリ内キャッシュに利用可能な全体的な容量は、システム リソースによる制約を受けるため、構成できません。キャッシュには次の制約が適用されます。
- キャッシュの制限: さまざまなキャッシュの制限が適用されます（名前や値のサイズ、キャッシュの合計数、キャッシュのアイテム数、有効期間など）。
-
メモリ内（L1）キャッシュ。キャッシュのメモリ上限を構成することはできません。多数の顧客のキャッシュをホストする Message Processor ごとに、Apigee によって上限が設定されます。
ホスト型クラウド環境では、すべての顧客のデプロイで使用されるメモリ内キャッシュが複数の共有 Message Processor でホストされます。この場合、Apigee による構成可能なメモリしきい値（パーセント）が各プロセッサで指定され、キャッシュ処理によってアプリケーションのメモリを使い切ることがないようにします。このしきい値を超える Message Processor があると、最も長く使われていない順にキャッシュ エントリがメモリから削除されます。メモリから削除されたエントリは、有効期限切れになるか無効にされるまで、L2 キャッシュに保持されます。
- 永続性（L2）キャッシュ。メモリ内キャッシュから削除されたエントリは、構成可能な有効期間設定に基づいて永続キャッシュに残ります。
構成可能な最適化
次の表は、キャッシュのパフォーマンスを最適化するために使用できる設定を示したものです。
| 設定 | 説明 | 注 |
|---|---|---|
| 有効期限 | キャッシュ エントリの有効期間を指定します。 | なし |