Dans cette première partie nous allons uniquement présenter Terracotta et dans une deuxième partie, probablement demain, nous présenterons des cas d’utilisation. Au cours de la dernière décennie, les systèmes informatiques ont enregistré une montée en charge foudroyante, et de nouvelles problématiques de scalabilité se sont posées. Aujourd’hui, les technologies standard (EJB, JMS, Jini) commencent à montrer leurs limites, tandis que le trafic réseau et les capacités de traitement des bases de données arrivent à saturation. Dans cet article, nous verrons comment Terracotta peut soulager vos architectures Java, grâce à son approche radicalement différente du clustering.
Problématique
Avant de présenter Terracotta, faisons un rapide tour des principaux problèmes rencontrés lorsqu’une application est victime de son succès. Nous prendrons ici l’exemple d’une application web.
Lorsque la charge augmente et qu’un unique serveur web ne suffit plus, il devient nécessaire de mettre en place un cluster, c’est-à-dire un agrégat de serveurs se répartissant le traitement des requêtes de manière transparente pour l’utilisateur. Pour assurer la sécurité des données de session des utilisateurs et améliorer la résilience générale du cluster, les serveurs disposent de systèmes de réplication. Mais ceux-ci souffrent de sérieuses limitations :
- Ils sont peu efficaces car ils reposent sur le mécanisme de sérialisation de Java, qui ne permet d’échanger que des objets complets, et pas de simples différentiels d’état.
- Ils saturent rapidement le réseau car le nombre de liaisons inter-serveurs augmente exponentiellement avec le nombre de serveurs.
Conscients de ces limitations et très sensibles à la sécurisation des données, les architectes estiment généralement plus prudent de stocker toutes les informations, mêmes temporaires, dans la base de données. Les architectures REST vont par exemple dans ce sens, en promouvant des couches de présentation totalement « stateless ». Mais cette décision a des impacts importants sur les performances : plus sûre mais infiniment moins réactive que la mémoire vive et supportant mal la mise en cluster, la base de données devient alors le principal goulet d’étranglement de l’application. Pour éviter les requêtes inutiles et conserver des performances acceptables, il est donc nécessaire de mettre en place des caches distribués, qui posent à leur tour des problèmes de réplication…
Le travail de l’architecte SI consiste donc à trouver le juste milieu entre la performance et la sécurité des données, tout en maîtrisant la charge des machines et la densité du trafic réseau. Voyons maintenant comment Terracotta peut aider à résoudre cette quadrature du cercle.
Présentation du produit
Terracotta est un middleware open-source gratuit pour Java de type NAM (Network Attached Memory). De la même manière qu’un NAS (Network Attached Storage) permet à plusieurs machines d’accéder aux mêmes fichiers sur un disque partagé, un NAM permet à plusieurs applications (ou plusieurs instances d’une même application) d’accéder aux mêmes graphes d’objets au sein d’une mémoire virtuelle partagée.
Afin de limiter le trafic réseau, Terracotta s’emploie à maintenir les données au plus près du code qui les utilise. Ainsi, lors qu’une application obtient un lock sur un sous-ensemble du graphe d’objet commun, ce sous-ensemble est monté (ou maintenu) au niveau de la JVM de l’application, qui y accède alors localement. Toute modification apportée aux objets est immédiatement répliquée sur le NAM pour des raisons de sécurité.
Pour toutes les problématiques de mise en cluster d’applications, de répartition de charge (datagrid) ou de distribution de données (caches), cette solution présente de nombreux avantages. Premièrement, le développement et la maintenance des applications en est fortement simplifié, puisqu’elles ne dépendent plus d’une API explicite pour s’échanger des données (JMS, RMI, SOAP…) : celles-ci peuvent être consultées et modifiées de manière transparente, comme si elles étaient disponibles localement. Ensuite, il n’y a plus besoin de répliquer préventivement les données : elles sont sécurisées au sein du NAM, et seront transmises, à la demande et de manière optimisée, aux seules applications devant y accéder. Enfin, ce système autorise la manipulation de structures qui seraient habituellement trop larges pour tenir dans la mémoire locale des applications : les informations nécessaires sont fournies en temps réel par le NAM.
Techniquement, Terracotta est composé de deux éléments :
- Un serveur indépendant chargé de la gestion de la mémoire partagée. Afin de garantir une reprise sur incident immédiate, toutes les données sont sécurisées de manière asynchrone dans une base de données interne (BerkeleyDB), et le serveur lui-même peut être mis en redondance active ou passive.
- Un « bootClassLoader » spécial qui instrumente la JVM des applications clientes et assure la liaison avec le serveur Terracotta. Un fichier de configuration « tc-config.xml » permet alors de définir quels graphes d’objets doivent être déployés sur le NAM (il est également possible d’utiliser des annotations).
La clusterisation est donc fournie comme un simple service d’infrastructure, qui ne nécessite aucune modification du code (d’ailleurs, vous ne verrez aucun extrait de code Java dans cet article) et aucun apprentissage particulier de la part des développeurs.
L’instrumentation de la JVM et des classes partagées autorise de nombreuses optimisations. Par exemple, contrairement au mécanisme de sérialisation qui transmet des objets complets, Terracotta travaille à un niveau plus fin et ne transmet que des différentiels, de manière compressée et par batches. Les applications instrumentées peuvent également être monitorées par la console d’administration de Terracotta, afin de suivre en temps réel l’état du cluster, le volume des données échangées, repérer les « deadlocks » distribués, etc.
Pour finir, Terracotta propose des modules d’intégration (TIM, Terracotta Integration Module), qui fournissent toute la configuration nécessaire pour s’intégrer aux principaux frameworks d’entreprise : Spring, Hibernate, EHCache, Struts…
Actuellement, Terracotta est déployé avec succès chez des grands comptes de la finance et des services (WalMart, Comcast, JPMorgan, Pearson…).
A demain pour les cas concrets d’utilisation.
