VI. Rationaliser votre infrastructure▲
Lorsque la mise en place d'une des solutions précédentes est coûteuse, il est intéressant d'examiner l'architecture physique de la solution.
Les solutions associées à l'infrastructure matérielle sont nombreuses et la plupart consistent à augmenter le nombre de serveurs.
Cette partie présente quels sont les moyens d'améliorer les performances de votre application grâce à l'augmentation des capacités matérielles.
VI-A. Upgrade▲
Le principe de l'upgrade des serveurs est simple. Il s'agit d'augmenter de façon constante les performances physiques de sa machine : ajouter de la RAM, augmenter la taille des disques ou ajouter des disques, augmenter la puissance du ou des processeurs, utiliser un système multicœurs .
Ces actions permettent d'augmenter les capacités du serveur pour accueillir un plus grand nombre de connexions utilisateurs et/ou de calculs serveur. Une fois upgradé, le serveur web sera capable d'absorber une plus grande charge.
BON À SAVOIR : augmenter la puissance d'un serveur coûte relativement peu tant qu'on reste dans une puissance « standard », mais le rapport coût/performance croît exponentiellement dès que l'on sort de la norme.
Il est préférable de rapidement s'orienter vers des solutions de clustering qui fournissent une architecture plus robuste notamment en cas de panne. Aussi, il est intéressant de définir un seuil à partir duquel il convient de stopper l'upgrade, pour démarrer une stratégie de clustering.
VI-B. Clustering▲
VI-B-1. Séparer Apache - MySQL▲
Pour beaucoup d'applications PHP-MySQL, l'accès aux données représente un point majeur de l'utilisation des ressources serveur (goulet d'étranglement). Or, dans le même temps, l'application a un besoin non négligeable de ressources pour faire fonctionner l'application PHP. Dans de nombreux cas, ces deux demandes de ressources simultanées peuvent créer des lenteurs, voire des défaillances.
Une solution pour résoudre ce problème est de séparer le serveur Apache, contenant l'application PHP, du serveur MySQL contenant le Système de Gestion de Base de Données (SGBD). Ainsi, les actions effectuées sur l'un des serveurs n'impacteront pas l'autre et les performances en seront améliorées. Le SGBD étant dans de nombreux cas le goulet d'étranglement d'un site web, il sera ici traité de façon dédiée par un unique serveur qui n'aura que cette charge à gérer.
BON À SAVOIR : dans ce cas, la latence augmente. L'application ne doit pas effectuer de trop nombreuses requêtes par page.
VI-B-2. Load-balancing des serveurs Apache▲
Le load-balancing Apache permet de distribuer le trafic sur plusieurs serveurs. L'objectif est de multiplier le nombre de serveurs capables d'héberger le site cible et ainsi de partager la charge relative aux actions utilisateurs sur plusieurs serveurs.
La distribution sera effectuée par un serveur dédié (le load-balancer). Pour les sites à très fort trafic, on aura recours à un boîtier physique (proposé par les hébergeurs) afin de rediriger les accès au site web sur les différents serveurs. Un paramétrage fin est également nécessaire pour partager les données en cache, ainsi que les données sessions (APC, Memcache). La base de données doit également être partagée pour être accessible des différents serveurs web.
BON À SAVOIR :en plus d'améliorer les performances (plusieurs serveurs répondent en même temps aux requêtes utilisateurs), il y a une autre raison pour mettre en place cette optimisation : la solution est beaucoup plus robuste. En effet, comme plusieurs serveurs fonctionnent en parallèle, si l'un d'entre eux est défaillant, les autres sont susceptibles de prendre le relais instantanément. En revanche, cela demande un suivi constant de l'activité des serveurs en utilisant Nagios par exemple. Dans le cas contraire, un serveur peut devenir indisponible sans toutefois alerter l'administrateur du site.
Note :la maintenance de la solution devient plus complexe du fait que les modifications effectuées sur un serveur doivent être diffusées vers tous les autres.
VI-B-3. SQL Master/Slave▲
Dans la plupart des cas d'utilisation d'un serveur MySQL, les requêtes effectuées sont des requêtes de lecture, de récupération de listes de produits, d'informations personnelles. Ces demandes fréquentes surchargent les serveurs MySQL qui doivent gérer par ailleurs les requêtes d'insertion (INSERT) et de mise à jour (UPDATE).
Une nouvelle solution d'optimisation d'architecture matérielle est de dédier différents serveurs MySQL à des actions précises. Un serveur maître gère alors toutes les requêtes d'INSERT et d'UPDATE, et un serveur esclave gère toutes les requêtes de sélection. Ainsi, la charge du SGBD sera partagée entre plusieurs serveurs. Pour conserver une cohérence de données, le serveur esclave est répliqué du serveur maître en temps réel.
BON À SAVOIR :une solution qui n'améliore pas les performances, mais qui augmente la robustesse de la solution est le SQL Clustering. Le principe est de mettre à disposition un nouveau serveur SQL si le principal n'est plus disponible (crash, maintenance, etc.). Cette architecture est basée sur une réplication automatique des données du Système de Gestion de Base de Données. Le serveur courant est alors utilisé pour gérer l'ensemble des actions du serveur web, pendant que le serveur de backup ne fait que recopier les actions effectuées sur le principal. L'avantage est que ce système peut être couplé à une utilisation des instances master/slave.
VI-C. Cloud Computing▲
Pour simplifier, le « Cloud Computing » peut être défini comme le moyen d'exécuter des tâches de calcul en parallèle sur différents serveurs, ce qui est intéressant dans le cadre de l'amélioration des performances, c'est la façon d'utiliser cette puissance de calcul dynamiquement, en fonction de la charge serveur.
Il est très fréquent qu'un site Internet soit soumis à des pics d'activité ; de ce fait, il n'est pas forcément nécessaire de posséder une structure matérielle maximale pendant les périodes d'activité faible, ou moindre, de votre site Internet. Le principe évolutif du « Cloud Computing », comme le propose Amazon (AWS - EC2), est de mettre à disposition de l'application une force de calcul supplémentaire (image de votre site web) quand vous en avez besoin. Ce besoin très spécifique peut être défini de différentes façons : l'utilisation du CPU du serveur, la charge mémoire du serveur ou toutes autres données relative à l'utilisation et la charge du serveur web. Toutes ces données peuvent être surveillées afin de déclencher l'utilisation de nouvelles ressources matérielles. Ainsi, votre infrastructure s'adaptera automatiquement à votre besoin.
BON À SAVOIR : ce mouvement s'accompagne des bases de données NoSQL. Ces bases de données sont moins simples à requêter, mais elles se dupliquent facilement. En fait, ces besoins sont tirés par les géants du Web (Google, Amazon…) qui ont besoin de rechercher des informations qui ne sont pas nécessairement structurées.