Skalierte Architektur

Die Cloud-Infrastruktur kann entsprechend Ihren Ressourcenanforderungen skaliert werden, um eine höhere Effizienz zu erzielen. Die Adobe Commerce on Cloud-Infrastruktur überwacht Ihre Programme und kann die Kapazität anpassen, um eine kontinuierliche, vorhersehbare Leistung aufrechtzuerhalten. Die Konvertierung in diese Architektur trägt dazu bei, Probleme wie Latenz oder große Traffic-Spitzen zu minimieren.

Architektur mit mehreren Ebenen

Früher bestand die Pro-Architektur aus drei Knoten, von denen jeder einen vollständigen Technologie-Stack enthielt. Jetzt gibt es eine skalierbare Infrastruktur, die eine mehrstufige Architektur mit mindestens sechs Knoten bietet: drei Knoten für die zentrale Datenbank und Services und drei Knoten für den Webserver. Diese Split-Tier-Architektur bietet die Möglichkeit, Ebenen unabhängig zu skalieren, um ein optimales Leistungsgleichgewicht zu erzielen.

Service-Ebene

Jeder der drei Dienstknoten führt denselben Satz von Diensten aus: OpenSearch oder Elasticsearch für die Suche, MariaDB für die Datenbank und Redis oder Valkey für das Caching, unter anderem. Wenn sich die Servicestufe der Kapazität nähert, können Sie nur vertikal skalieren, indem Sie die Servergröße (CPU und Speicher) erhöhen. Die Kapazität ist auf die größte verfügbare Knotengröße beschränkt. Da der Datenbank-Cluster für hohe Verfügbarkeit ausgelegt ist, können Sie die Datenbankknoten nicht zuverlässig mit den verwendeten Technologien skalieren.

Betrachten wir ein Beispiel, bei dem der Service-Knoten-Instanztyp m5.2xlarge mit 32 GB RAM ist. Ein Dienst wie die Datenbank beansprucht eine beträchtliche Menge an Arbeitsspeicher (30 GB). Durch die Skalierung auf die nächste verfügbare Instanzgröße m5.4xlarge steht 64 GB RAM zur Verfügung, wodurch der Arbeitsspeicher verdoppelt und die wachsenden Anforderungen der Datenbank erfüllt werden können.

Sie können die Leistung der Service-Ebene weiter optimieren, indem Sie Traffic basierend auf dem Knotentyp weiterleiten. Standardmäßig ist der Datenbankknoten vom Web-Traffic getrennt. Sie können beispielsweise Webtraffic auf dem Datenbankknoten bereitstellen.

Web-Stufe

Es gibt drei Web-Knoten für die Verarbeitung von Anfragen und Webtraffic: php-fpm und NGINX. Zusätzlich zur vertikalen Skalierung durch Erhöhung der Leistung und des Speichers kann die Web-Ebene horizontal skaliert werden, indem Webserver zu einem vorhandenen Cluster hinzugefügt werden, wenn sie auf PHP-Ebene eingeschränkt werden. Informationen zur automatischen Skalierung der Web-Knoten finden Sie unter Automatische Skalierung.

Dies ergänzt die vertikale Skalierung, die von der Service-Ebene bereitgestellt wird. Wenn die Service-Ebene skaliert wird, um eine wachsende Datenbank zu berücksichtigen, wird die Web-Ebene skaliert, um einen Anstieg der Anfragen und des Traffics zu bewältigen.

Betrachten wir ein Beispiel, bei dem der Web-Knoten-Instanztyp C5.2xlarge mit acht CPUs und 16 GB RAM ist. Die Anzahl der Anfragen an die Website ist stark gestiegen. Um den Anstieg der php-fpm-Prozesse zu bewältigen, können Sie einen C5.2xlarge-Knoten hinzufügen oder jeden Instanztyp auf C5.4xlarge mit 16 CPU und 32 GB RAM ändern. Durch Hinzufügen eines Knotens wird das Risiko unzureichender Spitzenkapazitäten reduziert.

Projektstruktur

Pro-Projekte mit der skalierten Architektur verfügen über sechs Knoten.

Jedes Projekt ist jedoch einzigartig und erfordert eine Leistungsüberwachung, um das Ressourcenmanagement ordnungsgemäß zu analysieren. Jedes Konto enthält den New Relic-Service der sich automatisch mit den Anwendungsdaten und Leistungsanalysen verbindet, um eine dynamische Serverüberwachung zu ermöglichen. Insbesondere können Sie den New Relic-Service verwenden, um die CPU- und RAM-Auslastung zu überwachen und festzustellen, welche Knoten zusätzliche Ressourcen benötigen. Wenn eine Ressource ihre Kapazität erreicht oder Sie eine Leistungsminderung feststellen, die auf der Analyse basiert, können Sie eine Anfrage zur Skalierung Ihrer Infrastruktur erstellen, um den Bedarf zu decken.

SSH-Zugriff

Bestimmte Dateien und Protokolle, z. B. das /app/<project-id>/var/log, werden nicht zwischen Knoten freigegeben. Jeder Knoten verfügt über einen eindeutigen SSH-Zugriff. Sie können die magento-cloud CLI nicht verwenden, um sich beim Service oder bei den Web-Knoten anzumelden. Die Knotenadressen finden Sie jedoch in der SSH-Zugriffsliste in Ihrem Cloud Console.

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

Die Beispielantwort bei der Anmeldung bei einem Service-Knoten enthält die einheitliche Rolle:

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Die Beispielantwort bei der Anmeldung bei einem Web-Knoten enthält die Rolle Web:

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Speicherorte protokollieren

Die Protokollspeicherorte variieren je nach Knoten geringfügig. Das MySQL-Fehlerprotokoll (/var/log/mysql/mysql-error.log) ist beispielsweise auf einem Service-Knoten verfügbar, nicht jedoch auf einem Web-Knoten.

Jedes Pro-Konto enthält den New Relic Logs-Service, der sich automatisch mit Protokolldaten aus der Anwendung verbindet, um eine dynamische Protokollverwaltung zu ermöglichen. In der Anwendung "New Relic-Protokolle“ werden aggregierte Protokolldaten aus allen Knoten angezeigt, sodass Sie Leistungsprobleme auf bestimmten Knoten über ein einziges Dashboard beheben können.