[Commerce on Cloud]{class="badge informative" title="Cloud プロジェクト上のAdobe Commerceにのみ適用されます。"}

ValkeyとRedis サービス設定のベストプラクティス

Adobe Commerce on Cloud デプロイメント用にRedisまたはValkeyをAdobe Commerce アプリケーションキャッシュ、セッションストレージ、およびL2 キャッシュに設定する場合は、次の推奨事項を使用します。

Adobe Commerce オンプレミス キャッシュ設定については、​ パフォーマンス最適化のためのL2 キャッシュ設定を参照してください。

NOTE
ここでは、Commerce アプリケーションキャッシュとセッションバックエンドについて説明します。 FastlyやVarnishなどのHTTP フルページキャッシュは、個別のキャッシュレイヤーであり、独立して設定されます。 アプリケーションキャッシュバックエンドを変更しても、HTTP フルページキャッシュは置き換えられず、設定も行われません。

主な内容:

  • サポートされているキャッシュサービスを選択
  • レプリカ接続の有効化
  • キャッシュインスタンスとセッションインスタンスの分離
  • キャッシュ圧縮の設定
  • 非同期解放を有効にする
  • マルチスレッド I/Oを有効にする
  • クライアントのタイムアウトと再試行の増加
  • プリロードキー、古いキャッシュ、およびSymfony個のL2 キャッシュを含むL2 キャッシュを設定します
  • 設定例の確認

サポートされているキャッシュサービスを選択

Adobe Commerce版
推奨キャッシュサービス
L2 キャッシュの実装
2.4.8以前(正確なリリースでサポートされている場合)
RedisまたはValkey
RemoteSynchronizedCache
2.4.9以降
バルキー
symfony_l2

Redisは、Adobe Commerce 2.4.9およびシステム要件がValkeyを指定するパッチリリースのキャッシュ設定ではサポートされていません。 ​ キャッシュバックエンドオプションとストレージリファレンス ​および​ システム要件で、Commerceのバージョン、パッチレベル、サービスバージョンを常に確認してください。

NOTE
最新バージョンのece-tools パッケージを使用していることを確認してください。 そうでない場合は、最新バージョン ​にアップグレードしてください。 ローカル環境にインストールされているバージョンは、composer show magento/ece-tools CLI コマンドを使用して確認できます。

レプリカ接続の有効化

.magento.env.yaml ファイルでレプリカ接続を有効にします。 この変更により、Adobe Commerceでは、プライマリエンドポイントを書き込みに引き続き使用しながら、読み取りに追加のキャッシュ接続を使用できます。 この設定により、プライマリキャッシュサービスの読み取り負荷を軽減し、より効果的に読み取りトラフィックを分散させることができます。

NOTE
レプリカ接続を使用できるかどうかは、プロジェクトのトポロジ(シングルノードとスプリットまたはHA アーキテクチャなど)と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設定

Valkeyの場合は、次を使用します。

code language-yaml
stage:
  deploy:
    VALKEY_USE_SLAVE_CONNECTION: true

環境変数の設定の詳細については、Commerce on Cloud Infrastructure ガイド​のVALKEY_USE_SLAVE_CONNECTIONを参照してください。

Redis設定

Redisの場合は、次を使用します。

code language-yaml
stage:
  deploy:
    REDIS_USE_SLAVE_CONNECTION: true

環境変数の設定の詳細については、Commerce on Cloud Infrastructure ガイド​のREDIS_USE_SLAVE_CONNECTIONを参照してください。

キャッシュインスタンスとセッションインスタンスの分離

キャッシュとセッションの設定は独立しています。 使用するキャッシュ バックエンドまたはL2 キャッシュ実装にかかわらず、SESSION_CONFIGURATIONはキャッシュの動作に影響しません。 キャッシュをセッションから分離すると、キャッシュを個別に管理できます。 キャッシュとセッショントラフィック間の競合を減らし、キャッシュ関連のプレッシャーがセッションに影響を与えるのを防ぎ、各RedisまたはValkey インスタンスを独自のワークロードに合わせてサイズと調整を行うことができます。

IMPORTANT
実稼動環境とステージング環境で専用セッションインスタンスをプロビジョニングすることは、セルフサービスではありません。 次の手順3で説明するように、更新された.magento/services.yamlおよび.magento.app.yaml個のファイルを含むAdobe Commerce サポートチケット ​を送信する必要があります。

セッション用の専用インスタンスをプロビジョニングするには、次の手順に従います。

