[オンプレミス]{class="badge informative" title="Adobe Commerce オンプレミス プロジェクトにのみ適用されます。"}
パフォーマンス最適化のためのL2 キャッシュ設定
L2 （2 レベル）キャッシュでは、各web ノードにローカルキャッシュレイヤーを追加することで、リモートキャッシュサービスとCommerce アプリケーション間のネットワークトラフィックを削減します。 標準のCommerce インスタンスでは、リクエストごとに約300 KBを転送できます。 リクエスト量が多い場合、ネットワークトラフィックは大きくなる可能性があります。
L2 キャッシュでは、各web ノードは頻繁にアクセスされるデータをローカルに保存し、次の2つの目的でリモートキャッシュを使用します。
- キャッシュデータのバージョンを確認して、最新のキャッシュがローカルに保存されていることを確認する
- 更新されたキャッシュデータをリモートキャッシュサービスからローカルマシンに転送する
Commerceは、ハッシュ化されたデータバージョンをリモートキャッシュに保存し、サフィックス :hashを通常のキーに追加します。 ローカルキャッシュが古くなると、データはキャッシュアダプタを介してリモートキャッシュサービスから取得されます。
使用可能なL2 キャッシュの実装は、Commerceのバージョンとパッチレベルによって異なります。
Cm_Cache_Backend_Fileを含むZend ベースの2 レベルキャッシュRemoteSynchronizedCache L2 キャッシュ設定
RemoteSynchronizedCache L2設定について説明します。このバージョンは、正確なCommerce リリースとパッチレベルのサポート マトリックスでサポートされています。.magento.env.yamlのデプロイメント変数を使用してL2 キャッシュを設定します。 app/etc/env.phpを直接編集しないでください。 L2 キャッシュの設定を参照してください。キャッシュの設定手順は、Commerceのバージョンによって異なります。
RedisをサポートするAdobe Commerce オンプレミス バージョンの場合、次の例を使用して、app/etc/env.php ファイルの既存のキャッシュ セクションを変更または置き換えます。
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
],
'frontend_options' => [
'write_control' => false,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
],
]
どこで：
-
backendはL2 キャッシュ実装です。 -
backend_optionsはL2 キャッシュ設定です。remote_backendは、Commerce リリースとパッチレベルのサポートに応じて、RedisまたはValkeyのリモートキャッシュ実装です。remote_backend_optionsはリモート キャッシュ設定です。local_backendはローカル キャッシュ実装です：Cm_Cache_Backend_File。local_backend_optionsはローカル キャッシュ設定です。cache_dirは、ローカルキャッシュが保存されるディレクトリを定義するファイルキャッシュ固有のオプションです。
RedisまたはValkeyをサポートする2.4.9より前のAdobe Commerce バージョンの場合、Adobeでは、正確なリリースでサポートされているように、リモートキャッシュにはRedisまたはValkeyを使用し、ローカルキャッシュにはCm_Cache_Backend_Fileを使用することをお勧めします。 ローカルキャッシュは、通常、/dev/shm/などの一時ファイルシステムに保存されます。
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
Adobeでは、Redisの負荷を軽減するため、[cache preload](redis-pg-cache.md#redis-preload-feature)機能の使用をお勧めします。 プリロード キーのサフィックス :hashを追加してください。
古いキャッシュオプション
Commerce 2.4以降、use_stale_cache オプションは、以前にキャッシュされたデータを処理し、新しいキャッシュデータを並行プロセスで生成することで、特定の場合のパフォーマンスを向上させることができます。 この節で説明する推奨キャッシュの種類とトレードオフは、RemoteSynchronizedCacheとsymfony_l2の両方の実装に適用されます。 symfony_l2の設定例については、古いキャッシュを持つSymfony L2 キャッシュ を参照してください。
一般的に、ロック待ちのトレードオフは、パフォーマンスの観点から許容されます。 ただし、ブロック数やキャッシュエントリ数が増えると、ロック待ちに時間がかかります。 一部のシナリオでは、プロセスの待機時間は最大キー数 x 検索タイムアウトです。 まれに、ユーザーがBlock/Config キャッシュに数百のキーを持つことがあるため、ロックの小さなルックアップタイムアウトでも数秒かかる場合があります。
'use_stale_cache' => trueを追加します。Adobeでは、use_stale_cache オプションを有効にすることをお勧めします。これには、次のようなキャッシュタイプが最も利用されます。
block_htmlconfig_integration_apiconfig_integrationfull_pagelayoutreflectiontranslate
Adobeでは、default キャッシュタイプにuse_stale_cache オプションを有効にすることはお勧めしません。
次のコードは、RemoteSynchronizedCache バックエンドの設定例を示しています。 symfony_l2の例については、古いキャッシュを持つSymfony L2 キャッシュ を参照してください。
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
],
'frontend_options' => [
'write_control' => false,
],
],
'stale_cache_enabled' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
],
'use_stale_cache' => true,
],
'frontend_options' => [
'write_control' => false,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
'layout' => ['frontend' => 'stale_cache_enabled'],
'block_html' => ['frontend' => 'stale_cache_enabled'],
'reflection' => ['frontend' => 'stale_cache_enabled'],
'config_integration' => ['frontend' => 'stale_cache_enabled'],
'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
'full_page' => ['frontend' => 'stale_cache_enabled'],
'translate' => ['frontend' => 'stale_cache_enabled']
],
],
Symfony L2 キャッシュ実装
Commerce バージョン 2.4.9以降では、RemoteSynchronizedCacheの代わりにSymfony L2 キャッシュ実装（symfony_l2 バックエンド）を使用します。 Symfony L2 キャッシュは、Valkeyを使用してPSR-6準拠のキャッシュ実装を提供します。
- Adobe Commerce 2.4.9以降
- Adobe Commerce 2.4.8-p4以降のパッチ
- Adobe Commerce 2.4.7-p9以降のパッチ
- Adobe Commerce 2.4.6-p14以降のパッチ
- Adobe Commerce 2.4.5-p16以降のパッチ
symfony_l2を設定する場合は、リモート キャッシュ サービスにValkeyを使用する必要があります。 Valkeyの設定を参照してください。RemoteSynchronizedCacheからSymfony L2への移行
オンプレミスのインストールをRemoteSynchronizedCache バックエンドからsymfony_l2にアップグレードする場合は、app/etc/env.phpを更新する前に、次の点を確認してください。 backend値のみを変更するだけでは不十分です。 設定構造、キー名、および一部のデフォルト動作が異なります。
-
構成構造が変更されます。
remote_backend、remote_backend_optionsおよびlocal_backendは、symfony_l2の下で異なる値を使用しています。 例えば、remote_backendは完全修飾クラス名ではなく'valkey'になります。 既存のRemoteSynchronizedCache設定を編集するのではなく、以下の設定の例を出発点として使用します。 -
preload_keysはsymfony_l2.では推奨されませんRemoteSynchronizedCache設定にpreload_keysが含まれている場合は、移行の一部として削除します。 キーのプリロードはsymfony_l2のパフォーマンスを向上させず、追加の不要なキー検索をトリガーすることでValkeyの負荷を増やす可能性があります。 -
圧縮には明示的なフラグが必要です。
compression_libのみを設定すると、symfony_l2の下で圧縮が有効になりません。 必要なcompress_data設定については、Symfony L2 キャッシュのバックエンドオプション を参照してください。 -
手動で構成されたオンプレミスのデプロイメントでは、デフォルトで古いキャッシュが有効になっていません。
use_stale_cacheのデフォルトはsymfony_l2のfalseです（ バックエンドオプションの表を参照）。RemoteSynchronizedCache設定でstale_cache_enabledフロントエンドを使用している場合は、Symfony L2 キャッシュのパターンを使用して、古いキャッシュ で明示的に再作成する必要があります。
VALKEY_BACKEND: symfony_l2 デプロイ変数を設定するAdobe Commerce on Cloud環境には、stale_cache_enabled フロントエンドを含む完全なL2設定がece-toolsによって自動生成されます。 クラウド固有の動作については、Symfony L2 キャッシュの設定を参照してください。- Redisは、
symfony_l2のサポートされているリモート バックエンドではありません。 この変更の一環としてValkeyに移行します。 Valkeyの設定を参照してください。
Symfony L2 キャッシュを使用した設定例
app/etc/env.phpの例は、オンプレミス インストールにのみ適用されます。 Adobe Commerce on Cloud インフラストラクチャの場合、app/etc/env.phpを直接編集しないでください。 VALKEY_BACKEND: symfony_l2を.magento.env.yamlに設定します。 ece-toolsは、展開中にL2 キャッシュ設定を生成して維持します。 Symfony L2 キャッシュの設定を参照してください。app/etc/env.php ファイルで、L2 キャッシュに簡略化されたsymfony_l2 バックエンド タイプを使用します。 この例には、symfony_l2では推奨されていないpreload_keys設定は含まれていません。 詳しくは、RemoteSynchronizedCacheからSymfony L2への移行を参照してください。
例では、cleanup_percentageを90に設定します。 デフォルト値は95です。 利用可能なローカルキャッシュストレージとCommerceのデプロイメントの要件に従って、この値を調整します。
'cache' => [
'frontend' => [
'default' => [
'backend' => 'symfony_l2',
'backend_options' => [
// L2 (Remote): Valkey with Symfony Cache
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'compress_data' => '1',
'persistent_id' => 'magento_l2_default',
'timeout' => '2.5',
'read_timeout' => '2.0',
'use_lua' => '1',
],
// L1 (Local): File cache
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1'
],
'cleanup_percentage' => 90,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
],
],
Symfony L2 キャッシュと古いキャッシュ
どのキャッシュタイプが古いキャッシュから恩恵を受けるか、その理由については、古いキャッシュオプション を参照してください。
次の例を使用して、symfony_l2個の古いキャッシュ サポート用に個別のフロントエンドを設定します。
'cache' => [
'frontend' => [
// Default frontend: NO stale cache
'default' => [
'backend' => 'symfony_l2',
'backend_options' => [
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'compress_data' => '1',
'persistent_id' => 'magento_l2_default',
],
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1'
],
],
],
// Stale cache enabled frontend
'stale_cache_enabled' => [
'backend' => 'symfony_l2',
'backend_options' => [
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'compress_data' => '1',
'persistent_id' => 'magento_l2_stale',
],
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1_stale'
],
'use_stale_cache' => true,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
'layout' => ['frontend' => 'stale_cache_enabled'],
'block_html' => ['frontend' => 'stale_cache_enabled'],
'reflection' => ['frontend' => 'stale_cache_enabled'],
'config_integration' => ['frontend' => 'stale_cache_enabled'],
'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
'full_page' => ['frontend' => 'stale_cache_enabled'],
'translate' => ['frontend' => 'stale_cache_enabled'],
],
],
Symfony L2 キャッシュのバックエンドオプション
remote_backend'valkey'valkeyを使用します。 Redisは正式にはサポートされていません。remote_backend_options[]local_backend'file'fileまたはapculocal_backend_options[]cleanup_percentage95use_stale_cachefalsecompress_datafalsecompression_libと組み合わせると圧縮を有効にします。 このオプションは、リモート Valkey バックエンドオプションで設定します。persistenttruefalse （'0'）に設定します。デフォルトは非永続的な接続です。frontend_options.write_control オプションはRemoteSynchronizedCache設定に適用され、symfony_l2には適用されません。Symfony L2 キャッシュのパフォーマンスと信頼性の向上
symfony_l2を使用したAdobe Commerce 2.4.9のデプロイメントに適用され、ACP2E-5132 パッチで利用できます。ece-toolsの依存関係であるCloud Patches for Commerce パッケージに含まれます。 デプロイメント中に最新のCloud パッチを受け取るには、最新バージョンのece-toolsにアップデートしてください。最新のアップデートにより、Symfony L2 キャッシュのスケーラビリティが向上し、不要なファイルシステム I/Oが減り、キャッシュの一貫性と信頼性が向上しました。
最適化されたSymfony L2 キャッシュタグストレージ
ValkeyがサポートするSymfony L2 キャッシュのデプロイメントの場合、キャッシュタグはValkeyにのみ保存されます。 これにより、冗長なファイルシステムのタグインデックス書き込みが不要になり、ディスク I/Oが減少し、var/cache/symfony/tags/ ディレクトリが不要に増えるのを防ぐことができます。
ファイルベースのキャッシュ動作の改善
ファイルベースのキャッシュ（Valkeyを使用しない）を使用するデプロイメントの場合、ローカルタグインデックスは引き続き維持され、キャッシュの無効化がサポートされます。 タグインデックスは、以前にハードコードされたvar/cacheの場所ではなく、設定されたcache_dirに書き込まれるようになりました。これにより、キャッシュディレクトリの使用状況が一貫し、カスタムキャッシュ設定のサポートが向上しました。
再タグ化後の古いタグメンバーシップの修正
キャッシュエントリを再タグ化すると、そのエントリが属していないタグに関連付けられたままになります。 古いタグメンバーシップは再タグ時にクリアされるようになったため、キャッシュエントリは現在割り当てられているタグによってのみ無効化されます。
変更されていない保存に対する冗長なリモート書き込み修正
変更されていないコンテンツを含むキャッシュエントリを保存すると、リモート（Valkey）バックエンドへの書き込みがトリガーされます。 コンテンツが変更されていないときに保存がスキップされ、不要なリモート書き込みが減少するようになりました。
L1 サイズベースの立ち退き修正（cleanup_percentage）
L1 サイズベースの立ち退きに使用されたしきい値cleanup_percentageは、常にトリガークリーンアップを実行できませんでした。 L1 キャッシュの削除が、設定済みのcleanup_percentageを正しく尊重するようになりました。
古いキャッシュの再生ロック
use_stale_cacheが有効になっていて、エントリのリモートコピーが一時的に利用できない場合、1つのプロセスのみが、そのエントリを再生成するために短時間のみ有効なロックを取得するようになりました。 同じエントリに対するその他の同時リクエストは、それ自体を再生成するのではなく、既存のローカル値を引き続き提供し、再生成スタンプードと冗長なバックエンド負荷を軽減します。
効果
- ValkeyがサポートするSymfony L2 キャッシュのデプロイメントに対する冗長なファイルシステムのタグインデックス書き込みを排除し、ディスク I/Oを減らし、
var/cache/symfony/tags/ディレクトリの不要な増加を防ぎます。 - ファイルベースのキャッシュのデプロイメントでは、キャッシュの無効化の動作を維持しながら、ローカルタグインデックス用に設定された
cache_dirを一貫して使用します。 - 再タグ化後に残された古いタグメンバーシップによる誤ったキャッシュ無効化を防止します。
- 変更されていないキャッシュ保存に対する不要なリモート書き込みを減らし、ネットワークとバックエンドの負荷を軽減します。
- 設定された
cleanup_percentageしきい値でL1 キャッシュの削除を確実にトリガーします。 - キーごとに1つのリジェネレーターを選択することで、
use_stale_cache個のエントリの再生成スタンプを減らします。すべての同時リクエストでエントリを再構築する必要はありません。
設定オプションの詳細については、次を参照してください。