[Commerce on Cloud]{class="badge informative" title="Cloud プロジェクト上のAdobe Commerceにのみ適用されます。"}
ValkeyとRedis サービス設定のベストプラクティス
Adobe Commerce on Cloud デプロイメント用にRedisまたはValkeyをAdobe Commerce アプリケーションキャッシュ、セッションストレージ、およびL2 キャッシュに設定する場合は、次の推奨事項を使用します。
Adobe Commerce オンプレミス キャッシュ設定については、 パフォーマンス最適化のためのL2 キャッシュ設定を参照してください。
主な内容:
- サポートされているキャッシュサービスを選択
- レプリカ接続の有効化
- キャッシュインスタンスとセッションインスタンスの分離
- キャッシュ圧縮の設定
- 非同期解放を有効にする
- マルチスレッド I/Oを有効にする
- クライアントのタイムアウトと再試行の増加
- プリロードキー、古いキャッシュ、およびSymfony個のL2 キャッシュを含むL2 キャッシュを設定します
- 設定例の確認
サポートされているキャッシュサービスを選択
Redisは、Adobe Commerce 2.4.9およびシステム要件がValkeyを指定するパッチリリースのキャッシュ設定ではサポートされていません。 キャッシュバックエンドオプションとストレージリファレンス および システム要件で、Commerceのバージョン、パッチレベル、サービスバージョンを常に確認してください。
ece-tools パッケージを使用していることを確認してください。 そうでない場合は、最新バージョン にアップグレードしてください。 ローカル環境にインストールされているバージョンは、composer show magento/ece-tools CLI コマンドを使用して確認できます。レプリカ接続の有効化
.magento.env.yaml ファイルでレプリカ接続を有効にします。 この変更により、Adobe Commerceでは、プライマリエンドポイントを書き込みに引き続き使用しながら、読み取りに追加のキャッシュ接続を使用できます。 この設定により、プライマリキャッシュサービスの読み取り負荷を軽減し、より効果的に読み取りトラフィックを分散させることができます。
ece-tools バージョンによって異なります。 この設定に依存する前に、echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_ppを実行してUSE_SLAVE_CONNECTION エントリを確認し、サービスにレプリカ関係が存在することを確認してください。 トポロジがレプリカ エンドポイントをプロビジョニングしているかどうかを確認するには、ece-toolsをアップグレードして再デプロイするか、USE_SLAVE_CONNECTION エントリが存在しない場合はAdobe Commerce サポートにお問い合わせください。symfony_l2の場合、レプリカ接続のサポートはece-toolsおよびCloud Patchesの更新プログラムを通じて提供されます。 VALKEY_USE_SLAVE_CONNECTION: trueを変更するよりも追加のキャッシュ設定は必要ありません。 最新のece-tools バージョンに更新して、修正プログラムを受け取ります。Valkeyの場合は、次を使用します。
| code language-yaml |
|---|
|
環境変数の設定の詳細については、Commerce on Cloud Infrastructure ガイドのVALKEY_USE_SLAVE_CONNECTIONを参照してください。
Redisの場合は、次を使用します。
| code language-yaml |
|---|
|
環境変数の設定の詳細については、Commerce on Cloud Infrastructure ガイドのREDIS_USE_SLAVE_CONNECTIONを参照してください。
キャッシュインスタンスとセッションインスタンスの分離
キャッシュとセッションの設定は独立しています。 使用するキャッシュ バックエンドまたはL2 キャッシュ実装にかかわらず、SESSION_CONFIGURATIONはキャッシュの動作に影響しません。 キャッシュをセッションから分離すると、キャッシュを個別に管理できます。 キャッシュとセッショントラフィック間の競合を減らし、キャッシュ関連のプレッシャーがセッションに影響を与えるのを防ぎ、各RedisまたはValkey インスタンスを独自のワークロードに合わせてサイズと調整を行うことができます。
.magento/services.yamlおよび.magento.app.yaml個のファイルを含むAdobe Commerce サポートチケット を送信する必要があります。セッション用の専用インスタンスをプロビジョニングするには、次の手順に従います。
-
.magento/services.yaml設定ファイルを更新し、<version>を使用しているサービス バージョンに置き換えます。 サポートされているサービス バージョンについては、必要システム構成を参照してください。code language-yaml mysql: type: mysql:<version> disk: 35000 valkey: type: valkey:<version> valkey-session: # This is for the new Valkey instance type: valkey:<version> search: type: elasticsearch:<version> disk: 5000 rabbitmq: type: rabbitmq:<version> disk: 2048 -
.magento.app.yaml設定ファイルを更新します。code language-yaml relationships: database: "mysql:mysql" valkey: "valkey:valkey" valkey-session: "valkey-session:valkey" # Relationship of the new Valkey instance search: "search:elasticsearch" rabbitmq: "rabbitmq:rabbitmq" -
実稼動環境とステージング環境のセッション専用の新しいValkey インスタンスをリクエストします。
Adobe Commerce サポートチケット を送信します。 更新された
.magento/services.yamlおよび.magento.app.yaml設定ファイルを含めます。このアップデートはダウンタイムを引き起こしませんが、新しいサービスをアクティブ化するにはデプロイメントが必要です。
-
新しいインスタンスが実行中であることを確認し、ポート番号を書き留めます。
code language-shell echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp -
ポート番号を
.magento.env.yaml設定ファイルに追加します。note important IMPORTANT Valkey セッションポートを設定するのは、 ece-toolsがMAGENTO_CLOUD_RELATIONSHIPSValkey セッションサービス定義から自動的に検出できない場合のみです。note NOTE パフォーマンスを最適化するために disable_lockingを1に設定します。 同時セッションのアクティビティが多いために競合状態が発生するまれに、ロックを有効にするには0に設定します。code language-yaml SESSION_CONFIGURATION: _merge: true redis: # keep 'redis' even if you are using Valkey. timeout: 5 disable_locking: 1 bot_first_lifetime: 60 bot_lifetime: 7200 max_lifetime: 2592000 min_lifetime: 60 -
Valkey キャッシュインスタンスの デフォルト データベース (
db 0)からセッションを削除します。code language-terminal valkey-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
-
.magento/services.yaml設定ファイルを更新し、<version>を使用しているサービス バージョンに置き換えます。code language-yaml mysql: type: mysql:<version> disk: 35000 redis: type: redis:<version> redis-session: # This is for the new Redis instance type: redis:<version> search: type: elasticsearch:<version> disk: 5000 rabbitmq: type: rabbitmq:<version> disk: 2048 -
.magento.app.yaml設定ファイルを更新します。code language-yaml relationships: database: "mysql:mysql" redis: "redis:redis" redis-session: "redis-session:redis" # Relationship of the new Redis instance search: "search:elasticsearch" rabbitmq: "rabbitmq:rabbitmq" -
実稼動環境とステージング環境のセッション専用の新しいRedis インスタンスをリクエストします。
Adobe Commerce サポートチケット を送信します。 更新された
.magento/services.yamlおよび.magento.app.yaml設定ファイルを含めます。このアップデートはダウンタイムを引き起こしませんが、新しいサービスをアクティブ化するにはデプロイメントが必要です。
-
新しいインスタンスが実行中であることを確認し、ポート番号を書き留めます。
code language-shell echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp -
ポート番号を
.magento.env.yaml設定ファイルに追加します。note important IMPORTANT ece-toolsがMAGENTO_CLOUD_RELATIONSHIPSRedis セッション サービス定義から自動的に検出できない場合にのみ、Redis セッション ポートを設定します。note NOTE パフォーマンスを最適化するために disable_lockingを1に設定します。 同時セッションのアクティビティが多いために競合状態が発生するまれに、ロックを有効にするには0に設定します。code language-yaml SESSION_CONFIGURATION: _merge: true redis: timeout: 5 disable_locking: 1 bot_first_lifetime: 60 bot_lifetime: 7200 max_lifetime: 2592000 min_lifetime: 60 -
Redis キャッシュインスタンスの デフォルト データベース (
db 0)からセッションを削除します。code language-terminal redis-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
キャッシュ圧縮
6 GBを超えるRedisまたはValkey maxmemoryを使用する場合は、キャッシュ圧縮を有効にして、キーが消費する領域を削減できます。 この設定は、メモリの節約のためにクライアント側のパフォーマンスをトレードすることに注意してください。 CPUのキャパシティが空いている場合は、有効にすることを検討してください。 設定ガイドの「 セッションストレージにRedisを使用する」または「 セッションストレージにValkeyを使用する」を参照してください。
stage:
deploy:
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
compress_data: 4 # 0-9
compress_tags: 4 # 0-9
compress_threshold: 20480 # don't compress files smaller than this value
compression_lib: 'gzip' # snappy and lzf for performance, gzip for high compression (~69%)
非同期解放を有効にする
Adobe Commerce クラウドインフラストラクチャでlazyfreeを有効にするには、次のRedisまたはValkey設定を環境に適用することを要求するAdobe Commerce サポートチケット を送信します。
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
lazyfree-lazy-user-del yes
lazyfreeが有効になっている場合、RedisまたはValkeyは、メモリの再利用を、削除、有効期限、サーバー主導の削除、ユーザー削除、レプリカデータセットのフラッシュのために、バックグラウンドスレッドにオフロードします。 これにより、メインスレッドのブロックが減り、リクエストの待ち時間が短縮されます。
lazyfree-lazy-user-del yes オプションを使用すると、DEL コマンドがUNLINKのように動作し、キーのリンクがすぐに解除され、メモリが非同期で解放されます。マルチスレッド I/Oを有効にする
Adobe Commerce クラウドインフラストラクチャでRedis I/O スレッドを有効にするには、以下のI/O スレッド設定をリクエストするAdobe Commerce サポートチケット を送信します。 この設定は、CPUの使用率を高くしながらも、ソケットの読み取り、書き込み、およびメインスレッドからのコマンド解析をオフロードすることで、スループットを向上させます。 負荷の下で検証し、ホストを監視します。
Redisの場合
| code language-text |
|---|
|
Valkeyの場合:
| code language-text |
|---|
|
io-threadsを減らすか、I/O スレッドの読み取りを無効にします。クライアントのタイムアウトと再試行の増加
.magento.env.yamlのバックエンドオプションを調整することで、RedisまたはValkey キャッシュクライアントの許容値を飽和期間の短い期間に増やします。
stage:
deploy:
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
connect_retries: 3 # Number of connection retries
remote_backend_options:
read_timeout: 10 # Timeout
これらの設定により、接続の設定を再試行し、RedisまたはValkeyからの応答により多くの時間をかけることで、短いスパイク中の断続的な接続と読み取りタイムアウトエラーを減らすことができます。
L2 キャッシュの設定
.magento.env.yaml構成ファイルでVALKEY_BACKENDまたはREDIS_BACKENDのデプロイメント変数を設定して、L2 キャッシュを構成します。
Adobe Commerceのクラウドインフラストラクチャでは、2つのL2 キャッシュ実装を使用できます。
- 従来の実装では、
RemoteSynchronizedCacheとCm_Cache_Backend_Fileを使用してローカルストレージを使用しています - 最新の実装では、PSR-6への準拠とパフォーマンスの向上を備えた
symfony_l2を使用しています。 最新の実装では、Valkeyのみがサポートされています。
(Valkeyがサポートされている場合)
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'VALKEY_BACKEND: 'symfony_l2'ValkeyをサポートするCommerce 2.4.8以前のバージョンでは、次の設定を使用します。
| code language-yaml |
|---|
|
Commerce 2.4.9以降では、Symfony L2実装で次の設定を使用します。
| code language-yaml |
|---|
|
Redisをサポートするバージョン 2.4.8以前のCommerce バージョンでは、次を使用します。
| code language-yaml |
|---|
|
環境設定の詳細については、Commerce on Cloud Infrastructure ガイドのREDIS_BACKENDを参照してください。
Symfony L2 キャッシュを使用したValkeyへの移行
既存のAdobe Commerce on Cloud プロジェクトをRemoteSynchronizedCache (RedisまたはValkey)からsymfony_l2に移行する場合は、.magento.env.yamlを更新する前に、次の点を確認してください。
-
デプロイ変数の変更は、
symfony_l2を有効にするのに十分です。VALKEY_BACKEND: symfony_l2のみを設定すると、L2 キャッシュの完全な設定が自動的に構築されます。 以前のRemoteSynchronizedCache設定で使用していたbackend_options構造を手動で再作成する必要はありません。 設定 Symfony L2 キャッシュ を参照してください。 -
既存の設定から
preload_keysを削除します。RemoteSynchronizedCache設定にpreload_keysがCACHE_CONFIGURATIONの下に含まれている場合は、移行の一部として削除します。 詳しくは、 キーのプリロード を参照してください。 -
古いキャッシュ動作が自動的に変更されます。
symfony_l2では、ece-toolsは、RemoteSynchronizedCacheが必要とする手動のフロントエンド設定を必要とせずに、一般的なキャッシュタイプ(layout、block_html、full_page、translateなど)に対する古いキャッシュを自動的に有効にします。 以前に古いキャッシュを手動で設定し、以前の動作を正確に保持する場合は、移行前に古いキャッシュを有効にするを確認してください。 -
圧縮には明示的なフラグが必要です。
CACHE_CONFIGURATIONを通じてsymfony_l2圧縮をカスタマイズする場合、compression_libのみを設定しても圧縮が有効になりません –compress_dataも設定する必要があります。 キャッシュ圧縮を参照してください。 -
Redisは、
symfony_l2のサポートされているリモート バックエンドではありません。 この変更の一環としてValkeyに移行します。 Valkey サービスの設定を参照してください。 -
セッション設定は、この移行の影響を受けません。
SESSION_CONFIGURATIONはキャッシュバックエンドとは独立しているため、symfony_l2に移動する際に変更する必要はありません。 個別のキャッシュとセッションインスタンス を参照してください。
symfony_l2をapp/etc/env.phpで手動で設定しないでください。 ece-toolsが適用され、デプロイメント中に設定が維持されるように、.magento.env.yamlを通じて設定します。 設定 Symfony L2 キャッシュ を参照してください。キーのプリロード
正しいプレースメント(backend_optionsまたはremote_backend_options以下)を使用する場合は、プリロードキーをsymfony_l2設定に適用できます。 ただし、Adobeでは、symfony_l2でプリロードキーを使用することはお勧めしません。 symfony_l2のプリロード実装は、キーを1つずつ取得するので、RemoteSynchronizedCacheと同じようにラウンドトリップを減らすことはなく、パフォーマンス上のメリットを得ることなくValkeyの負荷を増やすことができます。
プリロード機能を使用すると、Magentoがリクエスト中に最初にアクセスしたときに1つのパイプラインで取得する、頻繁に使用されるキーのリストを提供できます。 Magentoは、そのリクエストの残りの部分について取得した値をPHP メモリに保持します。これにより、RedisまたはValkeyへの繰り返しラウンドトリップが削減され、それらのキーのリクエストブートストラップのパフォーマンスが向上します。
RedisまたはValkeyでアクティブなコマンドを監視することで、頻繁に使用されるキーを特定できます。
プリロードキーは、.magento.env.yaml設定ファイルで設定されます。 この例では、RemoteSynchronizedCacheをサポートするAdobe Commerce 2.4.8以前のバージョンの設定を示します。
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
backend_options:
preload_keys: # List the keys to be preloaded
- '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
- '061_GLOBAL_PLUGIN_LIST:hash'
- '061_DB_IS_UP_TO_DATE:hash'
- '061_SYSTEM_DEFAULT:hash'
キーを一覧表示するには、次のコマンドを実行します。
redis-cli -p 6370 -n 1 MONITOR > /tmp/list.keys
10秒後、Ctrl+Cを押します。次に、次のコマンドを実行します。
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50
このログには、プリロードできるキーが一覧表示されます。 キーの内容を確認するには、次のコマンドを実行します。
redis-cli -p 6370 -n 1 hgetall "<key_name>"
古いキャッシュを有効にする
古いキャッシュはL2 キャッシュ機能で、別のリクエストが既に同じエントリを再生成している間に、Adobe Commerceが/dev/shmから既存のローカルキャッシュ値を提供できるようにします。 これにより、同時リクエストが待機するのを防ぐことができます。 これにより、高価なキャッシュエントリの再生中にキャッシュスタンピングとロック競合が減少します。
Adobe Commerce 2.4.9以降では、.magento.env.yaml ファイルにVALKEY_BACKEND: symfony_l2を設定します。
stage:
deploy:
VALKEY_BACKEND: symfony_l2
ece-toolsは、default フロントエンドとstale_cache_enabled フロントエンドの両方を自動的に生成し、次のキャッシュタイプを古い対応フロントエンドにマッピングします:layout、block_html、reflection、config_integration、config_integration_api、full_page、およびtranslate。 これらの種類には、手動のuse_stale_cacheまたはフロントエンド設定は必要ありません。 この自動マッピング自体は、選択的な古いキャッシュ有効化の例です。 特定のキャッシュタイプのみが古い有効なフロントエンドを使用し、そのすべてが使用されるわけではありません。 stale_cache_enabledにマッピングするタイプをカスタマイズする方法、またはデフォルト以外のタイプを追加する方法については、L2 キャッシュ設定のカスタマイズ を参照してください。 Symfony
full_page キャッシュの種類は、ページ全体のキャッシュにFastlyを使用するため、Adobe Commerce on Cloud インフラストラクチャプロジェクトには関係ありません。 この節の手動設定の例では、ece-toolsがデフォルトのsymfony_l2 マッピングに含まれているにもかかわらず、その理由でfull_pageを省略しています。次のレガシー設定は、RemoteSynchronizedCacheを使用し、手動で古いキャッシュとフロントエンド設定を必要とするAdobe Commerce 2.4.8以前に適用されます。 同じ選択的グローバルな推奨事項がここで適用されます。
従来のRemoteSynchronizedCache バックエンドの仕組み
RemoteSynchronizedCacheでは、Magentoは各キャッシュエントリの2つのコピー(/dev/shmのローカルコピーとRedisまたはValkeyのリモートコピー)を保持します。 リモートコピーが利用できず、そのキーに対する再生ロックが既に存在する場合、同時要求は、新しい値が書き込まれるまで待つのではなく、以前のローカル値を受け取ることができます。
2.4.8以前のバージョンの古いキャッシュを有効にするには、.magento.env.yaml ファイルで設定します。
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
use_stale_cache: true
default キャッシュフロントエンドで古いキャッシュが有効になり、そのフロントエンドを使用するすべてのキャッシュエントリに古いキャッシュ動作が適用されます。 Magento コアキャッシュの種類は、この設定で期待どおりに機能します。 ただし、専用のキャッシュフロントエンドを使用せずに汎用\Magento\Framework\App\Cache API (例:$this->cache->save())を介してキャッシュに書き込むカスタムコードまたは拡張機能がプロジェクトに含まれている場合、それらのエントリは再生中に古い値を提供することもできます。default フロントエンドで古いキャッシュを無効のままにし、以下に示すように、選択したキャッシュタイプに対してのみ有効にします。キャッシュタイプごとに個別に古いキャッシュを有効にする(レガシー)
.magento.env.yamlで専用のキャッシュフロントエンドを定義し、選択したキャッシュタイプをそれにマッピングすることで、選択したキャッシュタイプに対してのみ古いキャッシュを有効にできます。 この手動アプローチは、従来のRemoteSynchronizedCache バックエンドに適用されます。symfony_l2は、前述のように、このマッピングを自動的に実行します。
正しく動作させるには、カスタムフロントエンドをCACHE_CONFIGURATION.frontendの下の完全なフロントエンドとして定義する必要があります。 新しいフロントエンド名のuse_stale_cache: trueのみを定義するだけでは不十分です。
設定例
バージョン 2.4.8以前のRedisでは、次の設定により、layout、reflection、config_integration、config_integration_api、およびtranslateのキャッシュタイプの古いキャッシュが有効になりますが、他のユーザーは古いキャッシュが無効なデフォルトのフロントエンドを使用したままになります。
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default: # In this frontend, we keep stale cache set to false.
id_prefix: '001_'
backend_options:
use_stale_cache: false
# Now, create a new frontend called 'stale_cache_enabled'.
# It must contain the same backend connection settings as the frontend 'default':
stale_cache_enabled:
id_prefix: '001_'
backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
backend_options:
remote_backend: '\Magento\Framework\Cache\Backend\Redis'
remote_backend_options:
server: localhost
port: 6370 # Use the same port used by the frontend 'default' in env.php
database: 1
load_from_slave:
server: localhost
port: 26370 # Use the same port used by the frontend 'default' in env.php
retry_reads_on_master: 1
read_timeout: 10
local_backend: 'Cm_Cache_Backend_File'
local_backend_options:
cache_dir: /dev/shm/
use_stale_cache: true # stale cache here is enabled
# Now select which cache types you want to enable (stale_cache_enabled), or disable (default)
type:
default:
frontend: default
layout:
frontend: stale_cache_enabled
reflection:
frontend: stale_cache_enabled
config_integration:
frontend: stale_cache_enabled
config_integration_api:
frontend: stale_cache_enabled
translate:
frontend: stale_cache_enabled
# add other cache types as needed...
stale_cache_enabledにコピーします。Symfony L2 キャッシュの設定
Adobe Commerce 2.4.9以降では、symfony_l2 キャッシュバックエンドがサポートされています。 symfony_l2 バックエンドは、Adobe CommerceがL1およびL2 キャッシュ動作の管理に使用するキャッシュ実装です。 RedisまたはValkeyをリモート キャッシュ サービスとして置き換えることはできません。
ece-toolsがデプロイメント中に設定を適用して維持できるように、.magento.env.yamlのデプロイメント変数を使用してsymfony_l2を設定します。 デプロイメントでは手動env.phpの変更を上書きできるため、app/etc/env.phpでsymfony_l2を手動で設定しないでください。 ece-toolsがsymfony_l2を適用しない場合、Commerceはファイルベースのキャッシュにフォールバックし、ディスク I/Oを増やし、マルチノード環境でファイルシステムレプリケーションのオーバーヘッドを増やし、パフォーマンスを低下させる可能性があります。Adobe Commerce 2.4.9にsymfony_l2 キャッシュを使用するには、次の手順を実行します。
-
クラウドプロジェクトで
ece-toolsパッケージ v2002.2.12以降が使用されていることを確認します。 -
デプロイメント変数を
.magento.env.yamlファイルVALKEY_BACKEND=symfony_l2に設定します。code language-yaml stage: deploy: VALKEY_BACKEND: symfony_l2
VALKEY_BACKENDのデプロイメント変数をsymfony_l2に設定すると、defaultおよびstale_cache_enabled フロントエンドを含むValkey サービス接続の詳細から完全なL2 キャッシュ設定が自動的に構築され、共通のキャッシュタイプが既にマッピングされています。 CACHE_CONFIGURATIONの定義はオプションで、特定のバックエンドオプションをカスタマイズする場合にのみ必要です。
cleanup_percentage)に関する問題の修正により、Symfony L2 キャッシュのパフォーマンスと信頼性を向上させます。 これにより、キャッシュの一貫性を向上させながら、ディスク I/Oとバックエンドの負荷を軽減します。 Adobe Commerce Configuration GuideのEnhanced Symfony L2 cache performance and reliabilityを参照してください。ece-tools)に含まれており、最新のece-tools バージョンに更新すると、デプロイメント中に自動的に適用されます。 最新バージョンのece-toolsに更新して、パッチを受け取ります。Symfony L2 キャッシュ設定のカスタマイズ
ece-toolsは、defaultおよびstale_cache_enabled フロントエンドのValkey接続の詳細(server、port、database、serializer、compression_lib、persistent_id)を自動的に導き出します。 ローカルキャッシュディレクトリなどの他のバックエンドオプションをカスタマイズするには、CACHE_CONFIGURATIONを_merge: trueとVALKEY_BACKEND: symfony_l2で定義します。 ここで定義した値は、対応する自動生成のデフォルトを上書きします。省略したオプションは、ece-toolsが自動的に導き出す値を引き続き使用します。
stage:
deploy:
VALKEY_BACKEND: symfony_l2
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
remote_backend: valkey
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1
stale_cache_enabled:
backend: symfony_l2
backend_options:
remote_backend: valkey
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1_stale
use_stale_cache: true
symfony_l2のCACHE_CONFIGURATIONを定義する場合、プロジェクトのValkey サービス以外のキャッシュエンドポイントを意図的に指している場合にのみ、serverまたはportを上書きします。 ece-tools パッケージは、これらの値をValkey サービス関係から自動的に取得します。serverを上書きする場合、プロジェクトのValkey サービスに接続する際は、その値をlocalhostにする必要があります。 無効なserverまたはport値を指定すると、デプロイメントがキャッシュ接続エラーで失敗します。Adobe Commerce CloudのL2 キャッシュメモリサイズ
L2 キャッシュでは、ストレージメカニズムとして一時ファイルシステム (/dev/shm)が使用されます。 特殊なキー値ストアとは異なり、tmpfsにはキーの立ち退きポリシーがないので、メモリの使用量は制限なく増加する可能性があります。 Adobe Commerceでは、使用状況が設定可能なしきい値(デフォルトでは95%)に達すると、自動的にL2 ストレージがクリアされます。 大きな/dev/shm マウントを要求するか、クリーンアップしきい値を下げることで、メモリ消費を制御できます。
プロジェクトの要件に基づいて、L2 キャッシュメモリの最大使用量を調整します。 次のいずれかの方法を使用します。
/dev/shmマウントサイズを調整するには、サポートチケットを作成します。 この場合、Adobeでは、/dev/shmマウントサイズを15 GBに設定することをお勧めします。- アプリケーションレベルで
cleanup_percentageプロパティを調整して、他のサービスで利用可能なストレージ使用量と空きメモリを制限します。
キャッシュ構成グループcache/frontend/default/backend_options/cleanup_percentageの配備構成で構成を調整できます。
cleanup_percentage オプションは、Adobe Commerce 2.4.4で導入されました。次の例は、.magento.env.yaml ファイルの設定コードを示しています。
Commerce 2.4.9以降では、次の設定を使用して、クリーンアップしきい値を90%に設定します。
| code language-yaml |
|---|
|
Commerce 2.4.8以前の場合は、次の設定を使用して、クリーンアップしきい値を90%に設定します。
| code language-yaml |
|---|
|
キャッシュの要件は、プロジェクトの設定とカスタムのサードパーティコードによって異なります。 L2 キャッシュメモリのサイズを調整して、頻繁なスレッショルドヒットなしでキャッシュを動作できるようにします。
理想的には、L2 キャッシュメモリの使用は、頻繁なストレージのクリアを避けるために、しきい値を下回って安定します。
次のCLI コマンドを実行し、/dev/shm行を確認することで、クラスターの各ノードでのL2 キャッシュストレージメモリの使用状況を確認できます。
df -h /dev/shm
使用状況はノードによって異なりますが、類似の値に収束します。
設定例
RedisまたはValkey サービス設定の出発点として、次の例を使用します。
ベストプラクティスの推奨事項をすべて適用
VALKEY_BACKEND: symfony_l2の場合、ece-toolsがdefaultおよびstale_cache_enabledのフロントエンドとそのキャッシュタイプマッピングを生成します。 広範なdefault フロントエンドにuse_stale_cacheを設定しないでください。 以下のCACHE_CONFIGURATION ブロックには、明示的なバックエンドオプションの上書きのみが含まれています。
| code language-yaml |
|---|
|
Adobe Commerce 2.4.8以前のRedisでは、次の設定を使用します。
| code language-yaml |
|---|
|
キャッシュタイプ別に古いキャッシュを分離する
| code language-yaml |
|---|
|
| code language-yaml |
|---|
|