Valkey
  1. .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
    
  2. .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"
    
  3. 実稼動環境とステージング環境のセッション専用の新しいValkey インスタンスをリクエストします。

    Adobe Commerce サポートチケット ​を送信します。 更新された.magento/services.yamlおよび.magento.app.yaml設定ファイルを含めます。

    このアップデートはダウンタイムを引き起こしませんが、新しいサービスをアクティブ化するにはデプロイメントが必要です。

  4. 新しいインスタンスが実行中であることを確認し、ポート番号を書き留めます。

    code language-shell
    echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp
    
  5. ポート番号を.magento.env.yaml設定ファイルに追加します。

    note important
    IMPORTANT
    Valkey セッションポートを設定するのは、ece-toolsMAGENTO_CLOUD_RELATIONSHIPS Valkey セッションサービス定義から自動的に検出できない場合のみです。
    note
    NOTE
    パフォーマンスを最適化するためにdisable_locking1に設定します。 同時セッションのアクティビティが多いために競合状態が発生するまれに、ロックを有効にするには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
    
  6. Valkey キャッシュインスタンスの​ デフォルト データベース ​db 0)からセッションを削除します。

    code language-terminal
    valkey-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
    
Redis
  1. .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
    
  2. .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"
    
  3. 実稼動環境とステージング環境のセッション専用の新しいRedis インスタンスをリクエストします。

    Adobe Commerce サポートチケット ​を送信します。 更新された.magento/services.yamlおよび.magento.app.yaml設定ファイルを含めます。

    このアップデートはダウンタイムを引き起こしませんが、新しいサービスをアクティブ化するにはデプロイメントが必要です。

  4. 新しいインスタンスが実行中であることを確認し、ポート番号を書き留めます。

    code language-shell
    echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp
    
  5. ポート番号を.magento.env.yaml設定ファイルに追加します。

    note important
    IMPORTANT
    ece-toolsMAGENTO_CLOUD_RELATIONSHIPS Redis セッション サービス定義から自動的に検出できない場合にのみ、Redis セッション ポートを設定します。
    note
    NOTE
    パフォーマンスを最適化するためにdisable_locking1に設定します。 同時セッションのアクティビティが多いために競合状態が発生するまれに、ロックを有効にするには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
    
  6. 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は、メモリの再利用を、削除、有効期限、サーバー主導の削除、ユーザー削除、レプリカデータセットのフラッシュのために、バックグラウンドスレッドにオフロードします。 これにより、メインスレッドのブロックが減り、リクエストの待ち時間が短縮されます。

NOTE
lazyfree-lazy-user-del yes オプションを使用すると、DEL コマンドがUNLINKのように動作し、キーのリンクがすぐに解除され、メモリが非同期で解放されます。
WARNING
解放はバックグラウンドで行われるため、削除されたキー、期限切れのキー、または削除されたキーで使用されるメモリは、バックグラウンドスレッドが作業を完了するまで割り当てられたままになります。 RedisまたはValkey インスタンスが既にメモリの負荷が厳しい場合は、慎重にテストし、まずメモリ負荷を軽減することを検討してください。 例えば、前述のように、特定のケースと個別のキャッシュおよびセッション Redis インスタンスのブロックキャッシュを無効にします。

マルチスレッド I/Oを有効にする

Adobe Commerce クラウドインフラストラクチャでRedis I/O スレッドを有効にするには、以下のI/O スレッド設定をリクエストするAdobe Commerce サポートチケット ​を送信します。 この設定は、CPUの使用率を高くしながらも、ソケットの読み取り、書き込み、およびメインスレッドからのコマンド解析をオフロードすることで、スループットを向上させます。 負荷の下で検証し、ホストを監視します。

RedisのI/O スレッドの設定

Redisの場合

code language-text
io-threads-do-reads yes
io-threads 8 # Choose a value lower than the number of CPU cores (check with nproc), and then tune under load.
ValkeyのI/O スレッドを設定

Valkeyの場合:

code language-text
io-threads-do-reads yes
io-threads 8 # choose a value lower than the number of CPU cores (check with nproc), then tune under load
events-per-io-thread 2
NOTE
I/O スレッドは、クライアント I/Oと解析のみを並列化します。 Redis コマンドの実行はシングルスレッドのままです。
WARNING
I/O スレッドを有効にすると、CPUの使用量が増加する可能性があり、すべてのワークロードにメリットがあるわけではありません。 まず、保守的な値とベンチマークを設定します。 待ち時間が長くなったり、CPUが飽和状態になったりした場合は、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からの応答により多くの時間をかけることで、短いスパイク中の断続的な接続と読み取りタイムアウトエラーを減らすことができます。

