La roadmap d'OpenSearch sous l'ère Fondation Linux

La Fondation Linux, une suite logique pour OpenSearch ?

Le projet vient de franchir ce cap. AWS, son instigateur et principal porteur, veut y voir la concrétisation d'une démarche d'ouverture progressive. Il l'illustre, d'une part, en chiffres (42 % des dépôts GitHub ont aujourd'hui au moins un gestionnaire ne travaillant pas pour Amazon, par exemple). De l'autre, en rappelant quelques étapes traversées depuis les débuts d'OpenSearch en 2021. Parmi elles :

• Création, en septembre 2022, d'un processus communautaire pour la gestion des problèmes de sécurité
• Lancement, en avril 2023, d'un espace de travail Slack public
• Ouverture, en mai 2023, du process de release à des contributeurs hors AWS
• Constitution, en décembre 2023, d'un "comité directeur"

Ce comité se compose notamment de gestionnaires et de propriétaires de dépôts, d'ingénieurs et d'employés d'entreprises utilisant OpenSearch. Il a recommandé de confier le projet à la Fondation Linux. Une démarche qui avait démarré en avril 2024... et qu'AWS dans laquelle AWS perçoit un levier d'attraction de nouveaux contributeurs.

Parallèlement à cette transition, OpenSearch communiqué une roadmap exhaustive pour 2024-2025.

Sur la partie base de données vectorielle et GenAI

Pour améliorer le rapport prix/performance, OpenSearch entend introduire une solution ANN (approximate nearest neighbor) utilisant des vecteurs quantisés. Il promet une compression jusqu'à 32 x et des coûts réduits de 70 %.

Il est aussi question d'utiliser les GPU pour accélérer la construction des usages k-NN (promesse : un ratio prix/performance 10 à 40 fois meilleur que sur CPU). Et de mettre en place un routage "intelligent" pour augmenter le débit des requêtes en organisant les index par similitude sémantique.

Face au volume d'outils et d'algorithmes, une fonctionnalité AutoTune recommandera les valeurs d'hyperparamètres optimales pour un workload donné. S'y ajoutera un concepteur low code de flux de recherche au sein des dashboards.

Sur la partie recherche

Le projet cherche a intégrer les capacités du plug-in SQL directement dans OpenSearch. Objectif : unifier la planification et l'exécution des requêtes entre langages.

Pour améliorer les performances sur la requête de plage, des techniques d'approximation seront mises en place. On nous parle aussi d'une accélération des agrégations de type histogrammes de dates, d'une optimisation de la recherche concurrente de segments et du développement d'un cache de requêtes multiniveaux.

En complément à l'ingestion depuis DynamoDB et DocumentDB avec Data Prepper, le support des bases SQL est sur la roadmap.

Sur l'expérience utilisateur

Au niveau des dashboards, OpenSearch veut introduire un concept de "dataset". Celui-ci étendrait les patterns d'index pour permettre de travailler avec des sources de type bases relationnelles et Prometheus. Autre concept à venir : les workspaces, qui donneront accès à des expériences "verticales" pour la recherche, l'observabilité et les analyses de sécurité.

Le projet cherche par ailleurs à découpler les dashboards du moteur afin qu'ils fonctionnent comme des applications autonomes indépendantes de l'installation d'OpenSearch. Ils auront leur propre authentification et leur propre contrôle d'accès basé sur des workspaces. La gestion des plug-in sera en outre fluidifiée pour permettre d'étendre les dashboards sans avoir à la relancer. On nous promet aussi un assistant GenAI et un outil d'aide à la migration depuis d'anciennes versions des dashboards.

Sur l'observabilité et l'analytics

D'ici à fin 2024, OpenSearch devrait avoir consolidé SQL et PPL sur une interface commune au sein de Discover, avec saisie et suggestions automatiques. À l'horizon 2025, une trentaine de fonctions et de commandes PPL devraient faire leur entrée. Et le moteur SQL, prendre en charge la recherche géographique.

Pour automatiser l'identification des problèmes, OpenSearch prépare un framework reposant sur des "zones de corrélation". Il promet aussi d'améliorer l'UI du plug-in d'analyse de traces tout en l'intégrant avec d'autres modules d'extension. Les dashboards supporteront par ailleurs PromQL pour des requêtes directes sur des sources Prometheus.

La liste des sources prises en charge par Data Prepper devrait s'allonger pour inclure notamment Amazon Kinesis et les API OpenSearch. Au niveau des analyses de sécurité, il y aura des intégrations avec ServiceNow et PagreDuty. Ainsi que de la GenAI pour configurer la détection et accompagner la remédiation.

Sur la capacité de montée en charge

Il est question de réarchitecturer OpenSearch en séparant indexation et recherche. Pour des interconnexions plus rapides, le projet utilisera un format binaire pour la communication client-serveur. Pour les messages entre noeuds, il a mené des tests concluants avec Protobuf.

Actuellement sur un modèle push, l'ingestion des événements depuis des flux externes va passer sur un mode pull. Cela permettra de mieux gérer les pics de charge, tout en supprimant le besoin du translog sur les noeuds d'indexation.

Pour ce qui est des API d'administration, elles vont s'enrichir de fonctionnalités de pagination et d'annulation. OpenSearch prépare aussi des optimisations sur les API Stats et Cluster pour éliminer les traitements redondants.

Sur la disponibilité et la sécurité

OpenSearch entend donner, au niveau des coordinateurs, une visibilité plus fine sur les différentes phases d'exécution des requêtes. Il compte aussi fournir aux admins des clusters des garanties de performances basées sur les locataires. Et permettre la publication distante de l'état des clusters (en l'état, c'est le noeud de gestion qui assure la distribution).

Data Prepper pourra quant à lui envoyer de façon plus flexible les données vers une file d'attente de lettres mortes. En l'état, il ne le fait que si l'écriture finale échoue. L'idée est de pouvoir déclencher cet envoi en cas d'autres problèmes, par exemple pendant le traitement.

Pour l'isolation des plug-in, OpenSearch s'oriente vers un modèle zero trust. Dans le plug-in de sécurité, il a identifié des pistes d'amélioration, notamment pour les clusters regroupant beaucoup d'index ou de rôles associés à des utilisateurs.

Vers une architecture modulaire

À l'heure actuelle, le coeur du projet reste monolithique. Une solution pas idéale pour la nouvelle génération du moteur de requête. Ni pour le substitut recommandé à Java Security Manager, qui sera bientôt retiré du runtime. Dans ce contexte, OpenSearch entend aller vers une architecture orientée services.

Illustration