詳細設定

Commerceは、あらゆる規模のマーチャント向けのソリューションを含む、柔軟性と拡張性の高い製品です。 このセクションでは、大量のデータ、極端な負荷、その他のエンタープライズ ケースで動作するようにCommerceを設定する際のベストプラクティスと推奨事項について説明します。

索引のパフォーマンスを調整

大量のデータを扱う場合、インデックスの再作成が懸念される可能性があります。 Commerce チームは、最も読み込まれたインデックスを選択し、バッチインデックスを有効にしました。これにより、各反復で処理するデータの一部を設定できます。 これにより、データベース内のデータの種類とサイズに基づいて、バッチサイズを調整することができます。

この設定を管理するには、対応するモジュールのdi.xml ファイルでbatchRowsCount パラメーターを編集します。 次のインデックスがこの機能をサポートしています。

インデックスバッチサイズ変数を調整することで、インデックスパフォーマンスを調整できます。 これは、インデクサーが一度に処理するエンティティの数を制御します。 場合によっては、インデックス作成時間が大幅に短縮されることがあります。

例えば、B2B Mediumと同様のプロファイルを実行している場合、app/code/Magento/catalog/etc/di.xmlの設定値batchRowsCountを上書きし、デフォルト値5000から1000を上書きできます。 これにより、デフォルトのMySQL設定で、完全なインデックス作成時間が4時間から2時間に短縮されます。

web サイトごとに顧客グループと共有カタログを制限する

多数の製品SKU、web サイト、顧客グループ、または共有カタログは、製品価格およびカタログルールのインデックスの実行時間に影響します。 これは、デフォルトでは、すべてのweb サイトがすべての顧客グループ（共有カタログ）に割り当てられるためです。

インデックス作成時間を短縮するには、顧客グループ（共有カタログ）から特定のweb サイトを除外することができます。

Redisの設定

1つのRedis インスタンスでは、受信リクエストを処理するのに十分ではない場合があります。 この状況に対処するために推奨できるソリューションがいくつかあります。

まず、Commerceでは、キャッシュタイプごとに個別のキャッシュストレージを設定できます。 これにより、Magentoに登録されているキャッシュの種類の数と同じ数の個別のRedis インスタンスをインストールできます。 実際には、構成、レイアウト、ブロックなど、最もアクティブに使用されるキャッシュにRedis インスタンスを使用する場合があります。

もう1つの解決策は、構成キャッシュをファイルシステムに配置し、他のキャッシュをRedis サーバーに移動することです。 このソリューションでは、すべてのweb ノードで設定キャッシュを一元的に無効化するための別のツールが必要です。

また、ノード数が自動的に増加する並列の読み取り/書き込み操作を実行するRedis クラスターを使用することもできます。 Commerceはこのケースの設定を提供していませんが、マイナーなカスタマイズで起動できます。

RabbitMQを設定

Adobe Commerceは、RabbitMQを通じて実装されたメッセージキューをサポートしています。 Commerceはこのサービスを、B2B カタログ操作や非同期在庫更新など、多数の非同期操作を実行するために使用します。 ジョブサーバーにジョブを追加するためのすべてのインターフェイスは、製品と共に配布され、サードパーティの拡張機能の範囲でカスタム非同期ロジック実装に使用できます。 他の統合と同様に、CommerceはRabbitMQのサンプル設定ファイルを提供します。このファイルには、すべての推奨設定が含まれており、実稼動環境で使用する準備が整っています。

データベースの分割

Adobe Commerceでは、拡張可能なデータベースストレージを設定し、成長中のビジネスのニーズに対応できます。 特定のドメインに対応する3つの個別のマスターデータベースを設定できます。

追加のデータベースを設定するには、空のデータベースを作成し、次のいずれかのコマンドを実行する必要があります。

チェックアウトマスター DB用

bin/magento setup:db-schema:split-quote

OMS マスター DBの場合

bin/magento setup:db-schema:split-sales

これらのコマンドは、特定のドメインテーブルをメインデータベースからドメインデータベースに移行します。 また、Commerce設定を変更して、対応する接続性と制約処理を許可します。

チェックアウトとOrder Management用の個別のデータベースを持つことで、データベースサーバー間で負荷を分散できます。 カタログやその他の業務の可用性に影響を与えることなく、より多くのチェックアウトを提供し、1秒間でより多くの注文を処理することができます。 データベースを分割して瞬時に売上を伸ばしたり、自然に負荷の大きいプロジェクトに永続的に使用することをお勧めします。 データベース間の現在のデータの移行は、システム管理者の監督の下で実行する必要があります。 実稼動モードでデータベースを分割しないでください。

Commerceでは、マスターデータベースに加えて、複数のスレーブデータベース （システムで宣言された各データリソースに1つ）を設定できます。 スレーブデータベースは、メインデータベースの完全なレプリカ、またはドメインマスターデータベースの1つとして機能します。 特定のリソースでの読み取り操作に対して発行されます。

次のコマンドを実行して、スレーブデータベースを追加できます。

bin/magento setup:db-schema:add-slave

このコマンドは、設定変更を実行しますが、レプリケーション自体は設定しません。 これは手作業でやるべきことです。

マスターデータベースを分割し、スレーブデータベースを設定すると、Commerceはリクエストの種類（POST、PUT、GETなど）とデータリソースに基づいて意思決定を行い、特定のデータベースへの接続を自動的に規制します。 Commerceまたはその拡張機能がGET リクエストに対して書き込み操作を実行すると、接続がスレーブからマスターデータベースに自動的に切り替わります。 マスターデータベースでも同じように機能します。チェックアウト関連のテーブルを操作すると、システムはすべてのクエリを特定のデータベースにリダイレクトします。 一方、カタログ関連のクエリはすべてメインデータベースに送信されます。

複数のマスター/スレーブ設定の設定と利点について詳しくは、を参照してください
分割データベース パフォーマンス ソリューション ​。

メディアコンテンツの提供

Magentoでは、メディアコンテンツの提供と配信に特化した統合機能は提供されていません。 Magentoでは、すべての一般的なアプローチを同時に使用できます。

メディアコンテンツを配信する最も簡単な方法は、Varnish サーバーに配信してキャッシュすることです。 このアプローチでは、メディアコンテンツを保存するための共有ファイルシステム、またはVarnishを指す専用サーバーのいずれかを前提としています。

中負荷および高負荷の環境では、FastlyやAkamaiなどのコンテンツ配信ネットワーク（CDN）サービスの利用をお勧めします。 これらのサービスを使用する場合、Commerceはコンテンツの更新に従来のプル アプローチを使用します。 対応するCDN サービスと連携するには、Commerce URLを設定する必要があります。 メディアコンテンツをCDNに移行することで、インスタンスの負荷を大幅に軽減できます。

ログストレージの設定

ログの保存と他のディスク操作への影響は、特に高負荷の状況において、web ノードの可用性に影響します。 必要がない場合は、ログを最小限に抑えることをお勧めします。 また、ログを設定して、アクセス速度の高い別のストレージシステムに書き込むこともできます。 ログストレージにアクセスする際のボトルネックは、フローの一部としてログの書き込みまたは読み取り操作を行う受信リクエストの処理に直接影響する可能性があります。