NOTE
これらの設定は、一時的な過負荷の解消には役立ちますが、永続的な過負荷を修正することはありません。

L2 キャッシュの設定

.magento.env.yaml構成ファイルでVALKEY_BACKENDまたはREDIS_BACKENDのデプロイメント変数を設定して、L2 キャッシュを構成します。

Adobe Commerceのクラウドインフラストラクチャでは、2つのL2 キャッシュ実装を使用できます。

  • 従来の実装では、RemoteSynchronizedCacheCm_Cache_Backend_Fileを使用してローカルストレージを使用しています
  • 最新の実装では、PSR-6への準拠とパフォーマンスの向上を備えたsymfony_l2を使用しています。 最新の実装では、Valkeyのみがサポートされています。
Commerce版
RemoteSynchronizedCacheとValkey
推奨される設定
2.4.8以前
(Valkeyがサポートされている場合)
サポートされている従来のL2 パス
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
2.4.9以降
サポートされていません
VALKEY_BACKEND: 'symfony_l2'
IMPORTANT
Redis キャッシュは、Adobe Commerce 2.4.9、または2.4.5-p16、2.4.6-p14、2.4.7-p9、および2.4.8-p4以降のパッチリリースではサポートされていません。 Redisがサポートされていないキャッシュ設定にはValkeyを使用します。 リリース別のサポートされているキャッシュサービスについては、必要システム構成を参照してください。
Valkey設定

ValkeyをサポートするCommerce 2.4.8以前のバージョンでは、次の設定を使用します。

code language-yaml
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

Commerce 2.4.9以降では、Symfony L2実装で次の設定を使用します。

code language-yaml
stage:
  deploy:
    VALKEY_BACKEND: 'symfony_l2'
Redis設定

Redisをサポートするバージョン 2.4.8以前のCommerce バージョンでは、次を使用します。

code language-yaml
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

環境設定の詳細については、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_keysCACHE_CONFIGURATIONの下に含まれている場合は、移行の一部として削除します。 詳しくは、​ キーのプリロード ​を参照してください。

  • 古いキャッシュ動作が自動的に変更されます。 symfony_l2では、ece-toolsは、RemoteSynchronizedCacheが必要とする手動のフロントエンド設定を必要とせずに、一般的なキャッシュタイプ(layoutblock_htmlfull_pagetranslateなど)に対する古いキャッシュを自動的に有効にします。 以前に古いキャッシュを手動で設定し、以前の動作を正確に保持する場合は、移行前に古いキャッシュを有効にするを確認してください。

  • 圧縮には明示的なフラグが必要です。 CACHE_CONFIGURATIONを通じてsymfony_l2圧縮をカスタマイズする場合、compression_libのみを設定しても圧縮が有効になりません – compress_dataも設定する必要があります。 ​ キャッシュ圧縮を参照してください。

  • Redisは、symfony_l2のサポートされているリモート バックエンドではありません。 この変更の一環としてValkeyに移行します。 Valkey サービスの設定を参照してください。

  • セッション設定は、この移行の影響を受けません。 SESSION_CONFIGURATIONはキャッシュバックエンドとは独立しているため、symfony_l2に移動する際に変更する必要はありません。 個別のキャッシュとセッションインスタンス ​を参照してください。

IMPORTANT
symfony_l2app/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 フロントエンドの両方を自動的に生成し、次のキャッシュタイプを古い対応フロントエンドにマッピングします:layoutblock_htmlreflectionconfig_integrationconfig_integration_apifull_page、およびtranslate。 これらの種類には、手動のuse_stale_cacheまたはフロントエンド設定は必要ありません。 この自動マッピング自体は、選択的な古いキャッシュ有効化の例です。 特定のキャッシュタイプのみが古い有効なフロントエンドを使用し、そのすべてが使用されるわけではありません。 stale_cache_enabledにマッピングするタイプをカスタマイズする方法、またはデフォルト以外のタイプを追加する方法については、L2 キャッシュ設定のカスタマイズ ​を参照してください。 Symfony

