Elastic Search : quelle architecture pour être optimal ?

Avec une consommation sans cesse grandissante de données, maîtriser un outil de recherche, de gestion et d’analyse de base de données comme Elastic Search est un véritable atout.

Ses fonctionnalités pertinentes font de lui un moteur de recherche souple et efficace offrant d’ailleurs de nombreuses possibilités. 

Pour profiter de ses atouts, vous devez identifier l’architecture qui convient le mieux aux variables de votre projet. C’est la première étape, et sûrement la plus décisive. Découvrez dans cet article les différents types d’architecture Elastic Search.

Comment est mise en place une architecture Elastic Search ?

La mise en place de l’architecture Elastic Search suit une procédure bien définie. Découvrez les détails de cette procédure ainsi que les notions techniques qui y sont associées.

La couche d’application

Elastic Search propose une variété d’interfaces de recherche aux utilisateurs. Elles comprennent toutes les opérations CURD, la création et la suppression d’index.

Les utilisateurs ont la possibilité d’interagir avec le cluster Elastic Search via l’interface RESTful ou l’API Java. Sur les anciennes versions d’Elastic Search, on retrouve la version TransportClient de cette API, tandis que les versions plus récentes intègrent Java High Level REST Client.

Les protocoles de couche

Les protocoles de couche sont des protocoles de communication utilisés par les périphériques pour transférer les données dans un réseau étendu, ou entre un nœud et un autre dans un réseau local.

Thrift 

Thrift est un langage de définition d’interfaces conçu pour la création et la définition de services pour de nombreux langages de programmation comme Java, Python ou PHP. 

Il permet aux utilisateurs de sélectionner le type de protocole de transmission entre le client et le serveur. Selon les besoins en présence, il peut s’agir d’un protocole de transmission de type texte ou de type binaire.

Memcached

Memcached est un système de mise en cache de stockage d’objet à mémoire distribuée, gratuit et en open source. Il est basé sur des lignes de textes qui permettent aux applications web de charger rapidement du contenu et réduisent la charge des bases de données.

La persistance des données n’est pas prise en charge parce que les données sont interrogées fréquemment, ce qui entraîne plus de lecture et moins d’écriture. Toutes les données sont perdues après la fermeture du serveur.

Memcached convient pour les scénarios de commerce électronique et est idéal pour un développement rapide.

HTTP

L’API est fournie de manière externe sous la forme du protocole HTTP et du protocole RESTful au format JSON.

TCP

TCP est un protocole orienté connexion ; il permet à deux machines de contrôler l’état de la transmission. Son protocole de communication sous-jacent est Netty (un cadre d’E/S asynchrone à haute performance).

Elastic Search insère lui-même l’implémentation de Netty dans son propre système sous la forme de plug-ins. La couche inférieure utilise kqueue ou epoll pour réaliser un multiplexage élevé des E/S et exploite la technologie de tampon sans copie pour améliorer l’efficacité de l’unité centrale.

Crédit de l’image : Netty

Extensions de gestion Java (JMX)

Les extensions de gestion Java forment un framework de service ajouté depuis la version J2SE 5.0., capable d’intégrer des fonctions de gestion pour les applications, les appareils, les systèmes, etc.

Ce framework peut gérer dynamiquement les ressources durant leur exécution et obtenir dynamiquement l’état de l’application.

De même, il peut développer avec flexibilité des applications de gestion de système, de réseau et de service intégrées de manière transparente sur une série de plateformes de systèmes d’exploitation hétérogènes, d’architectures de système et de protocoles de transmission de réseau.

Crédit de l’image : Wikipedia

La couche de découverte/scripting

Il s’agit d’un protocole de couche qui permet d’identifier tous les appareils connectés à un même réseau informatique.

ZenDiscovery

ZenDiscovery est un mécanisme de découverte intégré spécial d’Elastic Search dont l’objectif est de découvrir les nœuds du cluster et d’identifier le nœud maître. Il propose deux méthodes de découverte :

