キャッシュの仕組み

このトピックでは、Populate Cache ポリシー、LookupCache ポリシー、InvalidateCache ポリシー、Response Cache ポリシーなどのポリシーの基礎となるキャッシュの仕組みについて説明します。

共有キャッシュと環境キャッシュ

2 種類のキャッシュ、すなわちアプリケーションがアクセスできる組み込み済みの共有キャッシュと、環境をスコープとし、ユーザーが作成する 1 つ以上のキャッシュのいずれかを使用して、各キャッシュ ポリシーを構成できます。

• 共有キャッシュ: デフォルトで、プロキシは各環境にある 1 つの共有キャッシュにアクセスできます。基本的なユースケースには、共有キャッシュが適しています。

  Management API ではなく、キャッシュ ポリシーのみを使用して共有キャッシュを操作できます。キャッシュ ポリシーで共有キャッシュを使用するには、ポリシーの <CacheResource> 要素を単に省略します。

• 環境キャッシュ: 選択した値を使用してキャッシュ プロパティを構成する場合は、環境をスコープとするキャッシュを作成します。キャッシュの作成の詳細については、環境キャッシュの作成と編集をご覧ください。

  環境キャッシュを作成する際に、デフォルト プロパティを構成します。キャッシュ ポリシーで環境キャッシュを使用するには、ポリシーの <CacheResource> 要素でキャッシュ名を指定します。

キャッシュの暗号化について

Edge for Public Cloud: キャッシュは、PCI と HIPAA が有効にされた組織でのみ暗号化されます。これらの組織での暗号化は、組織のプロビジョニング時に構成されます。

メモリ内キャッシュ レベルと永続性キャッシュ レベル

共有キャッシュと環境キャッシュはどちらも、メモリ内レベルおよび永続性レベルの 2 レベルからなるシステムで構築されます。ポリシーは、2 つのレベルを単一フレームワークと見なして両方とやり取りします。Edge はこれらのレベル間の関係を管理します。

• レベル 1 はメモリ内キャッシュ（L1）であり、迅速なアクセスの確保を目的とします。メッセージを処理する各ノード（MP）には、リクエストに素早く応答できるよう、独自のメモリ内キャッシュ（Ehcache を基に実装）が備えられています。
  • 各ノードでは、所定の割合のメモリがキャッシュ用に予約されます。
  • メモリの上限に達すると、Agipee Edge はメモリからキャッシュ エントリを削除して（ただし L2 永続性キャッシュに引き続き保持されます）、メモリを他の目的に使用できるようにします。
  • エントリの削除は最終アクセス時刻の順に行われ、最も古いエントリが最初に削除されます。
  • メモリ内キャッシュは、キャッシュ内のエントリの数によっても制限されます。
• メモリ内キャッシュの下のレベル 2 は永続キャッシュ（L2）です。すべてのメッセージ処理ノードが、永続性キャッシュ エントリの保存用に 1 つのキャッシュ データストア（Cassandra）を共有します。
  • メモリ内キャッシュの上限に達するなどして L1 キャッシュから削除された場合でも、この場所にキャッシュ エントリが存続します。
  • 永続性キャッシュは、複数の Message Processor（異なるリージョンに存在する場合を含む）間で共有されるため、キャッシュ データのリクエストを受信したのがどのノードであっても、キャッシュ エントリにアクセスできます。
  • 特定のサイズのエントリのみをキャッシュでき、その他のキャッシュの制限が適用されます。 キャッシュの制限の管理をご覧ください。

Apigee コミュニティの「Apigee Edge Caching In Detail」というタイトルの投稿もご覧ください。

ポリシーでのキャッシュの使い方

ここでは、キャッシュ ポリシーが機能する際に Apigee Edge でキャッシュ エントリがどのように扱われるかを説明します。

• ポリシーがキャッシュに新しいエントリを書き込む場合（PopulateCache ポリシーまたは ResponseCache ポリシー）:
  1. Edge は、リクエストを処理した Message Processor でのみ、エントリをメモリ内 L1 キャッシュに書き込みます。エントリの有効期限が切れる前に Message Processor のメモリ上限に達した場合、Edge は L1 キャッシュからエントリを削除します。
  2. Edge はエントリを L2 キャッシュにも書き込みます。
• ポリシーがキャッシュから読み取る場合（LookupCache ポリシーまたは ResponseCache ポリシー）:
  1. Edge は最初に、リクエストを処理する Message Processor のメモリ内 L1 キャッシュでエントリを検索します。
  2. 該当するメモリ内エントリがない場合、Edge は L2 永続性キャッシュでエントリを検索します。
  3. エントリが永続性キャッシュにもない場合:
     • LookupCache ポリシー: キャッシュから値が取得されません。
     • ResponseCache ポリシー: Edge はターゲットからの実際のレスポンスをクライアントに返し、エントリが期限切れになるか無効にされるまで、キャッシュにエントリを保存します。
• 既存のキャッシュ エントリ（InvalidateCache、PopulateCache、または ResponseCache の各ポリシー）がポリシーによって更新または無効化された場合:
  1. リクエストを受信した Message Processor は、そのプロセッサ自体、およびすべてのリージョンにある他のすべての Message Processor で L1 キャッシュ内の当該エントリを更新または削除するようブロードキャストを送信します。
     • ブロードキャストが成功すると、それぞれの受信側の Message Processor で L1 キャッシュ内の当該エントリが更新または削除されます。
     • ブロードキャストが失敗すると、ブロードキャストを受信しなかった Message Processor の L1 キャッシュには、無効になったキャッシュ値が残ります。該当するエントリの有効期間が経過するか、Message Processor のメモリ上限に達してエントリが削除されるまで、これらの Message Processor の L1 キャッシュには古いデータが保持されます。
  2. ブロードキャストにより、L2 キャッシュ内の該当エントリも更新または削除されます。

キャッシュの制限の管理

キャッシュのいくつかの側面を構成することで、管理が可能です。メモリ内キャッシュに利用可能な全体的な容量は、システム リソースによる制約を受けるため、構成できません。キャッシュには次の制約が適用されます。

• キャッシュの制限: さまざまなキャッシュの制限が適用されます（名前や値のサイズ、キャッシュの合計数、キャッシュのアイテム数、有効期間など）。
• メモリ内（L1）キャッシュ。キャッシュのメモリ上限を構成することはできません。多数の顧客のキャッシュをホストする Message Processor ごとに、Apigee によって上限が設定されます。

  ホスト型クラウド環境では、すべての顧客のデプロイで使用されるメモリ内キャッシュが複数の共有 Message Processor でホストされます。この場合、Apigee による構成可能なメモリしきい値（パーセント）が各プロセッサで指定され、キャッシュ処理によってアプリケーションのメモリを使い切ることがないようにします。このしきい値を超える Message Processor があると、最も長く使われていない順にキャッシュ エントリがメモリから削除されます。メモリから削除されたエントリは、有効期限切れになるか無効にされるまで、L2 キャッシュに保持されます。

• 永続性（L2）キャッシュ。メモリ内キャッシュから削除されたエントリは、構成可能な有効期間設定に基づいて永続性キャッシュに保持されます。

構成可能な最適化

以下の表に、キャッシュのパフォーマンスを最適化するために使用できる設定を示します。これらの設定の値は、環境キャッシュの作成と編集で説明されているように、新しい環境キャッシュを作成する際に指定できます。

設定	説明	注
Expiration	キャッシュ エントリの有効期間を指定します。	なし