e-commerce caddie et sourisLa structuration de l’architecture d’un site est extrêmement importante. En effet, si elle est mal pensée, elle peut ne pas permettre au site d’accueillir tous ses visiteurs dans de bonnes conditions, empêcher des évolutions futures, et donc freiner la croissance des clients. C’est pourquoi il existe certaines bonnes pratiques à respecter pour toute architecture, dont l’une des principales est la tendance aux microservices : le découpage d’une architecture en plusieurs services indépendants et spécialisés sur une seule tâche.

Pour un site de vente en ligne, chaque visiteur perdu peut représenter une baisse potentielle du chiffre d’affaires, sans compter les impacts sur l’image de marque de l’entreprise. En effet, 79% des internautes non satisfaits des performances d’un site de e-commerce ne visiteront pas le site à nouveau1. Il est donc d’autant plus vital d’avoir une architecture sous-jacente adaptée et efficace.

Les experts de NBS System, spécialiste de l’hébergement et de l’infogérance de sites e-commerce, ont beaucoup réfléchi à ce que pourrait être l’architecture idéale d’un site, en particulier de e-commerce, utilisant un framework ou une solution PHP. Nous vous livrons aujourd’hui leurs conclusions : une architecture à laquelle on peut se rapprocher le plus possible, selon le contexte et les contraintes à la fois de l’hébergeur et du client.

Principe de base

Sur la plupart des sites de e-commerce, le premier point de contention est MySQL. Cela a du sens : une base de données peut contenir des centaines de produits (chacun avec ses variations : couleur, taille…), stocker les informations de milliers de visiteurs… MySQL ne supportant pas les lectures et/ou écritures simultanées, on peut vite atteindre des temps de chargement très longs, sur une page produit par exemple. MySQL a ses limites, et il peut s’avérer délicat de trouver l’équilibre entre performance et fiabilité.

Le principe de base de l’architecture que nous allons vous exposer est donc de solliciter le moins possible la base de données. Pour cela, on externalise un maximum de services, en multipliant les couches… et les caches ! C’est ainsi que le point de contention devient le traitement des requêtes dynamiques nécessitant du PHP, ce qui est beaucoup plus simple à gérer, comme nous allons le voir.

Architecture e-commerce

Couche n°1

La première couche de l’architecture a pour but de constituer une « première ligne » servant les composants statiques du site. Elle est composée de deux serveurs web NGINX de taille moyenne, sur lesquels est installé Varnish, un logiciel de gestion de cache. S’il est bien configuré, ce dernier permet de mettre en cache certains éléments statiques de la page, à savoir le HTML (structure, menu…). Cela concerne tous les éléments qui ne changent pas d’un internaute à un autre.

VarnishLes éléments statiques hors HTML sont quant à eux stockés sur deux serveurs de médias. Ces serveurs NGINX bénéficient également de Varnish, qui va gérer la mise en cache de ces éléments et limiter la charge effective des serveurs. Pour un site vendant à l’international, une configuration optimale nécessite également un CDN sur lequel ces serveurs seront répliqués, afin de réduire le temps de chargement des pages pour les internautes internationaux par exemple.

On est ici confronté à un problème : en effet, les navigateurs sont limités quant au nombre de fichiers qu’ils peuvent télécharger en parallèle. Par exemple, si un navigateur peut télécharger 10 éléments en parallèle, que la page contient 30 images, et que le téléchargement d’une image dure 1 seconde, cela signifie qu’il faudra 3 secondes pour que toutes les images de la page soient chargées.

Pour pallier cela, on associe plusieurs noms de domaines à ces serveurs médias (exemple.com / media.exemple.com / share.exemple.com / toto.exemple.com…). Ainsi, le navigateur pense avoir affaire à plusieurs sites, et peut télécharger plus d’éléments simultanément. En associant 3 noms de domaines aux médias, pour reprendre l’exemple ci-dessus, on réduit ainsi le temps de chargement de 3 à 1 seconde.

Revenons donc au début : nous avons parlé de serveurs web NGINX, sans développer leur rôle. Grâce au Varnish installé sur ces mêmes serveurs et aux serveurs de médias, il ne leur reste plus que quelques requêtes à traiter : celles nécessitant une interprétation PHP. Cela correspond aux éléments de la page pouvant changer selon les utilisateurs : état de connexion, état du panier, etc.

Cela ne signifie pas que le reste du site n’est pas dynamique : pour gérer ces contenus dynamiques, comme la personnalisation par exemple (mise en avant de tel ou tel produit), il est possible d’utiliser ESI et AJAX. Cependant, la structure de la page en elle-même ne change pas.

Tomcat ApacheSur cette première couche, on installe également des serveurs Tomcat. Ils hébergent le service SolR, qui est un moteur de recherche. En effet, la recherche native des frameworks envoie, en général, beaucoup de requêtes à la base de données, ce qui, on l’a vu en introduction, pose des risques de perte de performance. L’externalisation de ce service, grâce à SolR, permet donc d’optimiser ces performances. Le contenu, donné par le framework, est indexé par SolR et stocké en RAM : la recherche est donc beaucoup plus rapide, et ne nécessite pas de connexion à la base de données.

Couche n°2

