ElasticON Tour Paris : ce que j'ai appris

Le 14 février 2019, je suis allé à l'ElasticON Tour Paris. Un peu nerveux.

C'était ma première conférence Elastic. J'utilisais ElasticSearch tous les jours comme moteur de recherche, beaucoup moins le reste de la stack, et je craignais de ne pas avoir le bagage technique pour suivre.

Je n'y allais pas pour les annonces produit. J'y allais pour trois questions très concrètes, celles sur lesquelles je butais en configuration : comment optimiser la mémoire, comment optimiser les recherches, et à quoi ressemble la configuration idéale. Avec l'envie, aussi, d'aller parler technique sur les stands.

Les talks se partageaient entre présentations par les équipes Elastic et retours d'expérience — BPCE et La Poste, notamment.

Les présentations, très denses, déroulaient les nouveautés de la stack. Le travail réalisé ces dernières années est énorme, sur Kibana en particulier. Deux features ont retenu mon attention.

SQL. Annoncé en 6.3 : on requête en SQL-like des données indexées par ElasticSearch.

Rally. Un framework de benchmarking. L'outil n'est pas nouveau, mais il permet de trancher quelle configuration colle le mieux à un SI, en benchmarkant les clusters.

Le reste mériterait un article chacun : Cross-Cluster Replication, Hot-Warm Architecture, Elastic Common Schema, Ingest resilience, Data rollups, Suggestion Extension, Scalable Cross Search, Adaptive Replica Selection, Index Management UI, rolling major version upgrade, index shrinking, frozen indices, index lifecycle management.

Le CEO a passé la moitié de son talk à défendre l'open source, et l'argument mérite d'être rapporté.

Une entreprise qui produit de l'open source ne peut pas bâtir son modèle sur le seul support. L'idéal du support, c'est d'accompagner le client jusqu'à un niveau d'indépendance technique où il n'en a plus besoin.

Or une partie des acteurs joue exactement l'inverse : un support de piètre qualité, entretenu pour maintenir la dépendance. Une sorte d'obsolescence programmée du support.

La réponse d'Elastic : certains produits de la stack deviennent payants, mais l'ensemble reste open source. Parce que seul ce modèle casse la barrière entre celui qui consomme et celui qui produit, en donnant à l'utilisateur la possibilité de retravailler le produit qu'il utilise.

Ils ont confirmé une intuition que j'avais déjà. ElasticSearch devient pertinent sur de gros volumes. Et par gros volume, entends téraoctet.

Le SI du groupe BPCE, c'est 3,3 milliards de messages indexés par jour, 100 milliards de documents, 180 To de données. Sans rapport avec les giga que j'avais eu à traiter.

La force de la suite Elastic aujourd'hui, c'est le monitoring de quantités massives de logs, donc l'analyse chronologique des données.

Le problème rencontré chez BPCE portait sur l'optimisation des index : comment réduire la volumétrie tout en conservant les données ? La réponse est passée par l'API RollUp, qui agrège les données pour en faire de nouveaux index, beaucoup plus légers et plus facilement requêtables.

J'ai regardé par curiosité le résumé des éditions précédentes, à Paris et ailleurs. Les thèmes sont voisins, mais le gain de maturité dans les outils est net, sur Kibana surtout. C'est logique : de plus en plus de SI monitorent des milliards de logs et de métriques au quotidien et cherchent des corrélations entre performance applicative et logs serveurs. Ça demande plus de robustesse et plus de pertinence dans la récupération des métriques.

Mes attentes, elles, ont été remplies. Je sais maintenant qu'il n'y a pas de configuration idéale pour tous. Il faut chercher, tâtonner, tester, échouer, avant de trouver celle qui correspond à son SI.

Et je suis reparti avec un condensé de bonnes pratiques :

• Un cluster par cas d'usage.
• Éviter le fuzziness : coût très élevé en recherche, à réserver à l'auto-complete, à la rigueur.
• Utiliser l'index sorting quand on veut remonter un top résultat — il trie les documents dès l'indexation. Utile quand on ne considère pas le nombre de matchs restants.
• Éviter les champs nested, préférer les documents imbriqués.
• Optimiser le mapping avant de chercher à scaler. Plus de nodes et plus de serveurs ne signifie pas forcément de meilleures recherches.

Cette conférence m'a permis de voir les usages les plus courants de la stack, et de comparer les configurations et architectures techniques sur le sujet. Plus qu'un moteur de recherche applicatif, Elastic tend à devenir un ensemble d'outils d'aide à l'analyse et à la décision technique pour un SI. Et dans cet esprit, de plus en plus de machine learning s'y invite.