Retour d’Elastic{ON} et Elasticsearch 2.0

Retour d'Elastic{ON} et Elasticsearch 2.0

La Elastic{ON} (cycle de conférences organisé par Elastic) est passée à Paris ce jeudi et nous y étions. À peine une semaine après la sortie d’Elasticsearch 2.0, voici ce que j’ai retenu de cette journée passée au Pavillon d’Armenonville.

Je ne reviens pas dans cet article sur les nouveautés connues (le fsync, le Cluster State plus rapide, les optimisations, le merge intelligent…) ; mais plutôt sur ce que j’ai appris lors de la conférence.

Le futur d’Elasticsearch

Beaucoup d’annonces ont été faites et une roadmap se dessine :

  • un Query Profiler est en cours de développement et devrait être mergé dans la 2.1 – c’est très attendu, et j’ai vraiment hâte de pouvoir m’en servir !
  • vous avez peut-être entendu parler de Beats, l’outil prend du galon et se positionne en framework ; il propose déjà :
    • packetbeat : un sniffer réseau qui extrait les requêtes HTTP, SQL… et les index ;
    • topbeat : index les top (les processus en cours) de vos serveurs, et permet de les grapher ;
    • filebeat : permet l’envoi de fichiers de logs (ou autre) vers Beats, il remplace logstash-forwarder !
  • un nouveau langage de script est en cours de développement, toutes les tentatives précédentes d’inclure des langages sandboxés ont échouées ; espérons qu’il sera simple a débugger (j’ai soumis l’idée :p) ;
  • la core team veut intégrer une graph API et se penche sur le machine learning. Deux fonctionnalités qui devraient arriver en 2016 ;
  • une nouvelle API de gestion de tâches va arriver, nous permettant de surveiller et d’agir sur ce que fait Elasticsearch en arrière plan ;
  • vous avez plusieurs clusters dans différents data-centers ? La réplication de cluster distant va être rendue possible nativement ;
  • Elasticsearch a acquis le SaaS Found en mars 2015, et l’annonce du jour est que leur orchestrateur de node Elasticsearch va être packagé et distribué, permettant de construire et gérer son cluster privé avec les mêmes outils et la même facilité, sans devoir envoyer vos documents sur l’internet ;

Des démos étaient présentées toute la journée mais il est encore trop tôt pour tester toutes ces nouveautés à la maison, une chose est sûr : 2016 va être très vivant pour la stack ELK.

Le nouveau Kibana

La nouvelle architecture de Kibana 4.2, avec son serveur NodeJS et son système d’applications, ouvre les portes à de nouvelles interfaces ; nous avons par exemple eu le droit à une démonstration de TimeLion qui permet d’exploiter très facilement les Pipeline aggrégations. Il n’est pas encore public mais semblait déjà très proche de la release.

Quelques bonnes nouvelles :

  • il n’est plus nécessaire d’exposer son Elasticsearch sur le Web, Kibana 4.2 fait proxy devant vos nodes ;
  • il est maintenant possible d’utiliser son propre serveur de tiles pour les cartes (WMS) ;
  • l’export PDF, demandé depuis 2013, fait partie de la roadmap officielle !

Pour le reste, vous le savez déjà : Sense est maintenant une application Kibana, l’interface de Marvel est très différente parce qu’elle a été réécrite, et va évoluer rapidement pour rattraper le niveau de la version 1.

Les retours d’expérience

L’après-midi était orientée retours d’expériences. Au programme, Natixis, ERDF, PSA Peugeot Citroën, et AXA qui nous ont parlé de leurs utilisations du produit, mais clairement pas des aspects techniques, scalabilités, implémentation. Seul Orange m’a semblé intéressant.

Le moteur de recherche d’Orange

Depuis 1996, Orange propose un moteur de recherche sur son portail. Aujourd’hui basé sur un outil propriétaire, il est en cours de réécriture sur Elasticsearch.

Leur cluster est composé de 13 noeuds dont 3 sans data. Après beaucoup d’explorations et de tests, ils en ont déduit leurs paramètres optimaux :

  • 0 réplica ;
  • clés de cache de filtre custom, et désactivation aux niveaux inférieurs ;
  • 10 machines et 20 shards… mais 2 noeuds par machine ;
  • les 3 noeuds sans data sont indispensables aussi bien en recherche qu’en indexation.

Ils comptent 1.2 milliards de documents, et obtiennent un index de 4,2 To qui se peuple en 2h45m – plutôt pas mal comme durée !

Le mot de la fin

La journée était très bien organisée et les conférences de la matinée riches, vivantes et informatives. J’ai été plutôt déçu par l’après-midi ; mais j’en ai profité pour discuter avec la Core Team.

Merci à Elastic, on se revoit dans un an !

Migrer vers Elasticsearch 2.0 ?

Cela fait donc une semaine que la version 2.0 stable est sortie, et tout le monde me parle de migration. Outre les vérifications d’usage (plugin migration et réécriture des query avec la nouvelle syntaxe si besoin), il faut quand même parler de l’éco-système.

Prenons Marvel par exemple, outre le fait qu’il est beaucoup plus compliqué à installer maintenant (il faut 4 briques : un plugin Elasticsearch de gestion de licences, un plugin Elasticsearch qui contient l’agent Marvel, Kibana 4.2 et une app Kibana qui contient l’interface Marvel), l’interface a perdu pas mal de contenus, et pour le coup, vous n’y trouverez plus tous vos petits (pour l’instant).

Marvel 2.0

Côté PHP, le client Elastica n’est pas encore compatible, et l’attente sera encore plus longue si vous utilisez une autre abstraction par dessus (FOSElasticaBundle pour Symfony par exemple). Il faut aussi compter sur les plugins tiers que vous pourriez avoir dans votre installation : tout ce qui n’est pas officiellement maintenu par Elastic nécessitera du temps.

Ma recommandation est donc d’être prudent, rien ne presse, Elasticsearch 1.7 est déjà excellent et cette 2.0 n’apporte pas de grande nouvelle fonctionnalité : la migration est donc un confort dont vous pouvez vous passer. Attendez 2016, les premières corrections de bug, la maturité, et gardez vos cheveux ;-)

Enfin, j’en profite pour annoncer que notre formation Elasticsearch est à votre disposition et que dès 2016 nous ne formerons plus que sur Elasticsearch 2.0 !

blog comments powered by Disqus