PHP FPMOn a vu que la première couche gérait les éléments statiques du site. Pour servir les éléments dynamiques, nécéssitant une interprétation PHP, les serveurs frontaux NGINX envoient des requêtes à la couche n°2 : les serveurs PHP-FPM. Ce sont eux qui récupèrent la majorité de la charge, étant donné que les requêtes PHP sont les plus lourdes à traiter : c’est donc à ce niveau qu’est gérée l’évolutivité du site. En effet, il est possible d’installer autant de serveurs PHP-FPM que nécessaire pour pouvoir servir efficacement tous les internautes.

Là où est la bonne pratique, c’est qu’il faut des serveurs dédiés au canal de vente et au checkout, et d’autres dédiés au reste du site. Ainsi, si ces derniers tombent (comme par exemple à cause d’une surcharge), les clients déjà engagés dans le canal de vente peuvent finir leurs achats sans subir de ralentissement ou d’indisponibilité. De même, dans ces cas-là si un client se rend directement sur son panier sans passer par la page d’accueil, ce dernier sera accessible ! Cette configuration permet de limiter les pertes au maximum en cas de problème.

Couche n°3

Comme dans toute infrastructure, viennent ensuite les « bastions ». Ceux-ci sont mutualisés sur le serveur gérant l’administration chez NBS System, mais si vous avez du budget, il est de bon ton de bénéficier d’un bastion spécifique.

La première utilité de ces serveurs est d’administrer le site : c’est sur ce serveur que le client a accès à son back office. Un bastion est un point d’entrée unique pour un client, à partir duquel il peut accéder aux autres serveurs via une connexion SFTP ou SSH.

Les bastions peuvent avoir plusieurs utilisations annexes :

  • Réplication de fichiers : le client peut par exemple y déposer ses fichiers sources, qui seront répliqués sur l’ensemble des serveurs de son architecture.
  • Consultation de logs (journaux) : l’hébergeur doit donner au client des accès à ses logs, en passant par ces serveurs.
  • Déploiement de code : des outils de déploiement de code (Git, Capistrano, etc.) peuvent être gérés depuis les bastions.
  • Applications métier
  • Tâches cron : ces tâches planifiées sont également gérées depuis cette couche.

En résumé, sur ces bastions sont installés tous les services sur lesquels le client peut directement influer.

Couche n°4

MySQLViennent ensuite les services sous-jacent que l’on retrouve là encore dans toute infrastructure. Cette couche est composée en premier lieu de serveurs de base de données MySQL, au minimum un master et un réplicat. Le master traite les requêtes d’écriture, tandis que le réplicat gère la lecture, ce qui permet de gagner en performance. Dans une infrastructure redondée, comme sur notre schéma, on peut doubler ces serveurs (fail-over) : ainsi, si le master ou son réplicat tombent, il reste possible de séparer la lecture et l’écriture sur deux serveurs différents, plutôt que de tout basculer sur un seul serveur (mode dégradé, impliquant une baisse de performance).

RedisEn plus de ces serveurs MySQL, on trouve sur cette couche des serveurs Redis. Redis est un outil permettant de gérer le cache applicatif, et les sessions générées par l’application entre autres spécificités. Là encore, cela limite les appels en base de données… Et si on a séparé les serveurs selon leur usage au niveau global de l’architecture, c’est également une bonne pratique à adopter au niveau micro : avoir une instance Redis par usage (une pour le cache, une pour les sessions, une pour le full page cache dans le cas de Magento par exemple) permet d’optimiser les performances. En effet, Redis est mono-threadé : séparer les instances permet par exemple d’avoir accès aux sessions, même si Redis bloque au niveau du cache.

Les avantages de cette architecture

Construction architectureComme on vient de le préciser, cette architecture présente la particularité d’utiliser un serveur différent pour chaque usage. Cela apporte une liberté au client, qui comprend et sait à quoi servent chacun de ses serveurs, mais pas seulement. Cette séparation des tâches permet en effet un meilleur troubleshooting, et surtout une meilleure gestion des ressources : on peut en ajouter exactement là où on en a besoin ! En effet, sur un serveur contenant, par exemple, à la fois les serveurs frontaux et le service de traitement PHP, il est impossible de préciser à la machine que telle ressource doit être dédiée à tel service. Avec l’architecture que nous vous présentons, ce problème est résolu !

De plus, elle est optimisée au maximum : en cas d’augmentation de trafic, il suffit de rajouter des serveurs PHP FPM pour gonfler la capacité d’accueil du site. En effet, tout le reste est déjà prêt à accueillir autant de visiteurs que nécessaire, il suffit donc simplement de rajouter de la force de calcul brute ! Et pour ajouter des serveurs, NBS System utilise des ETC (Extend to Cloud) : ce sont des serveurs dormants, activables à la demande en quelques minutes, pour une réactivité maximale.

Ainsi, cette architecture est, selon nos experts, une infrastructure idéale pour un site de e-commerce : elle est évolutive, performante et compréhensible par le client. Le coût de cette architecture peut paraître élevé, mais sur le long terme cela vaut le coup : comme on l’a dit, il suffit de rajouter des ETC pour augmenter les capacités de son site.

Si vous souhaitez en savoir plus, n’hésitez pas à nous contacter !

1 http://www.ecommerce-nation.fr/ameliorer-le-temps-de-chargement-de-votre-site-e-commerce-en-12-points/

Source technique : Julien Khamis

Lucie Saunois
Lucie Saunois
Passionnée d'informatique, en particulier de sécurité, depuis qu'elle a rejoint l'OT Group en 2015, Lucie se spécialise dans la vulgarisation technique pour permettre à tous d'appréhender ces sujets parfois complexes.