Infrastructure modulaire : memcached

Après avoir parlé du loadbalancer, un autre élément important de notre infrastructure est memcached.

Memcached est un outil très largement répandu sur les infrastructures Web : il est utilisé en premier lieu pour stocker les objets en mémoire sous la forme clef / valeur.

Cela induit 2 caractéristiques importantes : une forte amélioration en performances, mais aussi une perte de la notion de persistance des données. Ainsi, si vous perdez un noeud memcached (crash, reboot etc..), vous en perdez aussi le contenu : il est donc primordial de stocker dans memcached des données pouvant être regénérées facilement, et surtout ne provoquant pas une rupture de service.

Avec Magento, s’il y a bien un endroit qui justement remplit ces conditions, c’est le répertoire /var/ et plus particulièrement /var/cache. Magento l’utilise pour stocker son cache applicatif afin d’améliorer la vitesse de l’ensemble du site. Si vous avez déjà procédé à une suppression de ce répertoire, vous avez certainement remarqué que certaines données réapparaissent immédiatement après une visite sur votre site (cache activé bien entendu). Nous avons donc un répertoire qui contient des données pouvant être générées à la volée, et dont la perte ne cause au pire des cas qu’un ralentissement. Tout est parfait dans le meilleur des mondes ?

C’est un excellent début, mais l’on peut encore faire mieux : vous pouvez mettre en mémoire ce répertoire pour accélerer sensiblement les temps d’accès à ces fichiers. C’est d’ailleurs l’une des optimisations qui est souvent recommandée par les spécialistes du sujet. L’astuce simple consiste à allouer un espace en RAM pour y stocker votre /var/cache.

Cependant tout cela a un inconvénient : comment faire pour ajuster la taille de l’espace ? En effet, la RAM est un élément précieux (surtout pour Magento) et il serait dommage d’en gaspiller, car ces quelques megaoctets  de perdus pourraient être utiles ailleurs.

Vous l’aurez compris, une réponse, ou plutôt un moyen de contourner ce problème est d’utiliser memcached : pour les mêmes effets, vous avez un espace qui est utilisé de manière intelligente : en cas de remplissage total, l’élément le plus vieux est remplacé. Un fonctionnement FIFO en quelque sorte.

Memcached est aussi utilisé, à tord selon certains, comme stockage de sessions. En effet, le principal problème est que les sessions sont souvent un élément important pour votre shop, leur effacement provoque une déconnexion des utilisateurs, la perte de leur panier, etc. Or, conceptuellement memcached n’a pas été prévu pour partager son contenu (volatile) avec un autre noeud, entrainant l’impossibilité d’établir de la redondance de manière simple. Car il faut savoir que théoriquement la perte d’un noeud memcached ne doit pas provoquer une rupture de service : en effet, dans l’esprit des concepteurs, c’est au client de gérer ce détail, comme par exemple, de passer sur un autre noeud memcached. Concernant les sessions, Magento se base sur le session handler de PHP, qui a son tour offre la possibilité d’utiliser memcache et de dupliquer les données sur N serveurs.

Après une configuration adhoc, il est possible d’avoir plusieurs serveurs memcached et d’avoir un semblant de failover, tout cela en utilisant les propriétés natives du module memcache PHP. Cerise sur le gateau, vous pouvez donc avoir plusieurs frontaux qui ont en commun ce mécanisme de session. Cela nous permet de changer votre serveur à la volée sans que les clients ne soient déconnectés, ce qui n’est pas négligeable !

En bref, en creusant un peu, il existe des solutions techniques, au niveau système, pour pouvoir arriver à vos fins. Mais soulignons tout de même que le support Memcached de Magento, s’il a le mérite d’exister, n’est pas parfait : le fallback est mal géré, le module PHP utilisé est bien memcache et non pas memcached qui offre pourtant beaucoup plus de flexibilité… Mais espérons que ceci changera dans les futures version du framework !