Memcached, Varnish – La problématique du caching pour des sites à fort trafic

by Posted on


Lorsque votre site fait un très fort trafic (c’est bien tout le mal que l’on vous souhaite), la question de performances des temps de réponse, d’affichage bref d’optimisation de l’expérience utilisateur (UX) de votre site ne va pas tarder à se poser, parfois même cruellement et à vos dépens. C’est que l’on nomme couramment la question du caching ou de la mise en cache.

En effet, même si vous avez procéder avec une démarche “UX oriented”, pétri au scénario utilisateur et au wireframing, si les performances de votre site sont mauvaises, le bénéfice sera nul car les gens se lasseront d’attendre et se plaindront de la lenteur de votre service (en passant c’est la raison pour laquelle nous avons choisi une solution Cloud sur Amazon pour notre Webapp 3WDOC car on peut reprocher beaucoup de choses à cette application sauf celle des performances de mise à disposition :):), mais passons !)

C’est bien la question que nous allons aborder dans cet article en essayant de voir comment à l’aide d’un système de caching, on peut améliorer les performances de son site afin d’optimiser les temps d’accès et de réponse.
C’est un élément-clé, un facteur déterminant dans le succès ou l’échec d’adoption de votre site ou de votre webservice, qui pour le coup est une des vraies préoccupations partagées entre le marketing, la direction financière, l’équipe de développement, le client….etc.

Pour parodier le mot de Georges Clemenceau, “Le caching est une affaire trop sérieuse pour la laisser aux seuls mains des développeurs” *

* En l’espèce le tigre parlait de la guerre “La guerre ! C’est une chose trop grave pour la confier à des militaires.”

Developing Web Applications with Perl, Memcached, MySQL and Apache

Developing Web Applications with Perl, Memcached, MySQL and Apache

Des explications très complètes sur l'utilisation efficiente de memcached comme le titre du livre l'indique.

Genre(s) : , ,
Auteur(s) :
Edition(s) :
+ d'infos

Il existe deux solutions sur le marché qui vous permette d’améliorer considérablement ces performances d’accès à votre site. Ces deux solutions sont : Varnish et Memcached.
On va d’abord présenter brièvement à quoi sert la caching, ce que propose ces solutions memcached et varnish. Puis on verra rapidement comment implémenter memcached et varnish de sous MAMP, afin de créer un environnement de développement ou sandbox digne de ce nom. Enfin, à l’aide de nos outils favoris de wireframing, omnigraffle, on tentera d’obtenir la représentation de l’infrastructure idéal, un bon schéma vaut toujours mieux que de de fastidieuses explications. En toute fin, on donne un certains nombre de liens pour utiliser ces solutions sous WordPress notamment, dont les performances initiales de WP ne sont pas excellentes, il faut bien l’admettre.

Quelques articles d’excellence avant de commencer

Comme souvent, appréhender un sujet aussi vaste et important que la caching réclame de s’informer et éventuellement de trouver les bonnes explications avec de préférence des cas pratiques. Nous e avons trouver et on vous les livre dés à présent. On vous invite donc à lire :

  • Cet article en anglais rédigé par une des personnes du staff technique de la BBC, Simon Frost, qui détaille dans les grandes lignes, la manière dont la BCC a procédé pour améliorer les performances du site de la BBC notamment lors de la mise en production de leur iPlayer avec l’objectif avoué de rendre la chose rapide à utiliser notamment la partie dédié au caching intitulée We cache a lot

    Scaling the BBC iPlayer to handle demand (excellent)
    http://www.bbc.co.uk/blogs/bbcinternet/2010/07/scaling_the_bbc_iplayer_to_han.html

  • 2 excellents articles de Nate Haug (@lullabot), un “Senior Drupal Architect” de renom d’une société nommée Lullabot, basé à Providence (Rhode Island) qui explique de manière didactique comment installer en local les deux solutions, nous nous sommes abondamment inspirés de ces tutoriaux, qu’il en soit remercié.
  • L’article le plus complet que nous ayons en français de Stéphane Raymond @sraymond38. Un article vraiment complet, qui envoie du bois, avec schémas, explications… Lumineux
    Caching avancé et stratégie d’optimisation pour des applications web à forte charge (excellent et en français)
    http://www.stephane-raymond.com/blog/webperf/caching-avance/
  • Cette article qui détaille tout le processus de création sous Drupal de bmj.com de la méthode Agile à l’infrastructure déployé. Un “must”.
    Caching avancé et stratégie d’optimisation pour des applications web à forte charge
    http://drupal.org/node/1557636

De l’importance du caching

Le caching, c’est primordial ! En effet, les sites, les applications Web ne sont que données. Ainsi, être capable de traiter RAPIDEMENT les données, qu’il s’agisse de données stockées saisies par un utilisateur ou de la récupération de données à afficher, est la fonction principale d’une application web ou d’un site. Le problème le plus important est donc de faciliter autant que possible un accès rapide et efficace à ces données. Questionnement qui inclut un plus vaste sujet encore qu’est la scalability ou “scalabilité”, disons le dimensionnent progressif et maitrisé d’un point de vue technique et financier de votre web app ou site. Un des gros avantages du Cloud là encore.
Pour mémoire, nous avions aborder ce point dans un article précédent :