• La méthode Unicast : un nœud envoie une requête à un serveur lorsqu’il rejoint un cluster existant ou constitue un nouveau cluster. Tout nœud échangeant par monodiffusion obtient l’état de tous les nœuds de la grappe, communique avec le nœud maître et rejoint la grappe ;
• La méthode Multidiffusion : un nœud peut envoyer des demandes à plusieurs serveurs. Cette approche n’est toutefois pas efficace dans un environnement de production à grande échelle car elle génère un grand nombre de communications inutiles.

Script

Ce protocole est utilisé pour résoudre des scénarios commerciaux complexes. Cela dit, il est rarement utilisé dans un environnement de production réel car ses performances y sont faibles. Dans les scénarios d’entreprise non complexes, les opérations de base peuvent être effectuées sans script.

La couche de traitement des données

Nous nous intéressons ici à la couche de protocole d’Elastic Search s’occupant du traitement des données stockées et de leur exploitation.

Module d’indexation

Il s’agit d’un module créé par un index qui s’occupe de tous les aspects liés à cet index précis. Ce module peut prendre deux formes : statique et dynamique.

• Statique : il est spécifié au moment de la création et ne peut pas être modifié ;
• Dynamique : il peut être modifié en mettant à jour l’API de configuration de l’index.

Module de recherche

Comme son nom l’indique, le module de recherche permet aux utilisateurs d’effectuer une recherche et d’en obtenir les résultats. Il parcourt l’intégralité des segments qui composent chaque index pour trouver les informations désirées. Le délai de réponse est donc plus ou moins important.

L’opération fsync proposée par le module garantit que le segment peut être écrit physiquement sur le disque afin d’éviter toute perte de données. Mais elle prend du temps et ne peut alors pas être exécutée chaque fois qu’une donnée est indexée.

L’indexation et la recherche de données particulières demandent un délai important. Par conséquent, les données nouvellement ajoutées sont stockées dans la zone tampon d’indexation, puis réécrites dans un segment et enfin, directement réécrites dans le cache du système de fichiers.

Tant qu’il est possible d’interroger les données du segment, celles-ci peuvent être trouvées en peu de temps, sans qu’on ait à effectuer une opération de validation complète ou de synchronisation.

Crédit de l’image : Livebook

Processus d’indexation

Au moment de la création d’un index, un document est d’abord stocké dans le shard principal grâce à ses règles de routage. Sa réplique est ensuite créée.

L’ensemble des données de l’index est réparti dans des partitions. Le serveur principal et le serveur de copie conservent une réplique de ces données. Ainsi, en cas de perte, elles pourront être récupérées dans d’autres nœuds. 

Ce processus a toutefois des insuffisances. Pour commencer, il réclame du temps. Ensuite, en attendant la fin de la récupération des données perdues, l’ensemble du système sera dans un état relativement dangereux.

Toutes les données de l’index se trouvent dans les répertoires. Le serveur principal et le serveur de copies conservent une copie. Ainsi, si les données sont perdues, elles peuvent être récupérées dans d’autres nœuds. Encore une fois, le temps est l’inconvénient de ce processus. 

Processus de recherche

Quand une requête de recherche est envoyée à un nœud, il devient le nœud coordinateur. Il diffuse les requêtes de recherche à toutes les unités de stockage concernées et regroupe leurs réponses en un ensemble trié, qui est renvoyé au client.

Crédit de l’image :  Packtpub

Mapping

Il est utilisé pour définir la manière dont un document est mis en correspondance avec le module de recherche, y compris ses caractéristiques de recherche. Le mapping définit comment classer les documents d’un index en groupes logiques.

River

Le river est utilisé pour obtenir des données à partir d’autres sources de données.  Il existe sous la forme de plug-ins et comprend RabbitMQ, ActiveMQ, CSV, FileSystem, JDBC, GitHub, Kafka, etc.

La couche centrale de l’architecture

Encore appelée couche « core », la couche centrale est la partie essentielle d’un réseau évolutif. Celle d’Elastic Search repose sur Lucene.

