Apache Ignite Zero Deployment : vraiment Zero ?

Nous sommes le département de développement technologique du réseau de vente au détail. Un jour, la direction a fixé l'objectif d'accélérer le calcul volumique en utilisant Apache Ignite en conjonction avec MSSQL, et a montré un site avec de superbes illustrations et des exemples de code Java. Le site m'a immédiatement plu. Zero Deployment, dont la description promet des merveilles : vous n'avez pas besoin de déployer manuellement votre code Java ou Scala sur chaque nœud de la grille et de le redéployer chaque fois qu'il change. En cours de route, il s'est avéré que le Zero Deployment a des spécificités d'utilisation, dont j'aimerais partager les particularités. Sous le cut, réflexions et détails de mise en œuvre.

1. Formulation du problème

L'essence du problème est la suivante. Il existe un référentiel de points de vente SalesPoint et un référentiel de produits Sku (Stock Keeping Unit). Un point de vente a un attribut « typeMagasin » avec des valeurs « petit » et « grand ». Pour chaque point de vente, un assortiment (liste de produits du point de vente) est connecté (chargé depuis la base de données) et des informations sont fournies sur le fait qu'à partir de la date spécifiée, le produit spécifié
est exclu de l'assortiment ou est ajouté à l'assortiment.

Il est nécessaire d'organiser un cache partitionné des points de vente et d'y stocker des informations sur les produits connectés un mois à l'avance. La compatibilité avec le système de production exige du nœud client Ignite qu'il charge les données, qu'il calcule un agrégat du type (typeMagasin, codeProduit, jour, nombre_de_points_de_vente) et qu'il les exporte de nouveau dans la base de données.

2. Étude de la littérature

Je n'ai pas encore d'expérience, donc je commence par les bases. C'est-à-dire par un aperçu des publications.

L'article de 2016 Introduction à Apache Ignite : premiers pas contient un lien vers la documentation du projet Apache Ignite et un reproche concernant l'ambiguïté de cette documentation. Je l'ai relu plusieurs fois, la clarté n'est pas au rendez-vous. Je me tourne vers le tutoriel officiel getting-started, qui
qui promet de manière optimiste « Vous serez opérationnel en un rien de temps ! ». J'examine les paramètres des variables d'environnement, je regarde deux vidéos sur Apache Ignite Essentials, qui se sont révélées peu utiles pour mon problème spécifique. Je réussis à lancer Ignite depuis la ligne de commande avec le fichier standard « example-ignite.xml », et à créer ma première application. Application de calcul à l'aide de Maven. L'application fonctionne et utilise Zero Deployment, quelle beauté !

Je lis davantage, et là, l'exemple utilise tout de suite affinityKey (créé précédemment via une requête SQL), et en plus, il applique un mystérieux BinaryObject :

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

J'ai lu hors des paramètres de sécurité.: format binaire — quelque chose comme la réflexion, accès aux champs d'objet par nom. Peut lire la valeur d'un champ sans désérialiser complètement l'objet (économie de mémoire). Mais pourquoi BinaryObject est-il utilisé à la place de Person, surtout avec Zero Deployment ? Pourquoi IgniteCache<Key,Person> se traduit-il par IgniteCache<BinaryObject, BinaryObject> ? Pas encore clair.

Je réadapte l'application Compute à mon cas. La clé primaire du répertoire des points de vente dans MSSQL est définie comme [id] [int] NOT NULL, je crée le cache par analogie.

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

Dans le fichier de configuration XML, j'indique que le cache est partitionné.

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache" />
    <property name="cacheMode" value="PARTITIONED" />
< /bean>

La partition par points de vente suppose que l'agrégat requis sera construit sur chaque nœud du cluster pour les enregistrements existants dans salesPointCache, après quoi le nœud client effectuera une somme finale.

Je lis le tutoriel. Première application Ignite Compute., je fais par analogie. Sur chaque nœud du cluster, je lance IgniteRunnable(), à peu près comme ça :

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

J'ajoute la logique d'agrégation et d'exportation, je fais un test sur un ensemble de données. Tout fonctionne localement sur le serveur de développement.

Je lance deux serveurs de test CentOs, j'indique les adresses IP dans default-config.xml, j'exécute sur chacun.