A la problématique technique de caching s’attache d’autres enjeux à ne pas négliger, notamment l’enjeux financier. La Base de Données (BDD) est sans aucun le réceptacle d’une grande partie des données nécessaires au fonctionnement d’un site ou d’une web app. Or le traitement ou la récupération de ces données depuis une BDD a un coût. Il va sans dire que plus le site connaît un fort trafic, plus la dépense concernant l’infrastructure sera exponentielle. Il faut donc rapidement trouver une solution “cost-effective” pour ne pas être la victime de son succès.

Il existe 2 typologie de données, celles qui changent constamment et fréquemment tel les données utilisateur ou celles de session et puis les autres, celles qui ne changent que rarement voir pas du tout. C’est sur ce dernier type de données que la mise en place d’un système caching peut avoir un impact positif. En effet, il est éminemment bénéfique de ne pas avoir recours de manière systématique à une base de données en vue d’obtenir ces mêmes données.

Pour donner déjà un aperçu rapide des objectifs que l’on peut se fixer lorsque on met en place un système de caching, on va montrer comment s’appuyer sur Varnish pour faire du “caching” de contenu statique, le plus demandé, et sur memcached pour les résultats de requêtes SQL, les plus fréquentes.

Cloud et Caching

Une première précision concernant le Cloud. Que vous soyez sur le Cloud ne change pas grand chose à la problématique de caching. Etre sur le Cloud est certes une très bonne chose, en effet votre infrastructure est scalable, vous disposez si votre budget le permet de ressources serveur quasi inépuisables ( instance de stockage, instance MySQL….etc) toutefois vous ne ferez même en étant sur le Cloud, l’économie sur une réflexion sur le caching.

On peut la voir d’ailleurs dans ce schéma, gracieusement mis à disposition par rackspace.com qui présente une possible architecture sur leur infrastructure Cloud que la solution de caching y est intégré à chaque fois que vous soyez un site avec beaucoup de contenu, de e-commerce ou sous wordpress.

Le schéma de l’architecture Cloud pour un CMS (Content Management System)
Une possible architecture Cloud pour un CMS comme Drupal. Pour cette configuration, l’accent est mis sur une abondante mise en cache, avec Varnish pour la mise en cache de contenu statique et Memcached pour la mise en cache de requête de base de données.

Cette configuration permet également de redimensionner horizontalement rapidement pour faire face à des pics de trafic, typiquement comme des événements ou un trafic soutenu et constamment élevé.

Memcached, Varnish - La problématique du caching pour des sites à fort trafic
Copyright © rackspace.com

Le schéma de l’architecture Cloud pour WordPress
Ci-dessous, un exemple d’architecture Cloud sur la manière dont pourrait être configuré un site sous WordPress.

Memcached, Varnish - La problématique du caching pour des sites à fort trafic
Copyright © rackspace.com

On vous invite à découvrir les autres excellents schémas proposés par rackspace.com sur tous les types d’architecture Cloud selon vos ambitions et votre coeur de métier.

Source : http://www.rackspace.com/knowledge_center/article/rackspace-open-cloud-reference-architecture

Memcached

memcached est un système de cache en mémoire distribuée haute-performance. Il s’agit essentiellement d’un serveur de mémoire simple qui fournit une couche de mise en cache pour les applications en vue stocker des données afin d’alléger la charge sur la base de données. memcached fournit également une table de “hash” (hash lookup table) pour une recherche rapide dans le retraitement des données.

Les données stockées dans memcached ne restent pas ! Ce qui signifie que celles-ci disparaissent lorsque le serveur memcached est arrêté ou redémarré. Par ailleurs, il n’y a pas de basculement (failover) ou d’authentification, c’est donc l’application utilisant memcached qui est en charge si l’on peut dire de la mise en oeuvre de la manière dont les données sont gérées et mises à jour.

memcached a une structure qui est connu comme un LRU (Least Recently Used) cache, de sorte que les données stockées qui est la plus ancienne et moins accessibles seront remplacés par de nouveaux éléments lorsque la capacité de mémoire memcached est atteint. La structure de mise en cache de memcached est connu sous le nom de LRU cache. (LRU pour Least Recently Used). Ce qui implique que les données stockées les plus anciennes et les moins accessibles seront renouvelés par de nouveaux éléments lorsque la capacité de mémoire memcached est atteinte.

Afin d’affiner la gestion dans la durée de mise en cache, memcached fournit des délais d’expiration (expiration timeouts) pour les données stockées, il est ainsi possible de choisir si les données qui seront stockées, expirent au bout d’un temps défini ou n’expirent jamais par exemple.

memcached remplace les données qui ont expiré, puis remplacer les données les moins récemment utilisées, lorsque sa capacité de mémoire est atteinte. memcached peuvent s’exécuter dans n’importe quel type de configuration: soit sur un ou plusieurs serveurs, ou même dans plusieurs instances sur le même serveur. memcached remplacera donc en priorité les données expirées ou bien si ses capacités mémoires sont atteintes, memcached remplacera les données utilisées les plus anciennes.

