Scaled Architecture

The Cloud infrastructure scales according to your resource requirements to achieve greater efficiency. The Adobe Commerce on cloud infrastructure monitors your applications and can adjust capacity to maintain steady, predictable performance. Converting to this architecture helps to mitigate problems, such as latency or large spikes in traffic.

Split-tier architecture

Historically, the Pro architecture consisted of three nodes, each containing a full tech stack. Now, there is a scalable infrastructure that provides a tiered architecture with a minimum of six nodes: three nodes for the core database and services and three nodes for the web server. This split-tier architecture provides the capability to scale tiers independently to achieve an optimal balance of performance.

Service tier

Each of the three service nodes runs the same set of services: OpenSearch or Elasticsearch for search, MariaDB for the database, and Redis or Valkey for caching, among others. When the service tier approaches capacity, you can scale only vertically, by increasing the server size (CPU and memory). Capacity is limited to the largest available node size. Because the database cluster is designed for high availability, you cannot scale the database nodes in a reliable way with the technologies used.

Consider an example where the service node instance type is m5.2xlarge with 32-Gb RAM. A service, such as the database, uses a considerable amount of memory (30 Gb). Scaling to the next available instance size m5.4xlarge provides 64-Gb RAM, which doubles the memory and accommodates the growing needs of the database.

You can further optimize the performance of the service tier by routing traffic based on the node type. By default, the database node is isolated from the web traffic. For example, you can choose to serve web traffic on the database node.

Web tier

There are three web nodes for processing requests and web traffic: php-fpm and NGINX. In addition to vertical scaling by increasing power and memory, the web tier can scale horizontally by adding web servers to an existing cluster when constricted at the PHP level. To learn how the web nodes scale automatically, see Auto scaling.

This complements the vertical scaling provided by the service tier. As the service tier scales to accommodate a growing database, the web tier scales to handle an increase in requests and traffic.

Consider an example where the web node instance type is C5.2xlarge with eight CPUs and 16-Gb RAM. The number of requests to the site increased greatly. To handle the increase in php-fpm processes, you can add a C5.2xlarge node or you can change each instance type to C5.4xlarge with 16 CPU and 32-Gb RAM. Adding a node reduces the risk of insufficient surge capacity.

Project structure

Pro projects with the Scaled architecture have six nodes available.

Each project is unique, however, and requires performance monitoring to analyze resource management properly. Each account includes the New Relic service, which automatically connects with the application data and performance analytics to provide dynamic server monitoring. Specifically, you can use the New Relic service to monitor CPU and RAM utilization to determine which nodes require additional resources. As a resource reaches capacity or you notice a degradation in performance based on the analytics, you can create a request to scale your infrastructure to meet the demand.

SSH access

Certain files and logs, such as the /app/<project-id>/var/log directory, are not shared between nodes. Each node has a unique SSH access. You cannot use the magento-cloud CLI to log in to the service or web nodes, but you can find the node addresses in the SSH Access list in your Cloud Console.

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

Example response as you log in to a service node includes the unified role:

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Example response as you log in to a web node includes the web role:

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Log locations

The log locations vary slightly depending on the node. For example, the MySQL error log (/var/log/mysql/mysql-error.log) is available on a service node, but not on a web node.

Each Pro account includes the New Relic Logs service, which automatically connects with log data from the application to provide dynamic log management. Aggregated log data from all nodes displays in the New Relic Logs application so that you can troubleshoot performance issues on specific nodes from a single dashboard.