[Commerce on Cloud]{class="badge informative" title="Cloud プロジェクト上のAdobe Commerceにのみ適用されます。"}
ValkeyとRedis サービス設定のベストプラクティス
これらの推奨事項を使用して、Adobe Commerce on cloud infrastructureのValkeyまたはRedisのキャッシュとセッションを設定します。 オンプレミス キャッシュの設定については、 キャッシュ バックエンド オプションとストレージ リファレンス を参照してください。
- Symfony個のL2 キャッシュを含むL2 キャッシュの設定
- 読み取り専用レプリカ接続を有効にする
- キーのプリロード
- 古いキャッシュを有効にする
- キャッシュとセッションの分離
- キャッシュを圧縮
- 設定例の確認
ece-tools パッケージを使用していることを確認してください。 そうでない場合は、最新バージョン にアップグレードしてください。 ローカル環境にインストールされているバージョンは、composer show magento/ece-tools CLI コマンドを使用して確認できます。L2 キャッシュの設定
.magento.env.yaml構成ファイルでVALKEY_BACKENDまたはREDIS_BACKENDのデプロイメント変数を設定して、L2 キャッシュを構成します。
Adobe Commerce 2.4.9および2.4.8-p4、2.4.7-p9、2.4.6-p14、および2.4.5-p16以降のバージョンの場合は、Valkeyを使用してL2 キャッシュを設定します。 このページのRedisの設定例は、Redisを使用するサポートされているAdobe Commerce バージョンにのみ適用されます。 リリース別のサポートされているキャッシュサービスについては、必要システム構成を参照してください。
実装の詳細、設定例、デプロイメント固有のガイダンスについては、 パフォーマンス最適化のためのL2 キャッシュ設定を参照してください。
Valkeyの場合は、次を使用します。
| code language-yaml |
|---|
|
環境の設定の詳細については、「Commerce on Cloud Infrastructure Guide」の「VALKEY_BACKEND コンフィギュレーション変数」を参照してください。
Redisの場合は、次を使用します。
| code language-yaml |
|---|
|
環境設定の詳細については、Commerce on Cloud Infrastructure ガイドのREDIS_BACKENDを参照してください。
Symfony L2 キャッシュの設定
Adobe Commerce 2.4.9以降では、symfony_l2 キャッシュバックエンドがサポートされています。 クラウドインフラストラクチャ上のAdobe Commerceで、このバックエンドを設定するのは、.magento.env.yamlのsymfony_l2をサポートするece-tools バージョンをプロジェクトで使用した後のみです。
symfony_l2 バックエンドは、Adobe CommerceがL1およびL2 キャッシュ動作の管理に使用するキャッシュ実装です。 RedisまたはValkeyをリモートキャッシュサービスとして置き換えることはありません。 Adobe Commerce 2.4.9の場合は、Valkeyをリモートバックエンドとしてsymfony_l2を設定します。
ece-toolsのサポートが利用可能になるまで、app/etc/env.phpでsymfony_l2をクラウドインフラストラクチャ上のAdobe Commerceの永続的な設定として手動で設定しないでください。 展開では、手動のenv.php変更を上書きできます。 ece-toolsがsymfony_l2を適用しない場合、Commerceはファイルベースのキャッシュにフォールバックできます。 このフォールバックにより、ディスク I/Oが増加し、マルチノード環境でのファイルシステムのレプリケーションのオーバーヘッドが増加し、パフォーマンスが低下する可能性があります。ece-toolsのサポートが利用可能な場合は、Valkey バックエンド変数をsymfony_l2に設定し、CACHE_CONFIGURATIONでL2 バックエンドオプションを定義します。
stage:
deploy:
VALKEY_BACKEND: symfony_l2
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
remote_backend: valkey
remote_backend_options:
server: localhost
database: 1
port: 6370
serializer: igbinary
compression_lib: gzip
persistent_id: magento_l2_default
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1
symfony_l2で選択したキャッシュタイプの古いキャッシュを有効にするには、use_stale_cache: trueで2番目のフロントエンドを定義し、選択したキャッシュタイプをそのフロントエンドにマッピングします。 各フロントエンドには、明確なローカルキャッシュディレクトリと永続的なIDを使用します。
stage:
deploy:
VALKEY_BACKEND: symfony_l2
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
remote_backend: valkey
remote_backend_options:
server: localhost
database: 0
port: 6370
serializer: igbinary
compression_lib: gzip
persistent_id: magento_l2_default
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1
stale_cache_enabled:
backend: symfony_l2
backend_options:
remote_backend: valkey
remote_backend_options:
server: localhost
database: 0
port: 6370
serializer: igbinary
compression_lib: gzip
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
translate:
frontend: stale_cache_enabled
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 ファイルの設定コードを示しています。
| code language-yaml |
|---|
|
| code language-yaml |
|---|
|
キャッシュの要件は、プロジェクトの設定とカスタムのサードパーティコードによって異なります。 L2 キャッシュメモリのサイズを調整して、頻繁なスレッショルドヒットなしでキャッシュを動作できるようにします。
理想的には、L2 キャッシュメモリの使用は、頻繁なストレージのクリアを避けるために、しきい値を下回って安定します。
次のCLI コマンドを実行し、/dev/shm行を確認することで、クラスターの各ノードでのL2 キャッシュストレージメモリの使用状況を確認できます。
df -h /dev/shm
使用状況はノードによって異なりますが、同様の値に収束する必要があります。
スレーブ接続を有効にする
.magento.env.yaml ファイルで読み取り専用レプリカ接続を有効にして、Adobe Commerceでプライマリエンドポイントを書き込みに引き続き使用しながら、読み取りに追加のキャッシュ接続を使用できるようにします。 この設定により、プライマリキャッシュサービスの読み取り負荷を軽減し、より効果的に読み取りトラフィックを分散させることができます。
Valkeyの場合は、次を使用します。
| code language-yaml |
|---|
|
環境変数の設定の詳細については、Commerce on Cloud Infrastructure ガイドのVALKEY_USE_SLAVE_CONNECTIONを参照してください。
Redisの場合は、次を使用します。
| code language-yaml |
|---|
|
環境変数の設定の詳細については、Commerce on Cloud Infrastructure ガイドのREDIS_USE_SLAVE_CONNECTIONを参照してください。
キーのプリロード
Magentoは通常、Redis キーまたはValkey キーからキャッシュエントリを一度に1つずつ読み込みます。 プリロード機能を使用すると、Magentoがリクエスト中に最初にアクセスしたときに1つのパイプラインで取得する、頻繁に使用されるキーのリストを提供できます。 Magentoは、そのリクエストの残りの部分について取得した値をPHP メモリに保持します。これにより、RedisまたはValkeyへの繰り返しラウンドトリップが削減され、それらのキーのリクエストブートストラップのパフォーマンスが向上します。
RedisまたはValkeyでアクティブなコマンドを監視することで、頻繁に使用されるキーを特定できます。
プリロードキーは、.magento.env.yaml設定ファイルで設定されます。
| code language-yaml |
|---|
|
キーを一覧表示するには、次のコマンドを実行します。
| code language-terminal |
|---|
|
10秒後、Ctrl+Cを押します。 次に、次のコマンドを実行します。
| code language-terminal |
|---|
|
このログには、プリロードできるキーが一覧表示されます。 キーの内容を確認するには、次のコマンドを実行します。
| code language-terminal |
|---|
|
プリロードキーは、.magento.env.yaml設定ファイルで設定されます。
| code language-yaml |
|---|
|
キーを一覧表示するには、次のコマンドを実行します。
| code language-terminal |
|---|
|
10秒後、Ctrl+Cを押します。 次に、次のコマンドを実行します。
| code language-terminal |
|---|
|
このログには、プリロードできるキーが一覧表示されます。 キーの内容を確認するには、次のコマンドを実行します。
| code language-terminal |
|---|
|
古いキャッシュを有効にする
古いキャッシュは、RemoteSynchronizedCacheのL2 キャッシュ機能です。 これを有効にすると、Adobe Commerceは既存のローカルキャッシュ値を/dev/shmから提供できますが、別のリクエストでは既に同じエントリが再生成されており、すべての同時リクエストを待つ必要はありません。 これにより、高価なキャッシュエントリの再生中にキャッシュスタンピングとロック競合が減少します。
仕組み
RemoteSynchronizedCacheでは、Magentoは各キャッシュエントリの2つのコピー(/dev/shmのローカルコピーとRedisまたはValkeyのリモートコピー)を保持します。 リモートコピーが利用できず、そのキーに対する再生ロックが既に存在する場合、同時要求は、新しい値が書き込まれるまで待つのではなく、以前のローカル値を受け取ることができます。
古いキャッシュを有効にするには、.magento.env.yaml ファイルで設定します。
Valkeyの場合:
| code language-yaml |
|---|
|
Redisの場合
| code language-yaml |
|---|
|
full_page キャッシュの種類は、Fastlyを使用しているため、Cloud インフラストラクチャプロジェクト上のAdobe Commerceとは関係ありません。default キャッシュフロントエンドで古いキャッシュが有効になり、そのフロントエンドを使用するすべてのキャッシュエントリに古いキャッシュ動作が適用されます。 Magento コアキャッシュの種類は、通常、この設定で期待どおりに動作します。 ただし、専用のキャッシュフロントエンドを使用せずに汎用\Magento\Framework\App\Cache API (例:$this->cache->save())を介してキャッシュに書き込むカスタムコードまたは拡張機能がプロジェクトに含まれている場合、それらのエントリは再生中に古い値を提供することもできます。default フロントエンドで古いキャッシュを無効のままにし、選択したキャッシュタイプに対してのみ有効にします。これは、一般的に オンプレミス で行われるのと同じです。キャッシュタイプごとに個別に古いキャッシュを有効にする
.magento.env.yamlで専用のキャッシュフロントエンドを定義し、選択したキャッシュタイプをそれにマッピングすることで、選択したキャッシュタイプに対してのみ古いキャッシュを有効にできます。
正しく動作させるには、カスタムフロントエンドをCACHE_CONFIGURATION.frontendの下の完全なフロントエンドとして定義する必要があります。 新しいフロントエンド名のuse_stale_cache: trueのみを定義するだけでは不十分です。
設定例
Valkeyの場合:
| code language-yaml |
|---|
|
Redisの場合
| code language-yaml |
|---|
|
stale_cache_enabledにコピーします。キャッシュインスタンスとセッションインスタンスの分離
キャッシュをセッションから分離すると、キャッシュを個別に管理できます。 キャッシュとセッショントラフィック間の競合を減らし、キャッシュ関連のプレッシャーがセッションに影響を与えるのを防ぎ、各RedisまたはValkey インスタンスを独自のワークロードに合わせてサイズと調整を行うことができます。
セッション用の専用インスタンスをプロビジョニングするには、次の手順に従います。
-
.magento/services.yaml設定ファイルを更新します。code language-yaml mysql: type: mysql:10.4 disk: 35000 valkey: type: valkey:8.0 valkey-session: # This is for the new Valkey instance type: valkey:8.0 search: type: elasticsearch:7.9 disk: 5000 rabbitmq: type: rabbitmq:3.8 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設定ファイルを更新します。code language-yaml mysql: type: mysql:10.4 disk: 35000 redis: type: redis:6.0 redis-session: # This is for the new Redis instance type: redis:6.0 search: type: elasticsearch:7.9 disk: 5000 rabbitmq: type: rabbitmq:3.8 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からの応答により多くの時間をかけることで、短いスパイク中の断続的な接続と読み取りタイムアウトエラーを減らすことができます。
設定例
RedisまたはValkey サービス設定の出発点として、次の例を使用します。
ベストプラクティスの推奨事項をすべて適用
| code language-yaml |
|---|
|
| code language-yaml |
|---|
|
すべてのベストプラクティスの推奨事項を適用し、古いキャッシュをキャッシュタイプごとに分離します
| code language-yaml |
|---|
|
| code language-yaml |
|---|
|