Qui sommes nous ?
a
M

Suivez vous

Acceuil > Tous nos articles Magento & Ecommerce > Magento 2 : les bonnes pratiques d’infrastructure à ne pas négliger

Magento 2 : les bonnes pratiques d’infrastructure à ne pas négliger

Héberger un Magento 2, ça peut sembler simple. Mais entre les bonnes pratiques et les fausses bonnes idées, il y a un gouffre. Voici un guide technique et pragmatique pour poser une base d’infrastructure propre et stable.

🌐Serveur web : pourquoi Nginx est préférable à Apache

Nginx repose sur une architecture événementielle asynchrone, là où Apache fonctionne encore largement selon un modèle multi-processus (MPM prefork, worker, event).

Nginx gère des milliers de connexions simultanées sans dupliquer ses processus. C’est beaucoup plus performant pour les ressources statiques, et donc parfaitement adapté à Magento, qui envoie beaucoup de CSS, JS, images, etc.

Côté configuration, Nginx est plus lisible, les directives sont plus prévisibles, et le système de configuration par blocs (location, server) est plus modulaire que les .htaccess parfois fouillis d’Apache.

Autre point important : le support du reverse proxy est natif et très robuste chez Nginx — parfait quand on place Magento derrière Varnish ou Traefik.

🐘 PHP-FPM : le moteur PHP qu’il vous faut

PHP-FPM (FastCGI Process Manager) est aujourd’hui la norme pour exécuter Magento 2. Contrairement à PHP en mode Apache mod_php, FPM permet :

  • Une isolation des processus : un crash ou une fuite mémoire sur un processus n’impacte pas toute l’instance.
  • Une meilleure scalabilité : le serveur peut ajuster dynamiquement les processus PHP selon la charge.
  • Une configuration fine de la consommation mémoire et CPU.

Mais attention : il n’existe pas de configuration universelle. Les paramètres comme :

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

doivent être ajustés en fonction :

  • des specs du serveur (RAM disponible, nombre de cœurs)
  • du projet (trafic, charge SQL, complexité métier)
  • de son évolution (un site mieux optimisé consomme moins, donc ces valeurs peuvent être revues à la baisse)

👉 Conseil : surveillez régulièrement votre pool FPM via pm.status_path, logs slowlog, ou des outils comme Grafana + Prometheus.

Par contre, on a ces paramétrages généralement valables pour tous les serveurs Magento 2 :

pm = dynamic
pm.max_requests = 500
request_terminate_timeout = 60s
  • pm = dynamic : permet à PHP-FPM d’ajuster dynamiquement le nombre de processus selon la charge. C’est le mode recommandé, plus souple que static ou ondemand.
  • pm.max_requests = 500 : chaque worker FPM est redémarré après avoir traité 500 requêtes. Cela permet de prévenir les fuites mémoire ou autres dérives d’usage au fil du temps.
  • request_terminate_timeout = 60s : fixe un temps maximum d’exécution pour chaque requête PHP. Si dépassé, le process est tué. Une sécurité précieuse contre les appels bloquants.

⏰ Crons : ni sur les fronts, ni à l’aveugle

Le conseil est simple : n’exécutez jamais vos crons sur vos serveurs front.

  • Les crons doivent vivre sur un serveur dédié, ou a minima sur le serveur back-office.
  • Assurez-vous aussi qu’il n’y ait qu’une seule instance qui les lance. Sinon, bonjour les commandes dupliquées, les traitements simultanés, et les bugs subtils.

🔄 Montages NFS : oui, mais pas n’importe comment

Dans une architecture Magento multi-serveur (clusterisé), il est souvent nécessaire de partager certains répertoires.

Mais attention : tous les montages ne se valent pas.

✅ À monter :

  • pub/media → indispensable : c’est là que résident les images produits, catalogues, etc.
  • éventuellement var/log → utile pour centraliser les logs Magento si vous n’avez pas encore de stack ELK

❌ À ne surtout pas monter :

  • l’ensemble du dossier magento/ (vendor, generated, pub/static, etc.)

Pourquoi ?
Magento contient des dizaines de milliers de fichiers. Le moindre bin/magento setup:di:compile ou setup:static-content:deploy déclenche des tempêtes d’I/O. Avec un montage réseau (NFS, EFS, autre), cela devient un goulet d’étranglement critique. Résultat :

  • ralentissements
  • déploiements cassés
  • erreurs 500 aléatoires
  • voire corruptions de fichiers

📌 À noter :

  • NFS est courant sur les hébergements auto-gérés ou dédiés
  • EFS (Elastic File System) est l’équivalent chez AWS, souvent utilisé dans les architectures Magento sur Kubernetes ou EC2
  • Pour d’autres plateformes cloud : Azure Files, Google Filestore, etc.

👉 Ne partagez que ce qui est strictement nécessaire. Et pour le reste, privilégiez des volumes locaux rapides (SSD) et un bon système de déploiement (voir prochain article 😉).

Centraliser et surveiller ses logs avec ELK

Sur Magento, on loggue beaucoup : erreurs, événements métiers, lenteurs SQL, exceptions non catchées…
Lire tout cela en SSH, fichier par fichier ? C’est dépassé.

👉 Mettez en place une stack ELK :

  • Elasticsearch : moteur de recherche temps réel, capable d’indexer des millions de lignes de log.
  • Logstash : pipeline d’ingestion, qui agrège, filtre et transforme vos logs.
  • Kibana : dashboard graphique, pour analyser et croiser les infos en un clin d’œil.

Les bénéfices sont immenses :

  • Tous les logs Magento (et serveurs) dans une seule interface
  • Recherche instantanée sur un ID client, une URL, une erreur précise
  • Visualisation des pics d’erreurs, lenteurs récurrentes, ou incidents isolés
  • Gain de temps pour l’équipe dev et ops (et moins de stress pour tout le monde)

Vous pouvez aussi brancher un alerting (ex. via ElastAlert ou Grafana) pour être notifié en temps réel sur certains types d’erreurs critiques.

🚀 Déploiement : jamais en direct

Un bin/magento deploy:fail en prod, ça vous tente ? Non ?
Alors on ne déploie jamais sur l’instance courante. On utilise des dossiers versionnés (/releases/20240605) et on switch proprement.

Un autre article détaillera les méthodes de déploiement Magento (avec ou sans pipeline CI/CD).

🧵 RabbitMQ : pas de cron pour les queues

Magento utilise RabbitMQ pour gérer l’asynchrone. Et non, ce n’est pas aux crons de faire ce job :

  • Les crons sont déjà surchargés
  • Les queues doivent être consommées rapidement, quasi en temps réel

👉 On utilise donc un supervisor (ou systemd) qui lance et relance automatiquement les queue:consumers:start.
C’est stable, isolé, et efficace. En plus, ça permet de monitorer et relancer automatiquement en cas de crash.

🧩 En résumé

Mettre Magento 2 en production, ce n’est pas juste lancer un composer install.
C’est penser architecture, stabilité, performance.

Quelques rappels :

  • Nginx + PHP-FPM, combo gagnant
  • Des crons bien isolés
  • Du NFS bien pensé
  • Des déploiements versionnés
  • Et un RabbitMQ surveillé

🧠 L’infrastructure, c’est comme un backend solide : si elle est bien faite, vous n’y pensez plus.

👉 Pour aller plus loin sur les performances côté cache, ne manquez pas notre article sur Redis dans Magento 2, où l’on explique comment il optimise le cache et la gestion des sessions.