Architecture à grande échelle

L’infrastructure cloud s’adapte en fonction des besoins de vos ressources pour atteindre une plus grande efficacité. Adobe Commerce sur les infrastructures cloud surveille vos applications et peut ajuster la capacité pour maintenir des performances stables et prévisibles. La conversion vers cette architecture permet de réduire les problèmes, tels que la latence ou les pics de trafic importants.

NOTE
L’architecture évolutive est disponible pour Adobe Commerce sur les comptes d’infrastructure cloud avec le cluster Pro 48 ou une version ultérieure.

Architecture à deux niveaux

Historiquement, l’architecture Pro se composait de trois nœuds, chacun contenant un tech stack complet. Il existe désormais une infrastructure évolutive qui fournit une architecture à plusieurs niveaux avec un minimum de six nœuds : trois nœuds pour la base de données et les services principaux et trois nœuds pour le serveur web. Cette architecture à plusieurs niveaux permet de dimensionner les niveaux indépendamment pour obtenir un équilibre optimal des performances.

Niveau de service

Chacun des trois nœuds de service exécute le même ensemble de services : OpenSearch ou Elasticsearch pour la recherche, MariaDB pour la base de données et Redis ou Valkey pour la mise en cache, entre autres. Lorsque le niveau de service approche de la capacité, vous ne pouvez effectuer une mise à l’échelle que verticalement, en augmentant la taille du serveur (CPU et mémoire). La capacité est limitée à la plus grande taille de nœud disponible. Le cluster de base de données étant conçu pour offrir une haute disponibilité, vous ne pouvez pas mettre à l’échelle les nœuds de base de données de manière fiable avec les technologies utilisées.

Mise à l’échelle du niveau de service

Prenons un exemple où le type d’instance de nœud de service est m5.2xlarge avec 32 Go de RAM. Un service, tel que la base de données, utilise une quantité de mémoire considérable (30 Go). La mise à l’échelle vers la taille d’instance disponible suivante m5.4xlarge fournit 64 Go de RAM, ce qui double la mémoire et répond aux besoins croissants de la base de données.

Vous pouvez optimiser davantage les performances du niveau de service en acheminant le trafic en fonction du type de nœud. Par défaut, le nœud de base de données est isolé du trafic Web. Par exemple, vous pouvez choisir de diffuser le trafic web sur le nœud de base de données.

Niveau web

Il existe trois nœuds web pour le traitement des requêtes et du trafic web : php-fpm et NGINX. En plus de la mise à l’échelle verticale en augmentant la puissance et la mémoire, le niveau web peut être mis à l’échelle horizontale en ajoutant des serveurs web à un cluster existant lorsqu’il est limité au niveau PHP. Pour découvrir comment les nœuds web se mettent à l’échelle automatiquement, consultez ​ Mise à l’échelle automatique ​.

Mise à l’échelle de niveau web

Cela complète la mise à l’échelle verticale fournie par le niveau de service. À mesure que le niveau de service s’adapte à l’augmentation de la taille de la base de données, le niveau web s’adapte à l’augmentation des demandes et du trafic.

Prenons un exemple où le type d’instance de nœud web est C5.2xlarge avec huit processeurs et 16 Go de RAM. Le nombre de requêtes sur le site a considérablement augmenté. Pour gérer l’augmentation des processus php-fpm, vous pouvez ajouter un nœud C5.2xlarge ou changer chaque type d’instance en C5.4xlarge avec 16 CPU et 32 Go de RAM. L’ajout d’un nœud réduit le risque d’une capacité de pointe insuffisante.

Structure du projet

Les projets Pro avec l’architecture à l’échelle ont six nœuds disponibles.

  • 3 nœuds web c5.2xlarge (8 CPU, 16 Go de RAM)

  • 3 nœuds de service m5.2xlarge (8 CPU, 32 Go de RAM)

Cependant, chaque projet est unique et nécessite une surveillance des performances pour analyser correctement la gestion des ressources. Chaque compte comprend le service 🔗, qui se connecte automatiquement aux données de l’application et à l’analyse des performances pour fournir une surveillance dynamique du serveur. Plus précisément, vous pouvez utiliser le service New Relic pour surveiller l’utilisation de CPU et de la RAM afin de déterminer les nœuds qui nécessitent des ressources supplémentaires. Lorsqu’une ressource atteint sa capacité maximale ou que vous constatez une dégradation des performances en fonction des analyses, vous pouvez créer une demande afin d’adapter votre infrastructure en fonction de la demande.

Accès SSH

Certains fichiers et journaux, tels que le répertoire /app/<project-id>/var/log, ne sont pas partagés entre les nœuds. Chaque nœud dispose d’un accès SSH unique. Vous ne pouvez pas utiliser l’interface de ligne de commande magento-cloud pour vous connecter aux nœuds de service ou web, mais vous pouvez trouver les adresses des nœuds dans la liste Accès SSH de votre Cloud Console.

ssh <node>.<project-ID>-<environment>-<user-ID>@ssh.<region>.magento.com
  • node 1 à 3 : adresses pour accéder aux nœuds de service

  • node 4 à n : adresses pour accéder aux nœuds web

TIP
Après vous être connecté, vous pouvez confirmer l’ID de serveur et le rôle : les nœuds de service utilisent le rôle unifié et les nœuds web utilisent le rôle web.

L’exemple de réponse lors de la connexion à un nœud de service inclut le rôle unifié :

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

L’exemple de réponse lors de la connexion à un nœud web inclut le rôle web :

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

 Welcome to Magento Cloud.

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

project-id@server-id:~$

Emplacements du journal

Les emplacements des journaux varient légèrement en fonction du nœud. Par exemple, le journal des erreurs MySQL (/var/log/mysql/mysql-error.log) est disponible sur un nœud de service, mais pas sur un nœud web.

Chaque compte Pro inclut le service Journaux ​, qui se connecte automatiquement aux données de journal de l’application pour fournir une gestion dynamique des journaux. Les données de journal agrégées de tous les nœuds s’affichent dans l’application Journaux New Relic afin que vous puissiez résoudre les problèmes de performances sur des nœuds spécifiques à partir d’un seul tableau de bord.

recommendation-more-help
commerce-on-cloud-help-cloud-guide