Il existe une grande souplesse dans la configuration de memcached : le système peut en effet s’exécuter soit sur un ou plusieurs serveurs, ou à l’aide de plusieurs instances sur le même serveur.

Comment le “truc” fonctionne exactement. Le serveur de cache fournit simplement une structure de stockage où les données sont stockées à l’aide d’une valeur clé (key value) avec en plus une table de “hash” (hash lookup table) qui permet une recherche rapide et l’extraction des données. Toute l’intelligence du système de memcached, si l’on peut dire, tient dans la liaison entre une valeur de hachage de la clé pour faire référence à ce qui est stocké ou récupéré.

memcached utilise un algorithme de hachage qui détermine notamment à quel serveur la requête d’une ou plusieurs clés doit être envoyée. Une fois déterminé, quel serveur doit fournir la réponse, les requêtes sont envoyées en parallèle aux serveurs appropriés. Chaque serveur utilise les valeur clés de recherche de sa table de “hash” ( la hash lookup table) pour récupérer l’élément stocké et renvoyer les résultats.

memcached est extrêmement rapide à la fois pour stocker et récupérer des données car le système utilise de la mémoire et non de l’espace disque pour stocker les données. Enfin, pour fonctionner, memcached ne réclame que peu de CPU et peut être exécuté sur le même serveur que le serveur web Apache, ou sur tout autre serveur ayant des capacités de mémoire disponibles (spare memory).

Quelques très bons schémas d’explications existent sur ce site pour comprendre dans ces grandes lignes le fonctionnement de memcached. Voir http://www.9lessons.info/2012/02/memcached-with-php.html

Varnish

Comme nous l’avons vu précédemment, la mise en cache est omniprésente côté serveur comme côté client (navigateur) ainsi le navigateur dispose d’un cache, la plupart des serveurs de proxy font du cache, de même que les serveurs web tel Apache ou nginx peuvent éventuellement faire de la mise en cache.

Varnish est un “reverse proxy server”. Varnish, situé en “front” du serveur web, sert le contenu du web. Comme tous les “reverse proxy server”, Varnish est étroitement jumelé avec le serveur web et interagit avec celui-ci.

Par exemple, une page mise en cache peut être rafraîchi avec une commande de purge depuis le backend de votre serveur, ce qui est bien sûr impossible à faire côté navigateur/client cela va de soi ! Ce qu’il faut comprendre, c’est que c’est vous maitrisez une mise en cache si tentez que vous administrez votre machine.

Par ailleurs, les performances de Varnish sont excellentes, le contenu web est servi de manière optimale. Avec cette mise en cache, vous pouvez faire face à des pics de trafic ou travailler sur des niveaux de trafic très élevé sans démultiplier la taille de votre infrastructure. Varnish vous évite donc d’avoir un taux de rebond élevé, en gros tout vos visiteurs verront les pages, c’est du moins l’objectif.

Bien sûr, Varnish n’est pas le seul service de mise en cache mais de nombreux site à très fort trafic l’on adopté, la BBC par exemple. Apparemment, le créateur du Varnish, Poul Henning Kamp, n’a eu de cesse d’améliorer les performances et d’offrir une grande souplesse de configuration. Varnish possède son propres langage de configuration, le VCL et il est optimisé pour du matériel tournant sous Linux ou FreeBSD.

Conclusion : Au vu de très nombreux articles et de sites à très fort trafic qui utilisent ce tandem gagnant, varnish + mecached, pour la mise en cache et les bénéfices qui peuvent en être retirés. Cela semble être ma solution qui s’impose sur les problèmes de caching.

Créer une vue d’ensemble d’une infrastructure

Notre schéma est un “mix” pas forcément forcement perfectible ! Nous ne sommes pas admin système de quelques-unes des schémas trouvés sur le web. Comme souvent ces schémas sont esthétiquement didactiques mais assez moches ! On vous propose dans notre extrême bonté, une libraire pour le wireframing sous Omnigraffle d’une proposition d’architecture “idéale” pour un site à fort trafic. Les sources d’inspiration sont :

Notre proposition d’architecture, désigné avec Omnigraffle

Memcached, Varnish - La problématique du caching pour des sites à fort trafic

La librairie de notre proposition d’architecture à télécharger au format .zip ici. Pour fonctionner, elle nécessite d’utiliser OmniGraffle Pro 5.4.2 ou +. Télécharger caching_issue_scheme_lib_hecube_3.zip


Pour ouvrir le schéma de notre proposition d’architecture, vous aurez besoin d’un “mix” des librairies suivantes sous Omnigraffle :

En savoir plus

Published by Bruno Flaven

By now, Bruno Flaven works as AI Coordinator. He has been a project manager in a wide variety of Internet business applications both in Mobile and in Desktop for 20 years now. You can find more information about his professional life on his personal website (www.flaven.fr) or his linkedin profile: https://www.linkedin.com/in/brunoflaven. He is currently working In France Media Monde (FMM) mostly on mobile applications (iOS and Android). He has also worked as P.O for a Backoffice project made with Symfony. He also made few trainings to facilitate the handling of the tools that he helps to make.

Related Posts