拡張アーキテクチャ

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

NOTE
拡張アーキテクチャは、Pro 48 クラスター以上を持つクラウドインフラストラクチャアカウント上のAdobe Commerceで使用できます。

分割階層のアーキテクチャ

従来、Pro アーキテクチャは 3 つのノードで構成され、それぞれが完全なテクニカルスタックを含んでいます。 現在、拡張性の高いインフラストラクチャは、少なくとも 6 つのノード(コア・データベースとサービス用の 3 つのノード、Web サーバ用の 3 つのノード)を持つ階層型アーキテクチャを提供します。 この分割階層アーキテクチャは、パフォーマンスの最適なバランスを実現するために、階層を個別に拡張する機能を提供します。

サービス層

データストレージ、キャッシュ、サービスの 3 つのサービスノードがあります。 OpenSearch または Elasticsearch, MariaDB, レディス ​など。 サービス層が容量に近づくと、CPU の電力とメモリを増やすなど、サーバーのサイズを増やすことが唯一の方法です。 処理能力は、使用可能なノードのサイズに制限されます。 データベースクラスタは高可用性を目的として設計されているので、使用するテクノロジーを使用して、信頼性の高い方法で水平方向に拡張することはできません。

サービス層の拡張

サービスノードのインスタンスタイプが次のような場合について考えます。 m5.2xlarge 32 Gb の RAM を搭載。 データベースなどのサービスは、大量のメモリ (30 Gb) を使用します。 次に使用可能なインスタンスサイズに合わせて拡大/縮小 m5.4xlarge は 64 Gb の RAM を提供し、メモリを 2 倍にし、データベースのニーズの増大に対応します。

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

Web 層

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

Web 層の拡張

これにより、サービス層によって提供される垂直比率を補完します。 サービス層は、データベースおよびサービスの使用量の増加に対応するためにサイズと電力を拡大し、Web 層のサイズ、電力、インスタンスを拡大して、プロセスリクエストやトラフィック要件の増加に対応します。

Web ノードのインスタンスタイプが次のような場合、 C5.2xlarge (8 個の CPU と 16 Gb の RAM を搭載). サイトへのリクエスト数が大幅に増加しました。 php-fpm プロセスの増加を処理する C5.2xlarge ノードを追加するか、各インスタンスタイプを C5.4xlarge (16 CPU と 32 Gb RAM 搭載). ノードを追加すると、サージ容量が不足するリスクが軽減されます。

プロジェクト構造

少なくとも、スケールアーキテクチャを持つ Pro プロジェクトには、6 つのノードを使用できます。

  • 3 個の Web ノード c5.2xlarge (8 個の CPU、16 Gb RAM)

  • m5.2xlarge サービスノード x 3 (8 CPU、32 Gb RAM)

ただし、各プロジェクトは一意であり、リソース管理を適切に分析するには、パフォーマンスの監視が必要です。 各アカウントには、 New Relicサービス:アプリケーションデータおよびパフォーマンス分析と自動的に接続し、動的なサーバー監視を提供します。 特に、New Relicサービスを使用して CPU と RAM の使用率を監視し、追加のリソースが必要なノードを特定できます。 リソースが容量に達した場合や、分析に基づくパフォーマンスの低下に気付いた場合は、要求を作成して、必要に応じてインフラストラクチャを拡張できます。

SSH アクセス

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

ssh <node>.<project-ID>-<environment>-<user-ID>@ssh.<region>.magento.com
  • node 1~3 — サービスノードにアクセスするアドレス

  • node 4 ~ n— Web ノードにアクセスするアドレス

TIP
ログイン後、サーバー ID と役割を確認できます。サービスノードでは、 統一された 役割と Web ノードは、 web 役割。

にログインした際の応答の例 サービスノード 次を含む 統一された 役割:

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

 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 Log サービス:アプリケーションのログデータと自動的に接続し、Dynamic Log Management を提供します。 すべてのノードの集計ログデータがNew Relic Logs アプリケーションに表示され、単一のダッシュボードから特定のノードのパフォーマンスの問題をトラブルシューティングできます。

recommendation-more-help
05f2f56e-ac5d-4931-8cdb-764e60e16f26