HA HA HA Terracotta

High Availability, High Availability, High Availability, **Terracotta** !

Ari Zilka est à l'origine de Terracotta. Il possède une expérience sur les infrastructures des sites internet qui ont un grand nombre de clients simultanés.
Cette caractéristique s'appelle la haute disponibilité. Lors de son passage à Paris pour la soirée Terracotta, il a pu expliquer son rôle en tant que Directeur technique de Walmart.com. Comment structurer l'application web qui gère les ventes sur le site afin que les clients obtiennent une disponibilité acceptable ? Son équipe et lui ont alors alterné entre deux lignes de conduite:

• tout en mémoire
• tout en base

La première façon de faire permet de gagner sur la performance car la session n'est pas écrite sur le disque. Cependant, on peut difficilement faire du "load-balancing" car la session est piégée dans la JVM qui répond au client. En revanche, si toutes les interactions avec l'utilisateur passent par une sérialisation de la session en base, il n'y a plus de problème lors d'une panne ou d'une modification de la charge serveur. Évidemment, le point de contention devient la base qui est vite saturée.
D'autre part, ces approches sont figées dans le code applicatif. Toute modification de politique entraîne une modification de l'application elle-même. Ainsi, la clusterisation n'est seulement possible qu'au dessus de l'application avec l'utilisation de services comme JMS, RMI, RPC ou JCache.

C'est en analysant cette expérience qu'Ari a commencé à creuser son concept. En s'inspirant des NAS (Network Attached Storage), il crée le concept de NAM (Network Attached Memory). En s'intercalant dans la JVM partout où java est en interaction avec la mémoire vive, Terracotta offre à l'application une mémoire distribuée sur toutes les JVM connectées. Terracotta n'est donc pas une API car le développeur continue d'écrire en java.

En fait, Terracotta transforme ces services qui ne sont fournis que pour **une** JVM, sur un **cluster** de JVM:

• unicité de l'identifiant d'une instance
• unicité du moniteur qui gère la concurrence d'accès à cet objet par les multiples threads

Une de ses visions business m'a semblée intéressante. Dans une application e-commerce, il est classique de mémoriser en base le cheminement d'un utilisateur jusqu'au paiement final. Ari pousse la logique de réduction du gaspillage jusqu'au bout: pourquoi peupler la base de l'entreprise (ressource) avec des données qui peuvent s'avérer inutiles si le client décide de ne pas poursuivre finalement son achat ? Avec son produit, ces données ne font que transiter par son cluster (si besoin) et la transaction finale n'est enregistrée en base qu'en cas de paiement !

Cette soirée fut très intense. Ari a en effet une grosse expérience fortement chiffrée à partager (comment fait-il pour se souvenir de toutes ces données sur les cas de ses clients/utilisateurs !). C'est une bonne démonstration de la capacité à faire le point sur 10 ans d'expérience pour en sortir un produit open-source innovant. En tant que développeurs java, nous avons peut être trop tendance à raisonner en termes de nouveaux frameworks sans penser aux limites que nous impose la JVM. Terracotta a su dépasser le cadre de la JVM pour proposer une solution simple à un problème complexe.

Quelques pointeurs utiles pour finir:

• Présentation au FOSDEM 2008 (Free and Open Source Software Developers' European Meeting)
• Une démo très "pro" qui met les choses au clair sur les atouts de la solution.

---