NOTE
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
WARNING
上記の設定により、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では、次の設定により、layoutreflectionconfig_integrationconfig_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...
NOTE
ソースフロントエンドが追加のバックエンドオプションで設定されている場合は、新しいフロントエンドが同じ動作を維持するように、これらのオプションをstale_cache_enabledにコピーします。

Symfony L2 キャッシュの設定

Adobe Commerce 2.4.9以降では、symfony_l2 キャッシュバックエンドがサポートされています。 symfony_l2 バックエンドは、Adobe CommerceがL1およびL2 キャッシュ動作の管理に使用するキャッシュ実装です。 RedisまたはValkeyをリモート キャッシュ サービスとして置き換えることはできません。

IMPORTANT
ece-toolsがデプロイメント中に設定を適用して維持できるように、.magento.env.yamlのデプロイメント変数を使用してsymfony_l2を設定します。 デプロイメントでは手動env.phpの変更を上書きできるため、app/etc/env.phpsymfony_l2を手動で設定しないでください。 ece-toolssymfony_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の定義はオプションで、特定のバックエンドオプションをカスタマイズする場合にのみ必要です。

NOTE
ACP2E-5132 for Adobe Commerce 2.4.9は、タグ ストレージの最適化、古いキャッシュの再生成ロックの追加、古いタグ メンバーシップ、冗長なリモート書き込み、およびL1 サイズ ベースのエビクション (cleanup_percentage)に関する問題の修正により、Symfony L2 キャッシュのパフォーマンスと信頼性を向上させます。 これにより、キャッシュの一貫性を向上させながら、ディスク I/Oとバックエンドの負荷を軽減します。 Adobe Commerce Configuration Guide​のEnhanced Symfony L2 cache performance and reliabilityを参照してください。
このパッチは、Cloud Patches for Commerce パッケージ ​ (依存関係ece-tools)に含まれており、最新のece-tools バージョンに更新すると、デプロイメント中に自動的に適用されます。 最新バージョンのece-toolsに更新して、パッチを受け取ります。

Symfony L2 キャッシュ設定のカスタマイズ

ece-toolsは、defaultおよびstale_cache_enabled フロントエンドのValkey接続の詳細(serverportdatabaseserializercompression_libpersistent_id)を自動的に導き出します。 ローカルキャッシュディレクトリなどの他のバックエンドオプションをカスタマイズするには、CACHE_CONFIGURATION_merge: trueVALKEY_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
CAUTION
symfony_l2CACHE_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の配備構成で構成を調整できます。
NOTE
設定可能なcleanup_percentage オプションは、Adobe Commerce 2.4.4で導入されました。

次の例は、.magento.env.yaml ファイルの設定コードを示しています。

Valkey設定

Commerce 2.4.9以降では、次の設定を使用して、クリーンアップしきい値を90%に設定します。

code language-yaml
stage:
  deploy:
    VALKEY_BACKEND: symfony_l2
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            cleanup_percentage: 90
Redis設定

Commerce 2.4.8以前の場合は、次の設定を使用して、クリーンアップしきい値を90%に設定します。

code language-yaml
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            cleanup_percentage: 90

キャッシュの要件は、プロジェクトの設定とカスタムのサードパーティコードによって異なります。 L2 キャッシュメモリのサイズを調整して、頻繁なスレッショルドヒットなしでキャッシュを動作できるようにします。

理想的には、L2 キャッシュメモリの使用は、頻繁なストレージのクリアを避けるために、しきい値を下回って安定します。

次のCLI コマンドを実行し、/dev/shm行を確認することで、クラスターの各ノードでのL2 キャッシュストレージメモリの使用状況を確認できます。

df -h /dev/shm

使用状況はノードによって異なりますが、類似の値に収束します。

設定例

RedisまたはValkey サービス設定の出発点として、次の例を使用します。

ベストプラクティスの推奨事項をすべて適用

Valkey設定の例

VALKEY_BACKEND: symfony_l2の場合、ece-toolsdefaultおよびstale_cache_enabledのフロントエンドとそのキャッシュタイプマッピングを生成します。 広範なdefault フロントエンドにuse_stale_cacheを設定しないでください。 以下のCACHE_CONFIGURATION ブロックには、明示的なバックエンドオプションの上書きのみが含まれています。

code language-yaml
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    VALKEY_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture.
    VALKEY_BACKEND: symfony_l2 # Use symfony_l2 for Adobe Commerce 2.4.9 and later
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '001_' # any prefix is fine, but keep it consistent.
          backend_options:
            connect_retries: 3                # Number of connection retries
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1        # Required for split architecture
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # 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%)

    SESSION_CONFIGURATION:
      _merge: true
      redis:
        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.
        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60
