En guise d’introduction : après être arrivé avec David assez tôt pour lui donner un coup de main, présentation des solutions de cache, de grid computing et de datagrid par Erwan Alliaume et Cyrille Le Clerc de Xebia ainsi que Jean-Michel Bea de FastConnect. Je reviendrai plus longuement ensuite dessus. En deuxième partie, présentation de JavaRebel par Toomas Römer de ZeroTurnaround. Enfin en troisième partie, au bar le Falstaff j’ai interviewé Thierry Czarnyszka venu nous parler de Jazoon et enfin Toomas Römer sur JavaRebel, sur une proposition de Florent Ramière de Jaxio qui m’avait contacté pour cela cette semaine.
En premier lieu, vous qui êtes venu vous avez peut-être fait connaissance avec de nouvelles têtes au sein de l’équipe du ParisJUG… dont moi-même 🙂
Face au succès et au boulot que demande le ParisJUG, Antonio, David et Zouheir nous ont contacté afin de venir les aider et participer à l’animation du ParisJUG. Les 3 Jug-leaders restent les mêmes, nous sommes 4 nouvelles têtes pour aider l’équipe. Le rôle de chacun n’est pas spécialement défini, mais bien entendu selon nos profils et notre expérience, chacun apportera sa contribution. Les autres contributeurs de la « Crew » sont :
– José Paumard
– Tanguy Bayard
– Charles-Alexandre Sabourdin
et donc moi-même, Nicolas Martignole.
Erwan débute la présentation avec tout d’abord une présentation des caches distribués. Ehcache ou JBoss Cache sont deux solutions populaires de la distribution de données. Erwan explique que le premier besoin est de décharger de la base de données le chargement récurent de certaines données. Un cache permet en effet d’éviter de multiples accès à la base pour ne conserver que les données les plus lues. La JSR-107 est par ailleurs une JSR sur la gestion du cache pour ceux qui souhaitent y jeter un oeil.
L’utilisation d’un cache comme il l’explique ensuite, s’accompagne cependant d’une contre-partie, à savoir l’utilisation de mémoire, d’espace disque, et d’échanges sur le réseau afin de maintenir la cohérence du cache. Afin de ne conserver que les données les plus utiles, différentes stratégies d’éviction permettent de faire le ménage : LIFO,FIFO, temps, taille, etc.
La gestion des transactions par contre dégrade les performances, bien qu’il soit possible de s’en servir. L’objectif reste bien de décharger de la base de données et donc des utilisations comme le cache de second niveau d’Hibernate avec Ehcache sont des cas répandus. Erwan montre aussi un slide afin d’attirer notre attention sur les performances.
Il attaque ensuite le sujet des Network Attached Memory (NAM) comme Terracotta. L’objectif ici est de répliquer au niveau de la JVM les données. La mise à jour n’est plus alors applicative mais native à la JVM. C’est donc bien la JVM qui se charge de se synchronsier avec d’autres JVM. L’application adresse un espace de stockage répliqué en cluster, ce qui permet à plusieurs JVM de partager un espace mémoire commun. Erwan attire fort justement notre attention sur le besoin d’un Virtual GC comme d’une Virtual Heap, ce qui a un coût. Il parle aussi de l’invocation de méthode distante, en nous rappelant que Terracotta par ses propres mécanismes d’optimisation n’a pas forcément la même donnée sur tous les noeuds d’un cluster.
Jean-Michel Bea nous parle ensuite des Grilles de données. FastConnect dont il est l’un des consultants, est un intégrateur privilégié de Gigaspace. Il parle en connaissance de cause de ce sujet. Une grille de donnée vise à répartir et à diviser la donnée, afin de la rapprocher de l’utilisateur. Nous sommes là sur des problématiques d’architecture de haut niveau. Il présente les solutions de Grilles de données comme des « DB Shock Absorber » visant à atténuer l’utilisation des bases classiques. J’ai bien aimé aussi ses rappels sur les limites du réseau, le coût de la latence réseau et du débit limité. Nous parlons bien là de sites géographiques, d’infrastructure réseau distribuée. Cyrille prend la parole en expliquant qu’historiquement, lorsque le transport des données coûte trop cher en temps, la solution aujourd’hui est d’utiliser des procédures stockées afin d’effectuer le traitement en base. Nous savons tous aussi que le souci de ces solutions est qu’une partie de la logique métier se retrouve en base.
Cyrille prend ensuite la parole et continue la démonstration sur la Grille de donnée. Comme il l’explique, le traitement de données massives comme la réservation d’un billet de train, s’effectue aujourd’hui sans soucis sur des Mainframes. Avec une capacité de 1,5 To de mémoire et 64 processeurs, pour un coût supérieur au million d’Euro, ce n’est pas une solution envisageable partout. Sa partie sera donc de nous expliquer comment nous pouvons nous en sortir avec les solutions du marché.
Je vais passer moins en détail que la présentation de Cyrille, car son contenu était très complet. Il prend l’exemple d’un système de réservation de billet de train. Comme il l’explique, si vous devez travailler avec une grille de donnée, votre premier reflex doit être de revoir votre modèle Java. Là où une application de gestion est une pâle copie de la base relationnelle, vous devez revoir votre modèle pour utiliser efficacement une grille de données. Ses recommandations : créer tout d’abord une clé de partitionnement, constituée des données métiers, de l’association de plusieurs entités, de plusieurs classes. Ensuite, identifiez et adaptez ce modèle Java à votre problématique métier. Dans son exemple, pour déterminer si un siège de train est booké, la version SGBDR utilise une table Booking. On imagine une requête et donc une jointure. Dans le modèle Grid, il le remplace par un boolean, calculé au moment de la création et de la mise-à-jour des données.
Je comprends alors que l’utilisation correct d’une Grille doit nécessairement entrainer une refonte réfléchie de son modèle de données.
Jean-Michel reprend la parole pour expliquer le cas classique d’un transfert d’argent entre 2 comptes. Il y a quelques années, nous avons essayé de résoudre ce problème par une transaction afin que le retrait du compte A, puis le crédit du compte B, soit effectué dans une transaction. Si vous passez ce modèle vers une grille, il faudra alors isoler les 2 Comptes. Pour résoudre le problème, on créera une entité CheckOut pour le compte A avec la liste des transferts sortant. Le compte B aura une entité CheckIn avec la liste des transferts arrivant. A noter que dans la finance c’est exactement ce que l’on fait du côté du BackOffice pour la gestion des Deals entre différents Brookers sur le marché.
Jean-michel explique que la notion de transaction n’est pas nécessaire sur la forme que nous pensons. Ce qui doit être atomique, c’est l’ordre d’envoi d’argent pour le compte A, et l’ordre de réception pour le compte B, ce que font les applications classiques. Très intéressant.
On se force à ce modèle afin que par la suite, l’application puisse être déployé sur une grille. Votre modèle sera alors réparti dans un espace distribué, ce qui pourra garantir une montée en charge tout à fait correcte.
Cyrille parle de Websphere extremScale qui semble très intéressant, et Jean-Michel de Gigaspace, ce qui permet d’illustrer la discussion avec de vrais cas clients. Les questions de la salle portent sur la réelle nécessité d’utiliser une Grille. Cyrille répond avec le système de réservation de billet de train, je pense qu’il parle à cet instant de sa propre expérience chez Voyages-SNCF. Il explique qu’il existe certes des alternatives comme Oracle RAC, mais que ce sont des solutions techniques, là où eux trois viennent de nous parler de solution d’architecture, pour qu’ensuite l’application se comporte mieux et puisse monter en charge.
Après un buffet où je vous rappelle que la règle pour bien manger, c’est de rester à côté d’Antonio, la deuxième heure reprend avec notre équipe de 3 speakers. Ils viennent ensuite sur le sujet des API. Cyrille présente le pattern Map Reduce, avec un exemple de recherche de place de train, où chaque gare est colocalisée sur différents serveurs. La colocalisation des données, c’est la répartition géographique intelligente de l’information. C’est tout simplement trouver une stratégie pour ranger les données correctement.
Concernant les problématiques d’ACID, Jean-Michel explique que Gigaspace peut proposer ce type de service. Mais est-ce vraiment souhaitable ? Des solutions d’architecture et l’utilisation de patterns permettent de créer un modèle de donnée, différent du modèle relationnel, pour répondre à ces problèmes. Je retiens qu’il n’y a donc pas d’intérêt à utiliser une Grille si vous ne pouvez pas vous permettre une certaine forme d’abstraction par rapport à la base de données.
Pour terminer, ils abordent la mise à jour d’une base de données classiques par rapport à une Grid et inversement, avant de conclure avec un slide reprenant les 4 types de grilles. Je vous mettrait les détails de ce slide demain puisqu’Erwan m’a envoyé les slides.
En conclusion, une bonne présentation qui nous permet de prendre conscience que les solutions de Grid Computing s’accompagnent d’une nécessaire réflexion sur le modèle de données. La colocalisation, la déportation du traitement au plus prêt de la donnée, la mise en place d’outils de réplication avec la base de données pour le reste du modèle du SI sont donc les clés de la mise en place d’une solution de grille.
Je vous proposerai dans un autre article le compte-rendu sur la présentation de JavaRebel, ainsi qu’un interview exclusif de Toomas Römer de ZeroTurnaround, l’un des développeurs de JavaRebel.
Il présentera le même sujet le mercredi 13 mai au Tours JUG et ensuite le jeudi 14 mai au Bordeaux JUG.
Si vous lisez ces lignes et que vous êtes à Tours ou Bordeaux, dépechez-vous de vous inscrire et passez le bonjour de ma part aux JUG leader de là-bas.
0 no like