Apache Lucene est un moteur de recherche open source écrit en Java, considéré comme la bibliothèque de recherche la plus avancée et la plus puissante. Son API est puissant et exige une compréhension approfondie de la part de ses utilisateurs.

La couche de stockage des données

La couche de stockage des données s’articule autour de passerelles définies par les éléments suivants :

• Le système de fichiers local permettant aux applications de stocker et d’extraire des fichiers sur des périphériques de stockage. Les fichiers sont organisés selon une structure hiérarchique ;
• Le Hadoop distribué, qui fournit un accès performant aux données à travers des clusters Hadoop hautement évolutifs ;
• L’Amazon S3 cloud Object Storage : c’est un service de stockage d’objets offrant une évolutivité, une disponibilité des données, une sécurité et des performances de premier ordre.

Les différents types d’architecture Elastic Search

Il existe plusieurs architectures possibles pour déployer Elastic Search, selon des besoins spécifiques de votre application et de l’infrastructure disponible. Voici quelques-unes des architectures les plus courantes.

L’architecture standalone

Dans une architecture de type standalone, Elastic Search est exécuté sur une seule machine, sans être réparti sur plusieurs nœuds ou serveurs. 

Ce procédé est assez efficace et même recommandé pour des applications qui ont une faible charge de requêtes ou pour des cas d’utilisation spécifiques qui ne demandent pas une architecture distribuée.

Pour utiliser Elastic Search en architecture standalone, il faut télécharger l’archive binaire correspondante à votre système d’exploitation et l’extraire sur votre machine. Ensuite, vous pouvez exécuter le moteur en utilisant la commande appropriée.

L’architecture en cluster

Dans une architecture avec cluster, Elastic Search est exécuté sur plusieurs nœuds ou serveurs, qui sont organisés en cluster. Cette architecture distribuée augmente la capacité de traitement des données en répartissant les données et les requêtes sur plusieurs nœuds.

De plus, elle permet d’éviter les points de défaillance unique. En cas de panne, les nœuds sont configurés pour se redécouvrir automatiquement.

Pour mettre en place cette architecture, il faut installer et configurer plusieurs nœuds Elastic Search, puis les associer entre eux pour former un cluster. 

Une fois le cluster créé, les requêtes et les données sont automatiquement réparties sur les nœuds, en fonction des paramètres de réplication et de distribution configurés à l’entame.

L’architecture en cluster avec réplication

L’architecture en cluster avec réplication est concrètement une variante de l’architecture en cluster. 

Son originalité réside dans le fait que les données sont répliquées sur plusieurs nœuds du cluster en utilisant un mécanisme de réplication. Ce dernier sert à copier les données d’un nœud à un autre, de manière asynchrone ou synchrone, selon la configuration choisie.

Il est intéressant de préciser que la réplication garantit un certain niveau de redondance et de disponibilité des données en cas de panne. Ainsi, si un nœud vient à tomber en panne, la deuxième copie de son contenu est utilisée pour rendre les données à nouveau accessibles.

Cette architecture se révèle très efficace pour les applications qui exigent une disponibilité continue des données et une tolérance élevée aux pannes.

L’architecture multi-cluster

L’architecture de type multi-cluster est indiquée pour les applications nécessitant une grande capacité de traitement des données, une haute disponibilité, une bonne tolérance aux pannes ainsi qu’une latence faible sur de grandes distances géographiques.

Ici, plusieurs clusters Elastic Search sont déployés sur des environnements distincts. Ils peuvent être répartis sur plusieurs zones géographiques. Chacun d’entre eux pourra être administré de manière autonome, avec ses propres nœuds, ses propres index et ses propres politiques de rétention.

Selon les besoins de l’entreprise ou du projet, la réplication des données pourra être effectuée de manière synchrone ou asynchrone. 

Cela dit, il faut préciser qu’une telle architecture sera plus complexe à gérer, notamment à cause de la nécessité de gérer plusieurs clusters distincts et de configurer la réplication des données entre les clusters.

