拡張されたアーキテクチャ

クラウド基盤は、リソース要件に応じて拡大できるため、効率性が向上します。 Adobe Commerce on cloud インフラストラクチャは、アプリケーションを監視し、安定して予測可能なパフォーマンスを維持するために容量を調整することができます。 このアーキテクチャに変換すると、遅延やトラフィックの大幅な増加などの問題を軽減するのに役立ちます。

分割階層アーキテクチャ

従来、Pro アーキテクチャは3つのノードで構成され、それぞれに完全なテクノロジースタックが含まれていました。 現在では、最低6つのノードを持つ階層化されたアーキテクチャを提供するスケーラブルなインフラストラクチャが存在します。つまり、コアデータベースとサービス用の3つのノードとweb サーバー用の3つのノードです。 このスプリットティアアーキテクチャでは、最適なパフォーマンスバランスを実現するために、階層を個別に拡張できます。

サービス層

3つのサービスノードはそれぞれ同じサービスのセットを実行します。例えば、検索には​ OpenSearch ​または​Elasticsearch、データベースには​MariaDB、キャッシュには​ Redis ​または​ Valkey ​が実行されます。 サービス層が容量に近づくと、サーバーサイズ（CPUとメモリ）を増やすことによって、垂直方向にのみ拡張できます。 容量は、使用可能な最大のノードサイズに制限されます。 データベース・クラスタは高可用性のために設計されているため、使用するテクノロジーに応じてデータベース・ノードを確実に拡張することはできません。

サービスノードインスタンスのタイプが32 Gb RAMを搭載した​ m5.2xlarge ​の例を考えてみましょう。 データベースのようなサービスは、かなりの量のメモリ（30 Gb）を使用します。 次の使用可能なインスタンスサイズ m5.4xlarge​に拡張すると、64 Gb RAMが提供され、メモリが2倍になり、データベースのニーズの増加に対応できます。

ノードタイプに基づいてトラフィックをルーティングすることで、サービス層のパフォーマンスをさらに最適化できます。 デフォルトでは、データベースノードはweb トラフィックから分離されます。 例えば、データベースノードでweb トラフィックを提供するように選択できます。

web層

リクエストとweb トラフィックを処理するためのweb ノードは3つあります。php-fpm​と​NGINX。 電力とメモリを増やすことによる垂直方向のスケーリングに加えて、web層は、PHP レベルで制約されたときに既存のクラスターにweb サーバーを追加することで水平方向にスケーリングできます。 Web ノードが自動的に拡張される方法については、自動スケーリング ​を参照してください。

これにより、サービス層が提供する垂直方向の拡張が補完されます。 増大するデータベースに対応するためにサービス層が拡張されると、web層が拡張され、リクエストとトラフィックの増加に対応します。

Web ノードインスタンスの種類が​ C5.2xlargeで、CPUが8台、RAMが16 Gb ​である例を考えてみましょう。 サイトへのリクエスト数が大幅に増加しました。 php-fpm プロセスの増加を処理するには、C5.2xlarge ノードを追加するか、16 CPUと32 Gb RAM で各インスタンスタイプを C5.4xlargeに変更できます。 ノードを追加すると、サージキャパシティが不十分になるリスクが軽減されます。

プロジェクト構造

スケール化されたアーキテクチャを持つプロプロジェクトには、6つのノードが使用可能です。

ただし、プロジェクトごとに独自性があるため、リソース管理を適切に分析するには、パフォーマンスの監視が必要です。 各アカウントにはNew Relic サービス ​が含まれており、アプリケーションデータとパフォーマンス分析に自動的に接続して、動的なサーバーモニタリングを提供します。 具体的には、New Relic サービスを使用して、CPUとRAMの使用率を監視し、追加リソースが必要なノードを判断できます。 リソースがキャパシティに達するか、分析に基づいてパフォーマンスが低下した場合、需要に応じてインフラストラクチャを拡張するためのリクエストを作成できます。

SSH アクセス

/app/<project-id>/var/log ディレクトリなどの特定のファイルとログは、ノード間で共有されません。 各ノードには一意のSSH アクセスがあります。 magento-cloud CLIを使用してサービスまたはweb ノードにログインすることはできませんが、Cloud ConsoleのSSH アクセス リストにノードアドレスがあります。

ssh <node>.<project-ID>-<environment>-<user-ID>@ssh.<region>.magento.com

サービスノード​にログインする際の応答の例には、統合​の役割が含まれています。

 __  __                   _          ___ _             _
|  \/  |__ _ __ _ ___ _ _| |_ ___   / __| |___ _  _ __| |
| |\/| / _` / _` / -_) ' \  _/ _ \ | (__| / _ \ || / _` |
|_|  |_\__,_\__, \___|_||_\__\___/  \___|_\___/\_,_\__,_|
            |___/

 Welcome to Magento Cloud.

 This is server unique-server-id, role project-id:unified.

project-id@server-id:~$

web ノード​にログインする際の応答の例には、web​の役割が含まれています。

 __  __                   _          ___ _             _
|  \/  |__ _ __ _ ___ _ _| |_ ___   / __| |___ _  _ __| |
| |\/| / _` / _` / -_) ' \  _/ _ \ | (__| / _ \ || / _` |
|_|  |_\__,_\__, \___|_||_\__\___/  \___|_\___/\_,_\__,_|
            |___/

 Welcome to Magento Cloud.

 This is server unique-server-id, role project-id:web.

project-id@server-id:~$

ログの場所

ログの場所は、ノードによって少し異なります。 例えば、MySQL エラーログ （/var/log/mysql/mysql-error.log）は、サービスノードでは利用できますが、web ノードでは利用できません。

各Pro アカウントには、New Relic Logs サービス ​が含まれており、このサービスはアプリケーションのログデータと自動的に接続して、動的なログ管理を提供します。 すべてのノードから集約されたログデータは、New Relic Logs アプリケーションに表示されるため、1つのダッシュボードから特定のノードのパフォーマンスの問題をトラブルシューティングできます。