Adobe Commerce Cloud Architecture issues

6 min readApr 23, 2021

Magento Commerce Cloud it is not real cloud it is a single tenant 3 server cluster solution with limited resources without autoscaling.

Redis Server

# Replication
role:master
connected_slaves:2
slave0:ip=192.168.,port=26370,state=online,offset=2182602185,lag=1
slave1:ip=192.168.,port=26370,state=online,offset=2182602322,lag=1

Mysql

Galera cluster

ElastickSearch

Everything in one node with replication betving nodes

Basically Adobe Commerce Cloud it is Platform.sh hosting under another brand.

M5.xlarge — 130*3 = 390$ month AWS resources cost (reserved )

2.5 GHz Intel Xeon Platinum 8175

4 vCPU

16 GiB memory

EBS only

Upto 2120 Mbps EBS throughput

Up to 10 Gigabit networking performance

If you have an application that is resource intensive, it can easily cause the CPU cycles on the machine to peak, essentially bringing the machine to a halt.

if your eCommerce website makes a large amount of database queries, a considerable amount of network load can be removed by keeping it all on the same system, keeping the response times low.

There are many advantages of seperating Magento application server with database server. I will cover as many advantages as I can. So, let’s get started with the first and most important advantage.

Better Monitoring: Yes, when you seperate your database server with your application server, you get to know whether your need to optimise your server or you need to optimise your application. It’s because one server will be running application and you will get information about resources usage just for your application code and on the other side, you will get information just about your database. Let’s say you have one 16GB server with application as well as database and the load on your server is higher than it can handle. What you can do? separate your servers and check whether your application requires more resources or your database requires more resources.
Scalability: You can upgrade/downgrade servers according to their resource consumption. Let’s say you have one 16GB server and you have 70% CPU usage. Separate application server with database server 8GB each and check whether your application requires your more resources or your database. If your database requires less resources, You can downgrade it to save money ;) . Also, you can upgrade based on the resource usage. If your Database server requires more resources then you can upgrade your database server and keep same application server.
Better performance: In a single server, Apache/Nginx/IIS, MariaDB/MySQL/PostgreSQL/MongoDB, PHP/Python/Perl has to share single CPU but when they get their own resources, you will see improvement in overall performance of your application.

So, these are the benefits you get when you have different machines to manage your different types of tasks. I recommend you to separate

Running and Scaling Magento on AWS

GlleraClaster Performance: by design performance of the cluster cannot be higher than performance of the slowest node; however, even if you have only one node, its performance can be considerably lower comparing to running the same server in a standalone mode (without wsrep provider). It is particularly true for big enough transactions (even those which are well within current limitations on transaction size quoted above).

RDS —

Amazon RDS makes it possible for you to create MySQL read replicas in an AWS region other than the one containing our master MySQL Amazon RDS instance. This enables you to relocate read operations to the read replica located in the region nearest to your users and enhance your disaster recovery capacities, as well as migrate your database from one region to another.

Amazon RDS enables you to create your database in less than a minute using the AWS Management Console, Command Line Interface, or API calls. Amazon RDS makes database maintenance very easy due to the many possibilities it offers, including automatic AWS RDS MySQL backups and point-in-time recovery, whereas in our own data center we’d have to spend much more time on database maintenance and setup.

As Amazon takes care of infrastructure, backups, and updates on the Amazon RDS DB instance, the shell access to the underlying operating system is disabled. Keep in mind that access to MySQL user accounts with the “SUPER” privilege isn’t allowed, and the configuration of dynamic and non-dynamic MySQL variables are handled through Amazon RDS parameter groups.

Performance: Amazon EC2 vs RDS Performance

Which performs better: MySQL database migrations to Amazon RDS or MySQL database migrations to Amazon EC2 instances? A comparison of the performance of self-hosted MySQL databases on Amazon EC2 instances and Amazon RDS MySQL instances can be conducted using the Sysbench tool.

We chose a single Amazon EC2 m4.xlarge instance(the same as magento cloud using) and an Amazon RDS type db.m4.xlarge instance for the testing environment.

Two scenarios to test the performance:

25 threads an 1 million rows
50 threads and 2 million rows

As shown in the tables above, the performance of MySQL on Amazon RDS DB instance is significantly higher compared to the self-hosted MySQL on the same instance type. When it comes to performance in the Amazon RDS vs EC2-hosting matchup, AWS RDS comes out on top.

High Availability: Amazon RDS vs EC2 High Availability

Amazon RDS provides high availability and failover support for DB instances with Multi-AZ deployments.

In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different AZ. To prevent any negative impact of the backup process on performance, Amazon RDS creates a backup from the standby replica. In cases of planned or unplanned outages of your DB instance, Amazon RDS automatically performs a failover and that mechanism automatically changes the DNS record of the DB instance to point to the standby DB instance.

It’s important to note that the high-availability feature on Amazon RDS is not a scalable solution, and you cannot use a standby replica to serve read traffic.

Image 1. Master Amazon RDS instance and standby replica are in two different AZs

Amazon EC2 vs RDS: Backups and Restore

Amazon RDS makes it possible to perform automatic backups and manual snapshots of the DB instance.

Scallability

As a managed service, Amazon RDS takes care of the scaling of your relational database so your database can keep up with the increasing demands of your application or applications.

In this blog post, we are going to take a look into how we can vertically and horizontally scale your RDS instance. You can scale vertically to address the growing demands of an application that uses a roughly equal number of reads and writes. Or you can scale horizontally for read-heavy applications.

Vertical Scaling

To handle a higher load in your database, you can vertically scale up your master database with a simple push of a button. There are currently over 18 instance sizes that you can choose from when resizing your RDS MySQL, PostgreSQL, MariaDB

Horizontal Scaling

In addition to scaling your master database vertically, you can also improve the performance of a read-heavy database by using read replicas to horizontally scale your database. RDS MySQL, MariaDB can have up to 5 read replicas, and Amazon Aurora can have up to 15 read replicas.

Read replicas allow you to create read-only copies that are synchronized with your master database. You can also place your read replica in a different AWS Region closer to your users for better performance. Also, you can use read replicas to increase the availability of your database by promoting a read replica to a master for faster recovery in the event of a disaster. However, read replicas are not a replacement for the high availability and automatic failover capabilities that Multi-AZ provides.

Currently, RDS read replicas support transparent load balancing of queries or connections. Each replica has a unique Domain Name Service (DNS) endpoint so that an application can implement load balancing by connecting to the replica endpoint.