Architettura scalata

L’infrastruttura Cloud è scalabile in base ai requisiti delle risorse per ottenere una maggiore efficienza. L’infrastruttura cloud di Adobe Commerce esegue il monitoraggio delle applicazioni e può regolare la capacità per mantenere prestazioni costanti e prevedibili. La conversione in questa architettura consente di mitigare i problemi, ad esempio latenza o picchi di traffico elevati.

Architettura split-tier

Storicamente, l’architettura Pro era costituita da tre nodi, ciascuno contenente uno stack tecnologico completo. Ora esiste un’infrastruttura scalabile che fornisce un’architettura su più livelli con un minimo di sei nodi: tre nodi per il database e i servizi principali e tre nodi per il server web. Questa architettura split-tier offre la possibilità di scalare i livelli in modo indipendente per ottenere un equilibrio ottimale delle prestazioni.

Livello di servizio

Ognuno dei tre nodi di servizio esegue lo stesso set di servizi: OpenSearch o Elasticsearch per la ricerca, MariaDB per il database e Redis o Valkey per la memorizzazione nella cache, tra gli altri. Quando il livello di servizio si avvicina alla capacità, è possibile scalare solo verticalmente, aumentando le dimensioni del server (CPU e memoria). La capacità è limitata alla dimensione del nodo più grande disponibile. Poiché il cluster di database è progettato per l’elevata disponibilità, non è possibile scalare i nodi del database in modo affidabile con le tecnologie utilizzate.

Si consideri un esempio in cui il tipo di istanza del nodo di servizio è m5.2xlarge con 32 Gb di RAM. Un servizio, come il database, utilizza una notevole quantità di memoria (30 Gb). Il ridimensionamento alla successiva dimensione dell’istanza disponibile m5.4xlarge fornisce una RAM da 64 Gb, che raddoppia la memoria e soddisfa le crescenti esigenze del database.

È possibile ottimizzare ulteriormente le prestazioni del livello servizio instradando il traffico in base al tipo di nodo. Per impostazione predefinita, il nodo del database è isolato dal traffico web. Ad esempio, puoi scegliere di gestire il traffico web sul nodo del database.

Livello web

Sono disponibili tre nodi Web per l’elaborazione delle richieste e del traffico Web: php-fpm e NGINX. Oltre al ridimensionamento verticale aumentando la potenza e la memoria, il livello web può essere scalato orizzontalmente aggiungendo server web a un cluster esistente quando è limitato a livello PHP. Per informazioni sul ridimensionamento automatico dei nodi Web, vedere Ridimensionamento automatico.

Questa funzione integra la scalabilità verticale fornita dal livello di servizio. Con il livello di servizio scalabile per adattarsi a un database in crescita, il livello web viene scalato per gestire un aumento delle richieste e del traffico.

Si consideri un esempio in cui il tipo di istanza del nodo Web è C5.2xlarge con otto CPU e 16 Gb di RAM. Il numero di richieste al sito è aumentato notevolmente. Per gestire l’aumento dei processi php-fpm, è possibile aggiungere un nodo C5.2xlarge oppure modificare ogni tipo di istanza in C5.4xlarge con 16 CPU e 32 Gb di RAM. L’aggiunta di un nodo riduce il rischio di una capacità di sovratensione insufficiente.

Struttura del progetto

I progetti Pro con architettura Scalata dispongono di sei nodi.

Tuttavia, ogni progetto è univoco e richiede il monitoraggio delle prestazioni per analizzare correttamente la gestione delle risorse. Ogni account include il servizio New Relic, che si connette automaticamente ai dati dell’applicazione e alle analisi delle prestazioni per fornire il monitoraggio dinamico del server. In particolare, è possibile utilizzare il servizio New Relic per monitorare l’utilizzo di CPU e RAM per determinare quali nodi richiedono risorse aggiuntive. Quando una risorsa raggiunge la capacità o si osserva un peggioramento delle prestazioni in base all’analisi, è possibile creare una richiesta per scalare l’infrastruttura per soddisfare la domanda.

Accesso SSH

Alcuni file e registri, ad esempio la directory /app/<project-id>/var/log, non sono condivisi tra i nodi. Ogni nodo dispone di un accesso SSH univoco. Non è possibile utilizzare la CLI magento-cloud per accedere al servizio o ai nodi Web, ma è possibile trovare gli indirizzi dei nodi nell’elenco di accesso SSH in Cloud Console.

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

Esempio di risposta durante l’accesso a un nodo di servizio che include il ruolo unified:

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Esempio di risposta durante l’accesso a un nodo Web che include il ruolo web:

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Posizioni del registro

Le posizioni del registro variano leggermente a seconda del nodo. Ad esempio, il Registro errori MySQL (/var/log/mysql/mysql-error.log) è disponibile in un nodo di servizio, ma non in un nodo Web.

Ogni account Pro include il servizio Registri di New Relic, che si connette automaticamente ai dati di registro dell’applicazione per fornire una gestione dinamica dei registri. I dati di registro aggregati da tutti i nodi vengono visualizzati nell’applicazione Registri di New Relic in modo da poter risolvere i problemi di prestazioni su nodi specifici da un singolo dashboard.