Architecture d’hébergement Magento : Comment assurer performance et haute disponibilité !

Nous vous retrouvons aujourd’hui pour poursuivre notre série d’articles sur les différents types d’architecture possibles pour héberger votre plateforme e-commerce sous Magento ! Dans un notre précédent billet, nous avons présenté une infrastructure minimaliste et économique pour Magento 2. Voici comment la faire évoluer vers plus de performance et haute disponibilité.

Vers une plateforme redondée

Haute disponibilité et performance : ces deux concepts sont intimement liés, et l’amélioration de l’un passe souvent par l’optimisation de l’autre.

Pour améliorer la haute disponibilité, on utilise généralement une deuxième machine en “secours”. Il serait dommage de ne pas exploiter les ressources de cette deuxième machine pour améliorer les performances de votre plateforme.

Attention à bien faire la distinction entre deux aspects de la performance : temps de réponse et tenue en charge. L’ajout d’une nouvelle machine (nouveau front par exemple) n’a généralement pas d’impact immédiat sur le temps de réponse de votre site : il améliore sa tenue en charge, c’est à dire qu’il pourra servir votre site à plus d’utilisateurs en même temps (le temps de réponse se dégradera moins vite).

Pour améliorer le temps de réponse de votre site e-commerce, une optimisation applicative sera généralement beaucoup plus efficace qu’une optimisation matérielle (mais parfois plus coûteuse…).

Magento 2 se prête bien au Load Balancing : la charge applicative est générée par l’exécution du code PHP (ressource processeur), l’accès aux composants de données générant peu de charge. On peut donc améliorer la tenue en charge en ajoutant de nouveaux frontaux (scalabilité “horizontale”).

Le schéma suivant montre une infrastructure Magento 2 redondée, avec répartition de charge (“load balancing”).

 

ElasticSearch possède un mécanisme de haute disponibilité natif. Il en est de même pour Redis, même si les données de session et de cache sont souvent jugées moins critiques.
Le partage de fichier peut être géré par NFS, voire un autre mécanisme proposé par votre hébergeur.

En ce qui concerne la réplication MySQL, nous recommandons d’utiliser le module Galera, implémenté dans Percona XtraDB Cluster ou MariaDB. Par rapport à une réplication MySQL classique, ce composant rend la réplication plus robuste et facilite grandement les bascules. Un lien réseau rapide est un prérequis à ce genre de réplication semi-synchrone.

Attention à l’augmentation de complexité liée aux mécanismes de haute disponibilité. Ces mécanismes doivent être testés régulièrement afin d’éviter les mauvaises surprises au moment où ils sont vraiment nécessaires.

Les processus de déploiement sont également à modifier pour livrer le code source sur tous les frontaux en même temps. L’outil Capistrano est très utile pour gérer les déploiement multi-fronts, ainsi que les rollbacks.

Quels sont les bénéfices d’un CDN ?

Le CDN (Content Delivery Network / Réseau de diffusion de contenu) a pour objectif de fournir un cache HTTP au plus proche des utilisateurs, afin d’optimiser les temps de téléchargement, et donc le temps de rendu des pages Web.

Conclusion

De nombreuses solutions s’offrent à vous pour l’architecture d’une plateforme Magento 2. Ces choix dépendent du niveau de performance et de haute disponibilité désiré, mais aussi de votre budget.

Aussi, si vous rencontrez des difficultés avec votre architecture d’hébergement ou si vous souhaitez faire évoluer votre architecture pour optimiser les performances de votre plateforme Magento, n’hésitez pas à nous écrire !