Pause repas en compagnie de quelques français (Christophe Jollivet du ToursJUG et du site Developpez.com, Pierre-Alexandre Gregoire d’Agile Partner, Anthony Dahanne de Valtech). Puis reprise en direction de la salle 9. Jazoon est organisé dans un grand cinéma style UGC. Les conférences ont lieu dans des salles de cinéma, très confortables et correctement sonorisées.
Bela Ban de JBoss/RedHat est d’origine Suisse. Après un PhD à Zurich, un post-doc à l’université de Cornell, il rejoint la Californie, et il démarre le projet JGroups, intègre JBoss RedHat par la suite, pour s’occuper du projet JBossCache et JGroups.
L’objectif de la présentation sera de nous présenter une implémentation de memcached réalisée en Java, des résultats sur les performances et une discussion sur les DataGrids. Bela Ban est un excellent orateur, sa présentation était très intéressante, animée par une démonstration en direct.
Pour commencer, une phrase afin de marquer les esprits:
« Memory is the new disk. disk is the new tape (Tim Bray) »
La mémoire est le nouvel espace de stockage, finalement le disque dur n’est-il pas devenu aujourd’hui l’équivalent des lecteurs à bande des années 80 ? La base de données est un point de contention, les allers-retours demandent des accès réseaux, ce qui dégrade les performances.
Cependant, il n’est pas possible de stocker toutes les données en mémoire sur un seul serveur. Tout d’abord pour des raisons de place, mais aussi parce que la mémoire ne résiste pas à un crash.
memcached est un serveur de cache écrit en C qui fournit un service de cache de type HashMap en mémoire. Le client du cache peut être écrit dans n’importe quel langage, puisque le protocole pour utiliser memcached est très simple. Il y a un Get, un Put, un Remove, c’est une simple HashMap. Des exemples d’applications Webs connues qui utilisent memcached : FaceBook par exemple. 800 serveurs, 28 TeraBytes de données, memcached est un cache massivement répliqué, qui évite des accès disques très couteux en architecture distributée. C’est donc une grille de données distribuées. (voir cet article de FaceBook)
Le protocole de memcached propose 6 opérations pour enregistrer ses données, 2 opérations pour retrouver une donnée unique ou un ensemble. Les échanges s’effectuent avec de l’Ascii par dessus du HTTP. Bela Ban explique que l’un des soucis de ce protocole est qu’il n’y a pas d’indicateur de la taille des buffers, ce qui fait qu’il est difficile avec Java NIO de préallouer efficacement des buffers.
Il n’y a pas de cache de niveau 1 du côté du client, cela n’étant pas dans l’objet de memcached, bien que certaines implémentations du côté client soient capables de conserver des données.
Les données sont stockées avec une date d’expiration, mais plusieurs serveurs memcached ne se connaissent pas entre eux, il n’y a pas de réplication entre les noeuds. Lorsqu’un serveur memcached (c’est un cache rappelons-le) s’arrête, ses données cachées disparaissent, et il faut alors prévoir un reash de l’ensemble de la grille pour redistribuer les données. Imaginez une partie de Poker, l’un des joueurs s’en va, il faut alors reprendre les jetons de chacun et les redistribuer de manière équitable. Cette maintenance et cette fragmentation du cache est coûteuse.
Implémentation d’un serveur memcached en Java
Bela Ban présente maintenant son implémentation d’un serveur compatible avec le protocole memcached, mais réalisée en Java. Tout d’abord dans son exemple de cache distributé, le client en Java dispose d’un cache L1 pour optimiser les performances. Du côté des grosses différences par rapport à l’implémentation en C, chacun des « ReplCaches » (son implémentation Java de memcached) utilise JGroups pour découvrir ses voisins. Les données sont donc automatiquement distribuées de manière efficace dans la grille, constituée par plusieurs serveurs « ReplCaches ».
Lorsqu’une donnée est placée dans le cache, selon la clé de hashage de cette donnée, la grille de données s’optimise automatiquement. Par ailleurs la réplication entre les serveurs memcached en Java se fait via un protocole binaire optimisé, ce qui permet de bien meilleurs performances avec la version Java que la version C.
Le protocole peut aussi être adapté, c’est le fonctionnement de JGroups. Si vous souhaitez ajouter de l’encryption, de la compression, il est possible de configurer la couche JGroups finement. Cela réduit l’usage du réseau. Bien entendu, TCP comme UDP sont supportés.
Démonstration
Le « ReplCache » est embarqué dans un conteneur de Servlet, dans le même espace d’adressage. Arrive maintenant le moment le plus intéressant je trouve de sa présentation. Il explique qu’il utilise ses « ReplCache » comme des disques durs physiques. Il est possible de sélectionner une stratégie de stockage pour chaque donnée, afin de faire… du RAID de données. Il est donc possible de définir si l’on souhaite qu’une donnée soit répliquée ou non plusieurs fois dans la grille.
Les données qui peuvent être relues rapidement de la base de données pourront être reglées avec un compteur de replication (repl-count) = 0
Les données critiques de travail de votre session (un panier d’achat) que vous ne devez pas perdre en cas de crashes, peuvent être répliquées dans toute la grille avec un compteur repl-count=-1. Sinon en général, l’usage est de ne stocker qu’une seule fois dans le cache cette donnée, la clé de hash permet de trouver rapidement quel serveur stocke la donnée. Il s’en sert comme d’un espace d’adressage, chaque client sait que par exemple les clés de A à H sont sur le serveur 1 et les clés de I à Z sont sur le serveur 2, ce qui permet vraiment d’optimiser les performances.
JBoss Infinispan
Bela Ban présente ensuite le projet Infinispan, une grille de données open-source basée sur l’implémentation en Java memcached, avec la possibilité de passer des objets de type Runnable, ce qui en fait aussi une grille de calcul.
JBoss Infinispan est une implémentation de la JSR-107, la distribution du contenu caché est effectué selon la clé de hachage, afin d’assurer une distribution fine de celle-ci. Il est possible de créer un espace de stockage immense. 100 noeuds avec 2 Gb de mémoire, configuré en copie représentent 100 Gb d’espace de mémoire adressable. La mémoire est le nouveau disque dur comme il le rappelle.
Infinispan est aussi compliant JTA et offre le support de JMX pour proposer une interface de gestion performante. Il est compatible avec le protocole ASCII classique de memcached, ce qui permet de brancher un serveur en PHP avec un cache Infinispan par exemple. Bien entendu le protocole binaire dont il a parlé est plus intéressant, et l’un des objectifs du projet sera de fournir rapidement des implémentations du côté client en C et en PHP.
Du côté Java, l’API offre aussi une gestion asynchrone pour par exemple stocker de manière asynchrone une donnée :
FutureputAsync(K key, V value)
Perspectives
Bela Ban termine la présentation avec quelques idées pour la suite. Tout d’abord, réellement développer l’idée que la grille est un système de stockage de données, un file system. Pour cela, il imagine proposer une api type java.io pour utiliser la grille pour lire et écrire des données massivement répliquées. Encore une fois : Memory is the new disk, why can’t we implement JDBC on top of the grid ? use-it as a disk ? And what aboute Hibernate on a grid ?
La mémoire est le nouveau disque dur, celui-ci n’étant plus aujourd’hui que le vieux lecteur à bande destiné à faire une sauvegarde persistente.
Références
Démonstration Java WebStart de ReplCache : http://www.jgroups.org/jnlp/replcache.jnlp (lancez 2 ou 3 fois l’application en cliquant plusieurs fois sur le lien)
ReplCache Flash demo: http://www.jgroups.org/movies/ReplCache.swf
Infinispan : http://www.infinispan.org
