Memcached fête cette année ses 10 ans, il est intéressant de noter que Memcache reste si l'on regarde les tendances des demandes d'emploi calculées par Indeed.com la solution de cache la plus utilisée par les projets Java, notamment avec le très populaire client Spymemcached.
Depuis 2007 les demandes d'emploi pour les solutions de cache distribués ont fortement grossi, avec Memcached et Oracle Coherence comme leaders. Les autres solutions comme VMWare Gemfile, Terracotta EhCache, JBoss Infinispan sont également en forte croissance. Une explication possible à cette évolution et rapide adoption peut s'expliquer par l'utilisation de telles solutions par les géant du Net comme Facebook et Twitter.
Une raison possible autour de la croissante demande de compétences Memcached dans le monde Java est sa simplicité, tant du point de vue de la compréhension que de l'implémentation. Memcached semble avoir trouvé le compromis idéal au niveau des performances et simplicité d'utilisation. Ce qui n'est pas le cas des autres solutions de cache distribués qui ont étendu la liste des fonctionnalités de leur solution.
De nombreuses solutions de cache Java sont considérées comme des grilles de données (data grids), qui sont souvent vues comme des solutions de NoSQL. Il n'est donc pas étonnant de relier les demandes d'emploi autour des caches à celles du NoSQL. D'ailleurs JBoss Infinispan, et Oracle Coherence sont vus comme des solutions NoSQL dans la catégorie grille de données par http://nosql-database.org/. Les caches distribués, orientés grilles de données offrent une très grande richesse de fonctionnalités telles que "read through", "write through", transactions, partitionnement des données, élasticité et requêtage, … S'il est vrai que ces nouvelles fonctionnalités permettent de positionner ces solutions de cache dans le marché du NoSQL, la complexité peut rendre difficile la compréhension et l'implémentation pour les cas d'utilisation ne nécessitant qu'un simple cache distribué rapide et prévisible.
L'architecture de Memcached est elle beaucoup plus simple; le partitionnement s'appuie sur le hachage de la clé, qui est utilisé pour calculer l'adresse du serveur sur lequel les données sont stockées (en RAM). Memcached est en fait une grosse hashmap distribuée. L'intelligence du cache est partagée entre le client et le serveur. Memcached n'offre pas de solution pour la réplication, de requêtage, les transactions ou l'élasticité. La montée en charge se fait par l'addition de nouveaux serveur avec plus de RAM.
Il est intéressant de noter que Memcached est non seulement une solution de cache "serveur", mais son protocole d'échange a également participé à sa grande adoption. Le protocole Memcached est utilisé par de nombreuses solutions qui fournissent des fonctionnalités comme la réplication, et l'élasticité, par exemple, Amazon ElastiCache, Google App Engine Memcache, Gear6, Memcachedb et Couchbase. Il est possible par exemple d'acceder à JBoss Infinispan en utilisant le protocole Memcached. Le protocole Memcached est devenu un standard de fait pour le cache avec des librairies clientes disponibles pour PHP, Python, Java, C#, C, Ruby, Go et plus.
InfoQ a pu discuter, en 2011, avec Dustin Sallings, le développeur de Spymemcached, le client Java pour Memcached le plus utilisé, pour qu'il donne son point de vue sur la croissance de Memcached, et avoir également des nouvelles sur le protocole Memcached et Couchbase.
InfoQ : Quel est votre rôle dans Memcached, Membase/Couchbase et Spymemcached ?
J'ai écrit Spymemcached lorsque j'ai rencontré ce besoin durant mon travail quotidien. Je me suis retrouvé dans la communauté Memcached peu de temps après, et j'ai commencé à contribuer sur des fonctionnalités clés et corrections de bugs sur Memcached lui même. A un moment donné j'étais même le contributeur principal en nombre de commits, depuis j'ai été dépassé par d'autres personnes qui font un travail fantastique.
Membase est arrivé pour résoudre les problèmes que Memcached n'arrivait pas à résoudre ou pour lesquels Memcached n'était pas la bonne solution. Membase implémente un modèle attendus par certains utilisateurs tout en ne nécessitant que très peu de modifications sur ce qu'ils font actuellement.
Depuis, Membase Server a totalement été remplacé par Couchbase Server. Couchbase Server est construit au dessus de Memcached et fournit un stockage distribué supportant une approche clé/valeur et document. Avec Couchbase les données ne sont pas uniquement en RAM mais également stockées sur disque. Couchbase est élastique, ce signifie qu'il est possible d'ajouter et de supprimer des serveurs Couchbase d'un cluster. La réplication de données permet d’être tolérant aux pannes.
InfoQ : Pourquoi pensez vous que les caches sont de plus en plus utilisés depuis quelques années ?
Je suppose qu'il s'agit surtout d'un point de vue. Les caches ont toujours été très important là où je travaillais. Mais maintenant, avoir beaucoup de RAM n'est pas coûteux et n'importe qui avec une idée intéressante peut avoir accès au monde entier en quelques jours. Pour de nombreuses applications, accéder au disque est bloquant. Cela peut être vu comme une lecture d'une sauvegarde sur une bande.
InfoQ : Selon vous quel est le rôle de Memcached dans l'utilisation de plus en plus fréquente de caches ? Et pourquoi ?
Memcached est le cache d'objet standard depuis longtemps, principalement parce qu’il est très simple à utiliser, performant et prédictible.
InfoQ : En se basant sur les demandes d'emploi, Memcached est le premier cache open source que les développeurs Java utilisent, détronnant EhCache, voir Oracle Coherence. Comment Memcached a-t-il pu quitter le monde LAMP et gagner un si grande visibilité chez les développeurs Java ?
S'il est vrai que la RAM est de moins en moins chère, elle n'est pas non plus gratuite. La gestion de l'allocation de la mémoire de Memcached a certaines faiblesse, mais une fois bien configurée, Memcached est très fiable, et proche de l’efficience maximale tant du point de vue de la gestion du temps que de l'espace. Les solutions plus complexes sont quant à elles moins prédictible et consomment plus de ressources, ce qui les rend moins efficace comme solution de cache.
InfoQ : Quelle partie du design de Memcached (architecture et protocole) a permis à Memcached de rencontrer une tel succès ?
Le protocole Memached est tellement simple qu'il est implémenté quasiment partout lorsqu'il y a une couche réseau. C'est juste une de ces fonctionnalités que les développeurs aiment ajouter lorsqu'ils construisent quelque chose. Cela a donc rendu ce protocole disponible quasiment partout.
Dustin ajoute également que le protocole et serveur Memcached a été enrichi, pour les besoins de Couchbase (et précédemment Membase), mais également pour rendre Memcahed plus modulaire et simple à réutiliser/intégrer. Parmi les extensions développées par Couchbase, le support du multi-tenant est l'un des élément clé permettant l'utilisation de Memcahed sur le cloud. Couchbase a également créé le protocole "tap", fonctionnalité que Dustin voulait ajouter depuis longtemps dans Memcache, qui permet d'observer les mutations de données sur les différents nœuds. Le protocole "tap" est un élément clé de la réplication, ré-équilibrage (rebalance), et gestion des sauvegardes de Couchbase.
InfoQ : J'ai lu sur votre blog que vous avez implémenté un serveur Memcahed en Erlang. En combien de langages avez vous implémenté des serveurs Memcached ?
Je ne me souviens plus… J'en ai écrit un en Go le lendemain de l'annonce par Google de ce nouveau langage. Je n'ai pas utilisé directement, mais je l'ai utilisé pour travailler sur d'autres projets. Notamment lors de l'écriture des tests, et de l'implémentation du protocole "tap".
J'ai également écrit une implémentation avec Twisted (Python) il y a un certain temps. J'ai développé un stockage pour Memcache base sur S3 sur Amazon EC2. Je ne suis pas certain d'open sourcer ce projet. C'était élégant.
L'implémentation d'origine du protocole Memcached binaire s'appuyait sur un script Python asyncore, que j'ai écrit en même temps qu'un client correspondant. J'utilise toujours ces implémentations pour démarrer beaucoup de mes travaux.
InfoQ : Gemfire, Coherence, Ehcache Enterprise, Infinispan et d'autres solutions de cache supportent les requêtes, transactions, "read through", "write behind", partitionnement des données, réplication de données, etc … Memcached n'offre pas toutes ces fonctionnalités et malgré tout est un succès, pourquoi ? Est-ce parce qu'il est plus simple, donc plus facile a comprendre et utiliser ?
Comme je l'ai dit précédemment, Memcache est limité aux opérations qui peuvent être implémentées en utilisant les algorithmes O(1). Tout, depuis un "set" (NdT : stockage de donnée dans le cache) jusqu'au "flush" (NdT : suppression de toutes les données du cache) ont une complexité algorithmique plus ou moins identique. Il n'y a pas d'augmentation de la complexité avec un nombre plus grand d'objet en cache. Il n'y a pas d'opération avec : expression régulière, tag, préfixe, etc tout simplement parce qu’il n'est pas possible de le faire sans ralentir le système.
Si vous voulez exécuter des requêtes il faut indexer. Si vous indexez vous consommez de la mémoire et vous avez de nombreuses choses qui doivent être exécutées lorsqu'il y a des données à entrer ou sortir du système. Vous allez également devoir gérer de nombreux locks, et pression sur le cache qui affecteront les performances. Et notez que vous avez les bases de données pour faire cela.
C'est similaire pour les transactions. Vous allez devoir payer un certain prix pour supporter des transactions.
En général, vous avez raison pour la complexité. Les gens aiment les fonctionnalités comme la RAM, CPU, Locks et les bugs. Les fonctionnalités avancées amènent leur lot de problèmes, et vous allez passer de plus de temps sur ces problèmes au lieu de faire des choses simples. Les développeurs vont devoir regarder comment leur application va pouvoir gérer le contrôle de transaction en mémoire, et que faire en cas d'échec.
Memcached est un cache. Un problème ne va affecter que les performances, mais ne doit pas participer à un comportement incorrect de l'application.
C'est un cliché, mais : les contraintes vous libèrent !
InfoQ : Comment démarquez vous les grilles de données, le NoSQL et les caches d'objet ?
Je vois ça comme hardware, philosophie et software. :)
InfoQ : Quelles sont les fonctionnalités les plus importantes d'une implémentation NoSQL ?
Il y a les fonctionnalités dont vous avez besoins, et les fonctionnalités dont vous pensez avoir besoin rapidement. Il y a tellement de solutions et la plupart sont très bonnes pour faire les choses pour lesquelles elles ont été conçues.
Par exemple, lorsque je travaillais sur Membase, j'utilisais en secret CouchDB sur un des mes projets personnels, simplement car c'était le bon outil pour cette tâche. Nous avons regardé CouchDB avant de commencer Membase, et nous avons décidé que cette solution était trop loin de nos objectifs pour l'utiliser convenablement.
J'ai quelques fois recommander des produits concurrents lorsque les utilisateurs avaient des besoins qui étaient bien couverts par ces solutions.
Les différences vont peut être s'estomper avec le temps, mais vous pourriez également demander quelle est la fonctionnalité la plus importante pour une structure de donnée. Elles stockent tous types de données, mais dès que j'ai voulu en utiliser une pour faire quelque chose pour laquelle elle n'avait pas été conçue, j'ai échoué. Et c'est encore plus vrai lorsque le système se complexifie.
InfoQ : Un problème récurrent avec l'utilisation de Memcached, est le fait que les entreprises s'appuient de plus en plus sur Memcahed, et décharge de plus en plus de charge de la base de donnée sur le cache. En faisant cela le système est tellement dépendant de Memcached qu'il n'est plus possible de perdre un noeud Memcached. Puisque Memcached ne supporte pas la réplication de données, quelques sont les options possibles pour les développeurs ?
Un de mes collègue a dit un jour "Si tu as quelqu'un dans ton organisation que tu ne peux pas perdre, renvois le tout de suite avant que ce soit pire". C'est un sentiment similaire ici. Memcached a été construit pour être "jetable". Si votre service ne peut pas fonctionner si un nœud tombe, qu'allez vous faire si vous avez une coupure d'électricité ? La première chose à faire, c'est de rendre ces systèmes "jetables".
Quelques fois, bien sur, les personnes ont simplement besoin d'un stockage de donnée à plat. Certaines des plus grosses installations de Membase étaient avant des Memcached au dessus de MySQL. Dans ces cas, MySQL était presque considéré comme une simple sauvegarde. Il y avait une écriture au travers du cache qui avait était mis en place avec d'autres composants. Ils ne voulaient pas service des données qui n’étaient pas en mémoire. C'est pour ce genre de scénarios que Membase a été conçu, et peut ajouter plus de disponibilité, élasticité tout en réduisant la complexité. Vous avez juste à réfléchir au "capacity planning". Si vous avez un cluster de quinze nœuds, et votre application est tellement populaire qu'éteindre un nœud surchargerait votre cluster, il faut juste ajouter des nouveaux nœuds. Continuez d'ajouter des nœuds jusqu'à ce que vous soyez confiant. Si tuer un nœud, tue votre business, soit vous trouvez des ordinateurs indestructibles, totalement redondés et qui viennent avec leur propre centrale nucléaire ou ajoutez d'autres serveurs. Membase facilite la deuxième approche.
Membase, Couchbase et les autres produits qui supportent le protocole Memcached tout en fournissant de la persistance et de réplication, représentent une protection contre les "mauvais" cas d'utilisation de Memcached. Couchbase Server, comme son "parent" Membase, est également une solution simple pour aider les utilisateurs de Memcached à adopter le NoSQL dans leurs projets.
InfoQ : Quels outils tiers existent pour rendre Memcache tolérant aux pannes et élastique ?
L’élasticité avec Memcached a toujours été un sujet difficile. Il y a quelques forks qui ont ajouté le support pour le réplication, mais le modèle par défaut est le suivant : si le un nœud disparaît, il faut considérer que les données situées dans cette partie du cache ont disparu. Il faut donc les remonter dans le cache par le biais de l'application qui va faire des "caches misses". Ce modèle fonctionne très bien.
Ajouter des nœuds Memcached réduit le risque et le pourcentage d'accès à la base de données même lorsque certains nœuds tombent.
InfoQ : Pouvez vous décrire le concept de vBuckets ?
Les vBuckets sont des containers virtuels situés sur une machine physique ce qui permet de créer des sous ensembles de données pouvant être déplacés dans le cluster.
Une couche de management fixe un nombre de vBucket pour l'ensemble des nœuds de votre cluster, et communique cette information à vos clients (applications). Les clients, lorsqu’ils vont stocker ou récupérer des données, vont attribuer de façon déterministe dans quel vBucket ces données doivent être. Le client va ensuite directement sur la machine où doit se trouver le vBucket et effectue l'opération sur les données.
Nous avons des outils qui peuvent automatiquement déplacer les vBuckets d'un nœud vers un autre, même lorsqu’il y a de l'activité sur le cluster. Dans ces cas les opérations sur les données continuent sur le nœud initial jusqu'à ce que le dernier morceau de donnée ai été copié sur le nouveau nœud, de même le nouveau nœud n'acceptera les opérations sur ce vBucket qu'une fois que l'ensemble des données ai été reçue.
En pratique, nous pouvons déplacer des gigaoctets de données tout ayant des clients qui lisent et écrivent des données de façon intensive. Il y a juste un petit délai lorsque le client est informé qu'il a essayer d’accéder à des données qui ont été déplacées.
VBuckets utilise le hachage des clés pour distribuer les données de Couchbase et et permettre de déplacer les données rapidement sur un cluster lorsque la topologie de celui-ci change (ajout/suppression de noeuds). Il faut également répliquer les données, de façon distribuée pour pouvoir être tolérant aux pannes. Les vBuckets font partie du protocole réseau, c'est pourquoi lorsque le client supporte cette fonctionnalité, l'application cliente est automatiquement alertée lorsqu'il y a des changements de topologies que les données ont été déplacées sur une autre nœud.
Dustin a ensuite expliqué que les vBuckets permettent de différencier un "je ne sais pas", d'un "je ne peux pas savoir". Avec la stratégie précédente lorsqu'une machine disparaît du cluster, les clients dirigent automatiquement leurs requêtes sur une autre machine et commencent à l'utiliser, mais les données ne sont pas nécessairement dans le cache (cache miss). Cela fonctionne jusqu'au moment où les clients accèdent à plusieurs machines ayant les mêmes données, et donc de manière inconsistante. Avec le modèle de vBucket,la coordination est gérée de façon indépendante, les serveurs restent autonomes. Les serveurs ne savent pas lequel d'entre eux contient telle ou telle donnée, mais le serveur sait si un client interroge le mauvais serveur et à besoin de se reconfigurer. Memcached, n'a pas besoin de réplication ou transfert de données, il suffit d'ajouter ou enlever un ou plusieurs serveurs, et le protocole vBucket va informer les clients que les données ne sont pas présentes et qu'ils doivent se reconfigurer eux mêmes. Les serveurs ne connaissent pas la différence. Pour Couchbase, qui n'a pas la même façon de gérer le cache, il faut transférer l'état du cluster (FSM - Finite State Machine) ce qui rend très simple la gestion des donées et leur déplacement/répartition sur un autre serveur. Les vBuckets ont été initialement développés pour Membase/Couchbase mais il faut maintenant partie du protocole Memcached, et "les clients memcapable 2.0+ API peuvent donc utiliser les vBuckets si le serveur les supporte également".
InfoQ : Combien de projets/produits utilisent le protocole Memcached ?
Je ne sais pas. Il y en a plein.
InfoQ : Y-a-t-il de gros changement prévus au niveau de protocole Memcached ?
Le protocole binaire est stable depuis un certain temps maintenant, mais il n'est pas encore très utilisé. Avec les langages de script orientés Web, il est plus difficile de tirer partie de certains avantages de ce protocole. En Java, j'ai pu doublé le débit en utilisant le protocole binaire.
InfoQ : Comment le protocole a-t-il évolué au fil des années ?
Au niveau du protocole texte/ASCII, des petites choses ont été ajouté ici et là. Nous avons ajouté de petites choses qui permettent quelques fonctionnalités très pratiques, et d'autres qui ont été plus décevantes. Au niveau du protocole binaire, nous avons fait ajouter des choses régulièrement. Certaines personnes aiment le protocole text. Pour moi, je peux prendre le protocole binaire et implémenter le client convenablement très rapidement. Je pense que les deux parties se regardent avec confusion. Avec le travail que nous avons fait sur 1.6, il est facile de créer des extensions sur les deux protocoles.
InfoQ : Avez vous vu le test de performance Ehcache contre Memcached ? Si vous ne voulez pas, ne répondez pas.
Je les ai vu. Tous les tests de performances contiennent souvent des mensonges (pas nécessairement volontairement). J'ai rarement vu un test dans lequel, lorsque j'ai regardé le code je n'ai pas vu de failles.
Par exemple, j'ai regardé il y a quelque temps, un benchmark Memcached contre Redis, qui montrait que Redis était beaucoup plus rapide que Memcached. Les programmes de tests étaient vraiment différents, et montrait simplement qu'un client Redis particulier était plus rapide qu'un client Memcached particulier. Cela est malheureux.
A propos du test Ehcache, je vois des choses similaires. Quelque chose ne semble pas correct. Celui que j'ai trouvé avec Google, montre Memcache qui consomme 10 000 sets en 3.4 secondes. Dans mes tests avec le même client, j'ai pu monter a 1 000 000 sets en 10 secondes. Je n'ai pas vu le code, ni les détails du scénario, je ne peux donc pas voir les différences; mais quelques chose semble incorrect.
Il est également important de noter qu'en fonction du cas d'usage, les résultats des tests peuvent être très différents. Utiliser Memcached dans un scénario pour lequel il n'a pas été conçu peut impacter les résultats.
InfoQ : Avez vous été contacté pour rejoindre la JSR-107 ? Il semble naturel d'avoir quelqu'un avec votre expérience et statue dans cette JSR.
Non, je n'ai pas été impliqué dans le Java Committee. Il n'y a pas de langage en particulier avec lequel je me sens "chez moi". La communauté Java conçoit des spécifications particulièrement bien pensées, mais beaucoup trop d'entre elles sont quasiment impossible à implémenter de façon efficace. Par exemple, la plupart de la spécification JCache ne peut pas être implémentée au dessus de Memcached. Ma contribution au groupe serait souvent "Je ne pense pas que cela peut bien fonctionner".
Le dernier organisme de standardisation auquel j'ai participé était constitué de personnes intelligentes qui n'écrivent pas de software, qui me demandaient : "mais est-ce possible ?" J'ai pris un certain plaisir à faire fonctionner le standard malgré la grotesque complexité.
Dustin a commenté le fait qu'il ne dénigrait pas Java, les JSR, ni les organismes de standardisation.
Chaque cas d'utilisation ou problème de cache veut souvent dire une solution de cache particulière pour bien répondre aux besoins. Même si Memcached n'est pas la meilleure solution pour tous les cas d'utilisation de cache, Memcached semble avoir trouvé le juste équilibre entre vitesse, simplicité et prévisibilité, comme le montre la forte demande autour de Memcached. La où de nombreux vendeurs de solutions de cache ajoutent de plus en plus de fonctionnalités, Memcached se limite à un nombre moins important de fonctionnalités. Le protocole Memcached est supporté par les vendeurs qui ajoutent le support pour la réplication, persistance et élasticité. Le protocole Memcached est devenu le standard de fait supporté par de nombreux projets, produits et fournisseur de plate forme Cloud (IaaS et PaaS).