キャッシュの仕組み

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

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

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

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

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

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

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

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

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

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

Apigee Edge Caching In Detail という投稿が Apigee コミュニティにありますので、こちらも参考にしてください。

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

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

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

キャッシュの制限の管理

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

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

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

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

構成可能な最適化

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

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