. /bin/ignite.sh config/default-config.xml

Les deux nœuds Ignite se lancent et se voient. J'indique les adresses nécessaires dans le fichier de configuration XML de l'application cliente, elle se lance, ajoute un troisième nœud à la topologie et les nœuds retombent immédiatement à deux. Le journal indique «ClassNotFoundException: model.SalesPoint» à la ligne

SalesPoint sp=salesPointCache.get(spId);

StackOverflow dit que la raison de l'erreur est que la classe utilisateur SalesPoint n'est pas présente sur les serveurs CentOs. Ça, c'est dommage. Comment cela se fait-il que «you don’t have to manually deploy your Java code on each node» et ainsi de suite ? Ou «your Java code» ne concerne-t-il pas SalesPoint ?

Je pense que j'ai probablement manqué quelque chose — je recommence à chercher, lire et à chercher encore. Avec le temps, j'ai l'impression d'avoir lu tout ce qui concerne le sujet, rien de nouveau n'est disponible. En cherchant, j'ai trouvé plusieurs remarques intéressantes.

Valentin Kulichenko, Architecte principal chez GridGain Systems, réponse sur StackOverflow, avril 2016 :

Les classes modèle ne sont pas déployées par paire, mais vous pouvez utiliser le drapeau withKeepBinary() sur le cache et interroger les BinaryObjects. De cette façon, vous éviterez la désérialisation du côté serveur et n'obtiendrez pas de ClassNotFoundException.

Une autre opinion authoritative : Denis Magda, Directeur de la gestion produit, GridGain Systems.

Article sur Habr sur les microservices fait référence à trois articles de Denis Magda : Microservices Partie I, Microservices Partie II, Microservices Partie III 2016-2017. Dans le deuxième article, Denis propose de démarrer un nœud de cluster via MaintenanceServiceNodeStartup.jar. Il est également possible d'utiliser un démarrage avec une configuration xml et une ligne de commande, mais dans ce cas, il faut placer manuellement les classes utilisateur sur chaque nœud de cluster déployé :

Voilà. Démarrez (..) le nœud en utilisant le fichier MaintenanceServiceNodeStartup ou passez le fichier maintenance-service-node-config.xml aux scripts ignite.sh/bat d'Apache Ignite. Si vous préférez cette dernière option, assurez-vous de construire un fichier jar contenant toutes les classes des répertoires java/app/common et java/services/maintenance. Le jar doit être ajouté au classpath de chaque nœud où le service pourrait être déployé.

En effet, c'est ça. Voilà donc pourquoi ce format binaire mystérieux existe !

3. SingleJar

Denis a pris la première place dans mon classement personnel, c'est de loin le tutoriel le plus utile parmi tous ceux disponibles. Dans son MicroServicesExample sur GitHub, se trouve un exemple entièrement prêt à configurer des nœuds de cluster, qui se compile sans avoir besoin d'ajouts supplémentaires.

Je fais à l'image et à la ressemblance et j'obtiens un seul fichier jar qui lance un « data node » ou un « client node » selon l'argument de la ligne de commande. La construction démarre et fonctionne. Zero Deployment est vaincu.

Le passage de mégaoctets de données de test à des dizaines de gigaoctets de sessions réelles a montré que le format binaire existe pour une raison. Il a fallu optimiser la consommation de mémoire sur les nœuds et c'est là que BinaryObject s'est avéré très utile.

4. Conclusions

La première critique rencontrée concernant l'incompréhension de la documentation du projet Apache Ignite s'est révélée juste, depuis 2016, peu de choses ont changé. Il n'est pas facile pour un débutant de créer un prototype fonctionnel à partir du site et/ou du dépôt.

Au terme du travail accompli, j'ai eu l'impression que Zero Deployment fonctionne, mais seulement au niveau système. À peu près ainsi : BinaryObject est utilisé pour instruire les nœuds distants du cluster à travailler avec des classes utilisateur ; Zero Deployment est un mécanisme interne
d'Apache Ignite lui-même et distribue des objets système dans tout le cluster.

J'espère que mon expérience sera utile aux nouveaux utilisateurs d'Apache Ignite.

Source : habr.com