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

Esistono tre nodi di servizio per l'archiviazione dei dati, la cache e i servizi: OpenSearch o Elasticsearch, MariaDB, Redis e altro ancora. Quando il livello di servizio si avvicina alla capacità, l'unico modo per scalare è aumentare le dimensioni del server, ad esempio aumentando la potenza della CPU e la memoria. La capacità è limitata alla dimensione del nodo disponibile. Poiché il cluster di database è progettato per un'elevata disponibilità, non è possibile scalare orizzontalmente in modo affidabile con le tecnologie utilizzate.

Si consideri un esempio che 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 sulla scalabilità automatica dei nodi Web, vedere Ridimensionamento automatico.

Questa funzione integra la scalabilità verticale fornita dal livello di servizio. Con la scalabilità del livello di servizio in termini di dimensioni e potenza per soddisfare un crescente utilizzo di database e servizi, il livello web viene scalato in termini di dimensioni, potenza e istanze per soddisfare un aumento delle richieste di processi e requisiti di traffico più elevati.

Si consideri un esempio di tipo di istanza del nodo Web C5.2xlarge con otto CPU e 16 Gb di RAM. Il numero di richieste al sito è aumentato notevolmente. È possibile aggiungere un nodo C5.2xlarge per gestire l'aumento dei processi php-fpm oppure cambiare 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

In minima parte, i progetti Pro con architettura Scaled 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 della CPU e della 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. Un registro di database, ad esempio Registro errori MySQL, è disponibile in un nodo di servizio (/var/log/mysql/mysql-error.log), 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.