Redis設定の例

Adobe Commerce 2.4.8以前のRedisでは、次の設定を使用します。

code language-yaml
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    REDIS_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture
    REDIS_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '001_' # Any prefix is fine, but keep it consistent.
          backend_options:
            use_stale_cache: true             # Enables stale cache feature for all cache types
            connect_retries: 3                # Number of connection retries
            preload_keys:                     # Preload keys at backend_options level (official Adobe placement)
              - '001_EAV_ENTITY_TYPES:hash'   # Bootstrap: entity types
              - '001_GLOBAL_PLUGIN_LIST:hash' # Bootstrap: DI plugin list
              - '001_DB_IS_UP_TO_DATE:hash'   # Bootstrap: schema version
              - '001_SYSTEM_DEFAULT:hash'     # Config: system defaults
              - '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1        # Required for split architecture
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # 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%)

    SESSION_CONFIGURATION:
      _merge: true
      redis:

        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.

        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60

キャッシュタイプ別に古いキャッシュを分離する

Valkey
code language-yaml
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    VALKEY_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture
    VALKEY_BACKEND: symfony_l2 # Use symfony_l2 for Adobe Commerce 2.4.9 and later
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # Keep stale cache disabled on the broad default frontend.
          id_prefix: '001_' # Keep this prefix consistent with the frontend configuration generated in env.php
          backend_options:
            connect_retries: 3
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

        stale_cache_enabled: # New frontend with stale cache enabled only for selected cache types.
          id_prefix: '001_' # Use the same id_prefix used by the source frontend in env.php
          backend: symfony_l2
          backend_options:
            remote_backend: valkey
            remote_backend_options:
              server: localhost
              port: 6370   # Use the same port used by the source frontend in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same read-only replica connection/read port used by the source frontend in env.php
              retry_reads_on_master: 1
              read_timeout: 10
            local_backend: file
            local_backend_options:
              cache_dir: /dev/shm/
            use_stale_cache: true
            connect_retries: 3
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

      type:
        default:
          frontend: default # Keeps stale cache disabled on the broad default frontend, including generic cache writes that use \Magento\Framework\App\Cache, such as $this->cache->save().
        block_html:
          frontend: stale_cache_enabled # This is often one of the cache types that benefits the most from stale cache, because it is heavily used and can contribute significantly to lock contention during regeneration. In most cases, it can remain enabled. Exclude it only if the project has customization-specific issues caused by stale block output.
        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...

    SESSION_CONFIGURATION:
      _merge: true
      redis: # keep 'redis' even if you are using Valkey.
        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.
        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60
Redis
code language-yaml
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    REDIS_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture
    REDIS_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # Keep stale cache disabled on the broad default frontend.
          id_prefix: '001_' # Keep this prefix consistent with the frontend configuration generated in env.php
          backend_options:
            use_stale_cache: false # stale cache false here
            connect_retries: 3
            preload_keys:
              - '001_EAV_ENTITY_TYPES:hash'
              - '001_GLOBAL_PLUGIN_LIST:hash'
              - '001_DB_IS_UP_TO_DATE:hash'
              - '001_SYSTEM_DEFAULT:hash'
              - '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

        stale_cache_enabled: # New frontend with stale cache enabled only for selected cache types.
          id_prefix: '001_' # Use the same id_prefix used by the source frontend in env.php
          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 source frontend in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same read-only replica connection/read port used by the source frontend 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
            connect_retries: 3
            preload_keys:
              - '001_EAV_ENTITY_TYPES:hash'
              - '001_GLOBAL_PLUGIN_LIST:hash'
              - '001_DB_IS_UP_TO_DATE:hash'
              - '001_SYSTEM_DEFAULT:hash'
              - '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

      type:
        default:
          frontend: default # Keeps stale cache disabled on the broad default frontend, including generic cache writes that use \Magento\Framework\App\Cache, such as $this->cache->save().
        block_html:
          frontend: stale_cache_enabled # This is often one of the cache types that benefits the most from stale cache, because it is heavily used and can contribute significantly to lock contention during regeneration. In most cases, it can remain enabled. Exclude it only if the project has customization-specific issues caused by stale block output.
        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...

    SESSION_CONFIGURATION:
      _merge: true
      redis:
        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.
        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60
recommendation-more-help
commerce-operations-help-implementation-playbook