L’architecture en mode cloud

L’architecture en mode cloud d’Elastic Search est également une autre variante de l’architecture en cluster. Son fonctionnement repose sur l’utilisation des services cloud proposés par les fournisseurs comme Amazon Web Services (AWS), Microsoft Azure ou Google Cloud Platform (GCP).

Ces fournisseurs proposent aux entreprises des services Elastic Search administrés, qui leur permettent de créer des clusters Elastic Search très rapidement, avec des fonctionnalités de sécurité, de sauvegarde et de récupération intégrées.

Grâce à cette offre complète, les bénéficiaires peuvent déployer facilement Elastic Search en mode cloud, sans avoir à se soucier de l’infrastructure logicielle et matérielle sous-jacente. Les fournisseurs s’assurent d’adapter les clusters à leurs besoins et à l’échelle de leur activité.

Toutefois, si vous souhaitez opter pour une telle alternative, vous devrez considérer les coûts supplémentaires liés aux services cloud et à la bande passante. Ces derniers s’ajoutent aux coûts d’utilisation d’Elastic Search.

Quelle architecture vous convient le mieux ?

Le choix d’une architecture pour Elastic Search dépend de plusieurs critères, tels que la quantité de données que vous souhaitez stocker et indexer, la complexité de vos requêtes de recherche, le nombre d’utilisateurs et les performances attendues.

Il n’y a pas de réponse exacte à cette question. Toutefois, nous pouvons vous donner des directives pour orienter vos choix, en tenant compte des différents types d’architecture que nous avons présenté :

• L’architecture standalone. Elle est idéale pour les projets de petite envergure, ayant des volumes de données limités et des contraintes de disponibilité et de performance peu élevées ;
• L’architecture en cluster. Elle est recommandée pour les projets avec des volumes de données plus importants et qui requièrent une haute disponibilité et une grande résilience ;
• L’architecture en cluster avec réplication. Elle convient pour les entreprises ou les projets qui, en plus de remplir les conditions précédentes, souhaitent utiliser la réplication des données pour garantir la disponibilité des données en cas de défaillance dans leur réseau ;
• L’architecture en multi-cluster. Elle correspond aux entreprises ayant besoin de gérer plusieurs applications, environnements ou sites géographiques ;
• L’architecture en cloud. Elle est faite pour les entreprises ou projets souhaitant bénéficier de la flexibilité, de l’évolutivité et de la disponibilité des services cloud tout en exploitant les fonctionnalités avancées de gestion de clusters Elastic Search. 

Pour être certain de faire un bon choix, il faut d’abord comprendre les besoins spécifiques de votre entreprise et de votre projet. Si vous avez des difficultés à vous décider, pensez à consulter un expert pour vous aider à choisir l’architecture la plus adaptée pour être optimal avec Elastic Search.

Conclusion

Elastic Search est un moteur de recherche et d’analyse distribué qui permet le stockage, la recherche et l’analyse de contenu. Il conserve les données en format JSON et vous permet d’accéder à vos données en un temps record grâce aux fonctionnalités d’indexation de d’Apache Lucene.

Ce moteur de recherche dispose de plusieurs fonctionnalités. Par exemple, il est capable d’effectuer des recherches en full-text, de résoudre des opérations complexes pour les moteurs de recherche traditionnels et propose même des outils d’analyse et de gestion des données de séries temporelles.

L’architecture d’Elastic Search est le socle de son efficacité. Les différentes présentations menées dans cet article ont permis de mettre en évidence les nombreux mécanismes compris dans sa structure. 

Il existe plusieurs types d’architectures Elastic Search. Les plus pertinents sont : l’architecture standalone, l’architecture en cluster, l’architecture en cluster avec réplication, l’architecture en multi-cluster et l’architecture en cloud. 

Pour identifier l’architecture Elastic Search qui vous correspond, nous vous recommandons de prendre en compte les besoins de votre entreprise ou projet.