Site icon Blog Zenika

Devenir un service d’indexation et de recherche à la demande au sein de son S.I.

  • Tony Blanchard

    • Le passage d’une utilisation à la demande du célèbre moteur de recherche Elasticsearch à une utilisation industrielle, par de nombreux clients diversifiés, au sein d’un même S.I., demande quelques adaptations qui ne sont pas toujours évidentes à imaginer ou à comprendre sans entrer dans des considérations d’architecture, de contrat de service, de sécurité et d’urbanisation.

    Pour mieux comprendre les enjeux d’une plateforme de service à la demande et les adaptations nécessaires par rapport à une approche classique, cet article vous propose de faire un état des lieux de deux cas d’usage habituels avant d’en étudier les avantages et inconvénients:

    Une fois ces avantages et inconvénients connus, il sera alors possible de réfléchir aux moyens à mettre en oeuvre pour conserver une gouvernance sérieuse et efficace de notre S.I malgré une montée en nombre des clients ainsi que des contraintes induites…
    Une proposition d’architecture servira à expliciter les adaptations et concessions nécessaires à une utilisation comme plateforme centralisée au sein du S.I

    Cas d’utilisation standard

    Usages métier

    En production, un cluster Elasticsearch utilisé pour indexer ou rechercher des documents métiers est souvent organisé selon le schéma suivant.
    Pour chaque application utilisatrice:

    1. Un pool de connexions HTTPs/TCPs selon utilisation de clients REST/Json ou bien du protocole “Transport” d’Elasticsearch
    2. Un truststore valide pour initialiser ces connexions sécurisées vers le cluster protégé par SearchGuard, Shield ou X-Pack…
    3. Du code pour les requêtes de recherche et d’indexation
    4. Des transactions ou transactions globales[1] pour les indexations et autres écritures de données
    5. Des paramètres pour indiquer la liste des noeuds Elasticsearch à contacter
    6. Des paramètres pour indiquer la liste des alias d’index à utiliser pour le métier considéré
    7. Du code d’initialisation des mappings pour le métier considéré
    8. Des paramètres pour les identifiants/mot de passe de l’utilisateur applicatif du cluster Elasticsearch si protégé par searchGuard, Shield ou X-Pack…
    9. Une route réseau ouverte entre le serveur d’application et les noeuds du cluster
    Les avantages de cette solution
    Les désavantages potentiels de cette solution

    Les désavantages d’une augmentation du nombre de clients

    Usage des brokers et d’Elastic Stack pour centralisation de logs

    En production, la suite Elastic Stack est souvent accommodée d’une ou plusieurs instances de brokers.

    Voici une architecture habituelle de centralisation des journaux applicatifs
    Les brokers comme Kafka, RabbitMQ ou autres sont des composants utilisés de manière assez habituelle dans une infrastructure Elastic Stack de centralisation des logs.
    Ces composants, selon leurs paramètres, peuvent amener de nombreux avantages architecturaux:

    Les composants comme Logstash sont sans état et permettent donc une mise à l’échelle horizontale et une consolidation/transformation des logs avant envoi vers le cluster Elasticsearch.

    Les avantages de cette solution
    Les désavantages potentiels de cette solution

    *Transaction globale: Une transaction globale est un mécanisme qui permet à plusieurs routines de programmation, qui peuvent être mises en jeu par un ou plusieurs serveurs, de s’exécuter pour fournir une seule fonctionnalité logique persistante.

    Devenir plateforme de recherche et d’indexation à la demande dans tout ça ?!

    Comme nous l’avons vu, le mode d’utilisation en mode logs présente beaucoup plus d’avantages que l’utilisation business recherches + indexations métier.
    Par ordre d’importance, je dirai que les avantages sont:

    Or, qu’est-ce qui fait que les documents métiers ne puissent être utilisés avec cette architecture brokers + Elastic Stack ?
    En fait, avec l’expérience, on s’aperçoit que les éléments importants qui empêchent l’utilisation de la stack Elastic pour des documents métiers sont les usages nécessitant des activités de type CRUD ( créations, mises à jour et destruction de documents métiers identifiés de manière unique ):

    De même,l’expérience aidant, on s’aperçoit également qu’il peut y avoir des usages métiers se rapprochant des logs par leur construction:

    Exemple de logs métiers exploitables sans CRUD
    10/12/2017 INFO Main client=CLIENT-3302202203, action=achat, produit=REF-032203203, totalHT=20€, totalTTC=22€, mode_paiement=CB
    Dès lors, nous pouvons dresser un premier bilan sur la mise en place d’un centre de service d’indexation et de recherche au sein de son S.I.:

    Proposition d’architecture pour adapter le mode broker + Elastic Satck aux usages du CRUDs

    Tout d’abord, nous comprenons assez rapidement que les requêtes d’interrogation métier seront inévitablement effectuées en direct sur le cluster Elasticsearch car elles serviront à générer des comportements applicatifs et/ou des interfaces homme-machines sur mesure.
    Cette partie ne peut donc être améliorée…
    Par contre, qu’en est-il des indexations / mises à jour ou destructions de documents?
    Nous l’avons vu, les principaux problèmes de ce mode d’utilisation sont:

    Mais est-ce vraiment une limitation réelle ?
    Non.
    Heureusement, si la perte du mode synchrone peut être problématique dans certains cas,elle n’est pas rédhibitoire et Logstash est bien capable de parser des objets complexes pour les mettre à jour ou les détruire dans Elasticsearch à la condition que l’application émettrice fournisse quelques informations supplémentaires obligatoires dans le message transmis:

    Présentation de la solution d’optimisation avec ses concessions

    La solution consiste à faire passer toutes les actions d’écriture CRUD ou non par un Broker puis par la plateforme Elastic Stack. Ceci apporte bien entendu des contraintes qu’il faut alors prendre en compte…

    Au niveau des applications

    Les documents à traiter (lors d’une création, mise à jour ou destruction) doivent obligatoirement contenir leur identifiant métier ainsi que l’action à effectuer pour que Logstash sache quoi en faire.
    Le type d’un document pouvant être déterminé selon sa provenance, voir section logstash pour le mode de récupération de cette information, l’application n’est pas obligée de traiter ce point dès l’émission, c’est le choix du canal d’envoi qui permettra de transmettre l’information obligatoire à Logstash
    Attention, pour rappel, l’utilisation d’un broker comme tampon induit les conséquences suivantes :

    Pour limiter ces problématiques sans complexifier outrageusement code et conception, voici quelques exemples de règles de développement de code métier possibles.

    Cas de données sensibles pour l’exécution du processus métier

    Nb: Si documents à forme changeante, stocker un blob

    Dans tous les cas

    Cas de données complexes

    De manière générale, émettre des documents au format json n’a aucun intérêt si l’on passe par Logstash et non directement par Elasticsearch. En effet, Logstash devra de toute manière parser le json pour pouvoir le manipuler(préemption du CPU Logstash).De plus, le  format json prend beaucoup de place avec le rappel des noms des champs pour chaque valeur (Préemption de disque et de bande passante du LAN)…
    Aussi, on préfèrera en général émettre au format texte en raccourcissant les dates (epoch time in millis) + UTC et en utilisant un séparateur de champ ‘rare‘ (Ex: ‘|’) pour distinguer les différents champs du document
    Mais ceci ne suffit pas s’il est nécessaire  de construire des champs complexes avec des sous-objets ou des tableaux de sous-objets.
    Ex: Les livres suivants peuvent être difficiles à dénormaliser au format texte avec de simples séparateurs de champs…

    {
“titre”: “Livre 1”,
“auteurs”: [ { “nom”: “NomAuteur1”, “prenom” : “PrenomAuteur1 },
 { “nom”: “NomAuteur2”, “prenom” : “PrenomAuteur2 }]
}
ou
{
“titre”: “Livre 3”,
“auteurs”: [ “Prenom1 NomAuteur1”,  “Prenom2 NomAuteur2” ]
}

    Le cas des tableaux simples peut être résolu en utilisant des “filtres” Logstash comme:

    Pour les sous-objets ou tableaux de sous-objets, il est recommandé d’utiliser le filtre json capable de récupérer un objet json à partir du texte situé dans le champ spécifié par l’option ‘source’ du filtre.
    Ex:

    1472800657644|th1|I|Utilisateur 1|Service gestion du panier|{"panier":
[{"livre":{"titre":"Angular", "auteurs":[“Daniel Djordjevic”, “William Klein”, “Sébastien
Ollivier”]}, {"livre":{"titre":"Qt5", "auteurs":“Tristan Israel”}]|suite du message textuel
...
    Au niveau de Logstash
    Inputs des brokers

    Les inputs des brokers peuvent nous donner des indices sur le type de document à traiter.
    Les inputs permettent de récupérer cette information, soit en ayant un input exclusif par type de document, soit en récupérant des données supplémentaires fournies par l’input lui-même:

    Pour le cas de Kafka par exemple l’input peut indiquer le topic du document et positionner en conséquence la valeur de la métadonnée Logstash suivante:

     [@metadata][kafka][topic]

    Cette donnée pourra être utilisée dans l’output Elasticsearch sans forcément la stocker dans le document.

    Output Elasticsearch

    La récupération de l’identifiant du document et de l’action à effectuer n’a rien de complexe. Il suffit de récupérer ces valeurs dans le document parsé, puisque les applicatifs les ont fournis, et de les utiliser comme paramètres de l’output Elasticsearch
    Pour cela, positionner les paramètres suivants à la valeur adéquate dans l’output Elasticsearch:

    Rappel: Il est possible d’ajouter une politique de rotation des index via l’option index de l’output Elasticsearch. Ex: ‘monMetier-%{+YYYY.MM.dd}’

    Au niveau d’Elasticsearch

    De manière habituelle, un template d’index est utilisé par les indexations Logstash.
    Comme les documents métiers peuvent être beaucoup plus complexes, il est nécessaire de définir un template d’index explicite pour chaque document, via l’API dédiée, pour y définir un mapping qui réponde spécifiquement aux besoins des recherches applicatives.

    Conclusion

    Nous avons vu dans cet article tous les avantages qu’offre l’approche de l’indexation à la manière de logs, via la suite Elastic Stack, pour une plateforme de service d’indexation et de recherche à la demande face à des clients multiples et en nombre croissant au sein du S.I.
    En résumé:

    L’approche par logs amène bien sûr des avantages et inconvénients qu’il faudra bien expliciter aux clients potentiels de la plateforme. Bien qu’il existera toujours quelques applications qui ne peuvent s’accommoder des contraintes vues ici, la plupart d’entre elles devraient fonctionner dans le mode proposé et ainsi profiter au S.I dans son ensemble.
    Pour aller plus loin dans les avantages de la solution me direz-vous ?
    Et si les brokers devenaient une sorte d’ESB ?

    Auteur/Autrice

    Quitter la version mobile