Aller au contenu

Système de cache Memcached

Comment Memcached fonctionne comme cache mémoire distribué sur Stack Harbor PaaS — modèle client-serveur, mémoire mutualisée entre nœuds, sémantique de table de hachage et activation dans un environnement.

Memcached est un cache d’objets en mémoire distribué, open source et haute performance. Il est conçu pour accélérer les applications web dynamiques en gardant les données fréquemment accédées en RAM, pour que l’application lise depuis Memcached au lieu de frapper un magasin plus lent (typiquement une base de données).

Le modèle mental : une grande table de hachage, distribuée sur un ou plusieurs nœuds Memcached. Les clients la peuplent et l’interrogent. Quand la table est pleine, les anciennes entrées sont évincées en ordre LRU (least-recently-used).

Les clés peuvent atteindre 250 octets ; les valeurs jusqu’à 1 mégaoctet. Les deux limites sont configurables, mais les pousser est rarement le bon choix — des valeurs énormes défont l’intérêt d’un cache.

Modèle client-serveur

Memcached utilise un modèle client-serveur :

  • Les serveurs maintiennent un tableau associatif clé-valeur en mémoire.
  • Les clients peuplent le tableau (set, add, replace) et l’interrogent (get, gets).

Les clients choisissent quel serveur détient quelle clé en hachant la clé sur la liste des serveurs connus. Les serveurs eux-mêmes ne se coordonnent pas — il n’y a pas de coordination au niveau grappe, pas de réplication, pas de basculement. Chaque serveur est indépendant, et les clients fragmentent les clés entre eux.

Cette simplicité opérationnelle est ce qui rend Memcached rapide et économique. C’est aussi la contrainte à garder à l’esprit : perdez un serveur Memcached, et les clés qui s’y trouvaient sont perdues. Memcached est un cache, pas un magasin primaire — votre application doit pouvoir repeupler le cache depuis la base quand il est froid.

Mémoire mutualisée entre nœuds

L’avantage d’exécuter plusieurs nœuds Memcached n’est pas la redondance — c’est un pool partagé de mémoire que tout le palier applicatif peut lire.

Comparer deux patrons de déploiement pour un palier web multi-nœuds :

  • Sans Memcached. Chaque nœud applicatif tient son propre cache in-process local. Différents nœuds applicatifs ont des caches différents, avec recouvrement et gaspillage. Une requête qui frappe un nœud applicatif ne bénéficie pas des données en cache sur un autre. À mesure qu’on ajoute des nœuds applicatifs, la quantité totale de cache croît, mais la cohérence entre nœuds empire.
  • Avec Memcached. Tous les nœuds applicatifs consultent le même pool Memcached. Une clé de cache donnée vit toujours au même endroit, quel que soit le nœud applicatif qui sert la requête. Ajouter des nœuds applicatifs ne duplique pas le cache ; ajouter des nœuds Memcached agrandit le pool. Les deux montent en charge indépendamment.

Le deuxième patron est le bon défaut pour tout palier web monté en horizontal où le taux de hit du cache importe.

Ajouter Memcached à un environnement

Depuis l’assistant de topologie :

  1. Cliquer Créer un environnement dans le tableau de bord.
  2. Dans la boîte de dialogue Topologie d’environnement, choisir votre serveur applicatif (par exemple Tomcat).
  3. Activer Memcached dans la même boîte de dialogue.
  4. Définir la limite de cloudlets du nœud Memcached (cela plafonne la mémoire de cache disponible).
  5. Nommer l’environnement (p. ex. memcached-demo) et cliquer Créer.

Après quelques minutes, l’environnement est en service, avec Memcached disponible sur le port 11211 au CNAME ou à l’IP privée du nœud Memcached. Les applications dans l’environnement peuvent dialoguer via le protocole binaire ou texte — chaque grand langage a une bibliothèque cliente Memcached (spymemcached et Xmemcached pour Java, php-memcached pour PHP, pymemcache pour Python, memjs pour Node.js).

Intuition sur le taux de hit

Un déploiement Memcached n’a de valeur que dans la mesure où l’application frappe le cache plus qu’elle ne le manque. Suivre le taux de hit (cmd_get_hits / (cmd_get_hits + cmd_get_misses)) sur chaque nœud Memcached — un taux au-dessus de 80% est en général bon, en dessous de 50% suggère que le cache est trop petit pour le working set ou que les TTL sont trop agressifs.

Redimensionner le nœud Memcached verticalement quand le working set dépasse la mémoire disponible.

Voir aussi