Grid Computing avec Hazelcast, Apache Ignite et Kubernetes ... Aventure avec les Paradise Papers

Hazelcast est une grille de données en mémoire open source basée sur Java. Dans une grille Hazelcast, les données sont réparties uniformément entre les nœuds d'un cluster, ce qui permet une mise à l'échelle horizontale du traitement et du stockage disponible. Les sauvegardes sont également distribuées entre les nœuds afin de les protéger contre les défaillances d'un seul nœud. Hazelcast fournit une mise à l'échelle centralisée et prévisible des applications grâce à un accès en mémoire aux données fréquemment utilisées et à une grille de données évolutive et élastique.

Hazelcast peut fonctionner sur site, dans le cloud (Amazon Web Services, Microsoft Azure, Cloud Foundry, OpenShift), virtuellement (VMware) et dans des conteneurs Docker. Hazelcast propose des intégrations technologiques pour de multiples technologies de configuration et de déploiement des nuages, notamment Apache jclouds, Consul, etcd, Eureka, Kubernetes et Zookeeper. L'interface SPI (Shutelcast Cloud Discovery Service Provider Interface) permet aux nœuds basés sur le cloud ou sur site de se découvrir automatiquement.

Application à un cluster managé dans Azure avec AKS : lancement d'un cluster =>

J'en profite pour upgrader mon cluster k8s à la version 1.8.2 qui m'est proposée :

Le cluster k8s managé dans Azure est disponible :

Je lance le déploiement de mon cluster Hazelcast dans k8s :

avec les logs qui me donnent l'état d'un noeud de cette grille :

En scalant à seulement deux réplicas, je peux visualiser l'état de ma grille Hazelcast dans la console de management (accessible via l'Ingress Controller du cluster k8s) :

Le grand rival d'Hazelcast est Apache Ignite poussée par la société Gridgain et on peut déployer une grille dans k8s également :

Je visualise l'ensemble dans le dashboard k8s :

Hazelcast se retrouve naturellement dans les clusters Payara Micro que l'on avait vu dans les clusters Jelastic via des containers Docker :

Le monitoring de l'ensemble est réalisé via Azure OMS :

PS: Je termine par cette expérience amusante autour des Paradise Papers (en corollaire aux fuites des Panama Papers) et de la base NoSQL orientée Graphes : Neo4j ! En effet, cette dernière est devenue avec Linkorious, l'un des outils preferés pour analyser cette immense réservoir constitué avec cette fuite de données.

Or, l'équipe de Neo4J a mis à disposition une image Docker d'un serveur Neo4j avec les données embarquées comme le précise ce Dockerfile :

FROM neo4j:3.3.0
MAINTAINER Ryan Boyd, <ryan@neo4j.com>
RUN apk update
RUN apk add --quiet openssl sed wget unzip
RUN cd /var/lib/neo4j/plugins/; wget "https://github.com/neo4j-contrib/neo4j-apoc-procedures/releases/download/3.3.0.1/apoc-3.3.0.1-all.jar"
RUN cd /var/lib/neo4j/plugins/; wget "https://github.com/neo4j-contrib/neo4j-graph-algorithms/releases/download/3.3.0.0/graph-algorithms-algo-3.3.0.0.jar"
COPY download_db.sh /download_db.sh
COPY configure.cql /configure.cql
ENV EXTENSION_SCRIPT /download_db.sh
ENV NEO4J_AUTH=none

Je lance une instance dans Outscale :

avec cette image Docker :

et je peux lancer des requêtes en CQL (Cypher Query Language) même si avec Apache TinkerPop on est sensé utilisé Gremlin (DSL pour les graphes) :

Exemple de requête : Le Duché de Lancaster - la propriété privée et le portefeuille de la reine Elisabeth II - apparaît dans l'ensemble des données Paradise Papers. Un investissement de plusieurs millions de dollars a été fait dans une entité caïmanaise, Dover Street VI Cayman Fund par le Duché. Bien que la succession de la Reine fasse régulièrement état de certains placements et avoirs intérieurs, il n' y avait pas encore eu de placements étrangers, y compris le placement du Fonds Dover Street VI Cayman.

On peut écrire une requête de Cypher pour toutes les connexions à deux degrés vers le Duché:

et on peut développer les relations entre ces différents noeuds :

Une caractéristique puissante d'une base de données orientéé graphes comme Neo4j est la possibilité d'interroger des chemins de longueur arbitraire. Cela permet de trouver des connexions entre les nœuds lorsque nous ne savons pas quelles sont les connexions, ni même la longueur du chemin. Dès lors on peut vérifier si des liens indirects entre deux personnalités publiques figurent dans l'ensemble de données du Paradise Papers: par exemple Rex Tillerson, le secrétaire d'État américain qui avait des liens avec une société pétrolière et gazière établie aux Bermudes ayant des activités au Yémen, et la reine d'Angleterre, dont la propriété, selon les informations reçues, se matérialiserait sous la forme d'un investissement dans une société établie aux Bermudes. On peut donc rechercher le chemin le plus court entre la Reine d'Angleterre et Rex Tillerson :

Ceci montre un seul chemin le plus court reliant la Reine d'Angleterre à Rex Tillerson. Le chemin passe par plusieurs entités offshore et des officiers avec des connexions à ces entités. Si on ajuste légèrement la requête pour y inclure tous les chemins les plus courts, on constate que plusieurs des agents de notre chemin partagent des liens avec de nombreuses entités juridiques. Une recherche rapide sur Google révèle que ces personnes sont des gestionnaires de services corporatifs: des personnes qui sont rémunérées pour agir à titre de directeurs d'entités offshore pour gérer l'administration de ces entités.

Vous pouvez continuer l'enquête, la source de données étant immense à dépouiller ! ...