Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

キャッシュの仕組み

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

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

構成するキャッシュポリシーそれぞれで、2 種類のキャッシュのどちらかを使用できます。アプリケーションにアクセス権のある予め用意された共有キャッシュと、新たに作成する環境キャッシュです。

  • 共有キャッシュ -- プロキシはデフォルトで、作成される環境に予め用意された共有キャッシュにアクセスできます。基本的な使い方には共有キャッシュで十分です。

    You can work with the shared cache only by using caching policies. It can't be managed using the management API. You can have a caching policy use the shared cache by simply omitting the policy's <CacheResource> element.

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

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

Object size limit in cache

The maximum size of each cached object is 512 kb. For more information, see Managing cache limits.

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

Both the shared and environment caches are built on a two-level system made up of an in-memory level and a persistent level. Policies interact with both levels as a combined framework. The relationship between the levels is managed by the system.

  • Level 1 is an in-memory cache (L1) for fast access. Each message processing node has its own in-memory cache (implemented from Ehcache) for the fastest response to requests.
    • 各ノードでは、所定の割合のメモリーがキャッシュ用に予約されます。
    • As the memory limit is reached, Apigee Edge removes cache entries from memory (though they are still kept in the L2 data store) to ensure that memory remains available for other processes.
    • エントリの削除は最後にアクセスされた時刻順に行われ、最も古いエントリが最初に削除されます。
    • メモリー内キャッシュは、キャッシュに存在するエントリの数にも制限されます。
  • Level 2 is a persistent cache (L2) beneath the in-memory cache. All message processing nodes share a cache data store (Cassandra) for persisting cache entries.
    • Cache entries persist here even after they're removed from L1 cache, such as when in-memory limits are reached.
    • Because the persistent cache is shared across message processors (even in different regions), cache entries are available regardless of which node receives a request for the cached data.
    • This cache is limited in that only entries of a certain size may be cached. See Managing cache limits.
    • キャッシュエントリの数に関する制限はありません。永続性キャッシュエントリの有効期間は、有効期間の設定のみで決まります。
For HIPAA (Health Insurance Portability and Accountability Act) and Payment Card Industry (PCI) organizations, cached data is encrypted.
Apigee Edge Caching In Detail」というタイトルの投稿が Apigee コミュニティーにありますので、こちらも参考にしてください。

ポリシーによるキャッシュの使い方

ここからは、キャッシュポリシーによる処理中に Apigee Edge がキャッシュエントリをどう扱っているかについて説明します。

  • When a policy writes a new entry to the cache (PopulateCache or ResponseCache policy):
    1. The entry is written to the in-memory L1 cache on only the message processor that handled the request. If the memory limits on the message processor are reached before the entry expires, the entry is removed from L1 cache.
    2. The entry is also written to L2 cache, as long as it is no larger than 512 kb. Any entry larger than that is not written to L2 cache.
  • When a policy reads from the cache (LookupCache or ResponseCache policy):
    1. The system looks first for the entry in the in-memory L1 cache of the message processor handling the request.
    2. If there's no corresponding in-memory entry, the system looks for the entry in the L2 persistent cache.
    3. If the entry isn't in the persistent cache:
      • LookupCache policy: No value is retrieved from the cache. 
      • ResponseCache policy: The actual response from the target is returned to the client, and the entry is stored in cache until it expires or is invalidated.
  • When a policy updates or invalidates an existing cache entry (InvalidateCache, PopulateCache, or ResponseCache policy):
    1. The message processor receiving the request sends a broadcast to update or delete the entry in L1 cache on itself and all other message processors in all regions.
      • If the broadcast succeeds, each receiving message processor updates or removes the entry in L1 cache.
      • If the broadcast fails, the invalidated cache value remains in L1 cache on the message processors that didn't receive the broadcast. Those message processors will have stale data in L1 cache until the entry's time-to-live expires or is removed when message processor memory limits are reached.
    2. The broadcast also updates or deletes the entry in L2 cache.

キャッシュの制約事項の管理

キャッシュの各種側面は構成を通じて管理します。

The in-memory overall maximum is limited by system resources, and is not configurable. The overall capacity of the persistent cache is effectively unlimited, though the maximum size for each cached object is 512 kb. (While you can add an object larger than 512 kb to in-memory L1 cache, that object won't be added to the more persistent L2 database cache.)
  • In-memory (L1) cache. Memory limits for your cache are not configurable. Limits are set by Apigee for each message processor that hosts caches for multiple customers.

    In a hosted environment*, where in-memory caches for all customer deployments are hosted across multiple shared message processors, each processor features an Apigee-configurable memory percentage threshold to ensure that caching does not consume all of the application's memory. As the threshold is crossed for a given message processor, cache entries are evicted from memory on a least-recently-used basis. Entries evicted from memory remain in L2 cache until they expire or are invalidated.

  • Persistent (L2) cache. There are no limits on the number of entries in the cache, though the size of each object is limited to 512 kb. Entries evicted from the in-memory cache remain in the persistent cache in keeping with configurable time-to-live settings.
* In Edge for Private Cloud, you have finer-grained control over memory used for caching, including the maximum amount available. Although the settings can be changed, it's typically not necessary to alter the default configuration.

構成可能な最適化

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

設定 説明 注記
Skip if element size in KB exceeds If an entry exceeds the specified size, it will be skipped (not cached). This helps prevent caching overly large entries. The maximimum size for a cached object is 512 kb.
Expiration キャッシュエントリの有効期間を指定します。  

 

Help or comments?