Elastic Cloud : Elastic esquisse sa nouvelle architecture « stateless »
Elastic présente une nouvelle architecture pour Elastic Cloud, sa plateforme disponible en mode SaaS. L’éditeur veut simplifier la gestion de l’indexation et les coûts associés pour encourager les utilisateurs à adopter ses services cloud.
Il est difficile de l’admettre pour une entreprise comme Elastic : son architecture n’est pas cloud-native.
Cela peut s’expliquer aisément. L’entreprise est née en 2012, avant la généralisation du cloud. Mais se limiter à cette remarque ne suffit pas pour comprendre pourquoi le déploiement de la pile ELK (Elasticsearch Logstach, Kibana) et des outils associés demeure principalement déployé par les clients.
Bien que le modèle économique de sa plateforme Elastic Cloud est censé favoriser la migration vers le cloud, la majorité des clients ont déployé par eux-mêmes son architecture distribuée sur site ou sur les services IaaS des fournisseurs.
De plus, Elastic souffre du même problème que son concurrent Splunk : la phase d’ingestion de données demeure coûteuse, malgré les « rails de sécurité » en place dans sa plateforme.
En effet, Elasticsearch – un moteur de recherche Apache Lucene porté par une base de données NoSQL – réclame, après la phase d’ingestion, une procédure d’indexation spécifique qu’il faut souvent répéter et bien évidemment répliquer.
Comme ses clients faisaient face à des pertes de données, il a pris plusieurs années pour élaborer un sous-système de coordination des clusters disponible dès la version 7 d’Elasticsearch. Il s’agissait d’assurer la cohérence des mappages, des paramètres des index, des partitions attribuées à différents nœuds.
Réduire les coûts de l’indexation pour convaincre les clients
Tout comme ses concurrents, Elastic a pris des mesures pour tenter d’abaisser les coûts de stockage et de calcul liés à l’ingestion et à l’indexation de documents.
Pour cela, il a mis en place un système de tiers de stockage chaud, tiède, froid et gelé. En principe, cela permet de réduire le coût d’hébergement des données, notamment de celles archivées à des fins d’audit ou d’analyse de sécurité. Dans la 7.10 d’Elasticsearch, l’éditeur a revu la syntaxe pour clarifier la manière de configurer cette fonctionnalité.
Une fois que les données sont placées dans ces « frigos » et ces congélateurs, il faut bien pouvoir les interroger. Le coût du stockage est prévisible, dans une certaine mesure. Ce qui est beaucoup plus dur à estimer, c’est le coût de traitement des données. Or le volume de requêtes sur les données stockées dans ces tiers froids représente un pôle de dépense croissant pour les entreprises qui utilisent les tiers Hot/Warm/Cold/Frozen.
Depuis la 7.10, Elastic a mis en place ce qu’il appelle les « searchable snapshots » (les snapshots interrogeables, en français douteux). Ces snapshots entreposés dans des services de stockage objet (Amazon S3, Azure Storage, Google Cloud Storage, etc.) sont spécifiques aux tiers cold et frozen. Ils contiennent les shards de réplication des index qui peuvent être alloués automatiquement à un nœud d’un cluster, afin de réhydrater les données locales. Cela permettrait d’abaisser les frais de stockage jusqu’à 50 % par rapport au niveau warm « tout en assurant le même niveau de fiabilité et de redondance », promet l’éditeur.
A contrario des tiers de stockage tiède et chaud, qui impliquent l’utilisation de la moitié de l’espace disque pour stocker les données répliquées, la recherche avec les snapshots interrogeables est plus lente.
Ce compromis aurait toutefois permis des gains importants pour Elastic et certains de ses clients. Or, cela ne suffit pas : l’éditeur aimerait encore améliorer sa plateforme Elastic Cloud.
Mieux profiter des capacités du stockage objet en cloud
Car, avec ses différents dispositifs, l’éditeur ne s’était pas encore réellement attaqué au cœur du problème, selon ses dires. Son architecture stateful le limite.
Son système « à état » (stateful) est constitué de plusieurs « pièces », dont trois principales : le translog qui garantit les opérations d’écriture (à l’instar de la méthode WAL de PostgreSQL), l’espace de stockage des index, et les métadonnées des clusters. Ainsi, le stockage doit être persistant, c’est-à-dire qu’il est effectué sur les disques locaux d’un nœud, de manière à éviter les pertes lors d’un redémarrage ou de l’ajout d’un nœud dans un cluster.
De plus, l’architecture d’Elastic Cloud réplique forcément les index à travers plusieurs zones de disponibilité pour assurer la redondance des données. Conséquence : les index occupent de la place sur les disques locaux des nœuds d’un cluster. Surtout, ces réplications réclament davantage de ressources de calcul à l’ingestion, puisque cela revient à exécuter plusieurs fois cette même opération à l’arrivée des données sur un cluster.
Le déploiement de Searchable Snapshot a inspiré l’éditeur pour tenter de mettre en place une architecture « stateless ». Cette dénomination peut être trompeuse. Il s’agit plutôt pour Elastic d’externaliser la gestion des états à un service de stockage objet proposé par un fournisseur cloud.
Pourquoi ne pas décharger les index et le translog directement dans un stockage objet cloud comme S3 et laisser le service cloud effectuer automatiquement la réplication dans trois zones de disponibilité différentes ? Il fallait tester cette théorie et vérifier – à minima – si elle était viable chez les trois fournisseurs de cloud. Malgré les différences entre S3, Azure Blob Storage et GSC, Elastic est désormais convaincu que ces services peuvent prendre en charge « les besoins d’indexation des plus gros clusters » vus dans Elastic Cloud.
De la même manière, avoir les données persistées dans un stockage objet et se servir du stockage local des nœuds comme une couche de cache pour les données les plus requêtées aurait fait ses preuves. Cerise sur le gâteau, cela permettrait d’abaisser le volume de données persistées au niveau du cluster chargé de l’indexation.
Ainsi, il serait possible de n’effectuer l’indexation qu’une seule fois après une phase d’ingestion, ce qui promet d’abaisser de manière conséquente la consommation de ressources CPU. Pour information, les clients présents lors d’ElasticON Europe à Amsterdam ingèrent en moyenne 1 To de données par jour dans leur stack Elastic, qu’ils soient sur site ou dans le cloud.
De là découle l’idée suivante : au lieu d’avoir des instances primaires et secondaires synchronisées qui prennent en charge toutes les opérations, il s’agirait de mettre en place un tier d’indexation et un tier de recherche.
Le tier d’indexation exécuterait une opération d’indexation sur les données ingérées, puis persisterait le résultat (les segments Lucene) dans un stockage objet. Le tier dédié à l’interrogation pourrait lire les résultats depuis ce même data store.
Elastic tirerait deux avantages de la nouvelle architecture : il réduirait le nombre de tier de stockage nécessaire – moins chers, mais plus complexes à déployer et à maintenir – et il obtiendrait une séparation presque totale du stockage et du calcul (presque, parce que les métadonnées et les index seront mis en cache au niveau du tier d’indexation).
Cela demande d’utiliser d’autres types d’instances des fournisseurs cloud, misant sur les ressources CPU et RAM. Il n’est pas sûr que l’éditeur arrive à se passer des bonnes vieilles instances EC2.
Quant au tier dédié à la recherche, il pourrait reposer sur des services serverless, capables de « s’éteindre » après l’exécution d’une requête.
Elastic est loin d’être le seul à proposer une architecture qui découple le calcul du stockage. En fait, cette approche devient la norme dans le cloud chez AWS, Snowflake, Databricks, Google Cloud et d’autres.
« Je pense que ce qui est unique, c’est que nous le faisons pour un moteur de recherche, ce qui est très compliqué à faire », affirme Shay Banon, CTO et cofondateur d’Elastic (en photo en haut de page, ElasticOn Amsterdam, novembre 2022). « Un moteur de recherche doit supporter des modèles d’accès très différents. Beaucoup d’autres bases de données sont construites au-dessus d’un accès séquentiel ou d’un modèle d’accès prévisible, ce qui rend le découplage du calcul et du stockage plus simple », argumente-t-il.
Les fondations pour les dix années à venir
Ce n’est qu’un début. « Il fallait déjà prouver que cela fonctionne », tempère Shay Banon. « Nous arrivons à conserver les API et la plupart des sémantiques que nous proposons. C’est principalement le modèle d’implémentation qui change ».
Et au CTO d’insister auprès du MagIT sur le fait qu’il faudra au moins un an pour voir débarquer cette nouvelle architecture « stateless » dans un mode limité, ne couvrant qu’un « petit nombre de cas d’usage ». Pour rappel, Elastic utilise sa stack ELK afin de propulser un moteur de recherche, une suite dédiée à l’observabilité et à la sécurité.
L’éditeur ne refond pas son architecture uniquement pour la beauté technique ou le gain supposé en performance. Il le fait aussi parce qu’il veut abaisser ses coûts dans le cloud et encourager la migration vers Elastic Cloud, sa plateforme disponible en mode SaaS.
De prime abord, le modèle économique de l’éditeur fonctionne déjà. Au premier trimestre fiscal 2023 terminé le 31 juillet 2022, Elastic Cloud générait 39 % de ses revenus, soit 97 millions de dollars en hausse de 59 % par rapport à l’année précédente. Les autres modes de souscription (self-managed) représentent 54 % de son CA. (134 millions de dollars).
Pour autant, il affichait des pertes nettes de plus de 69 millions de dollars. Ash Kulkarni, CEO d’Elastic, se montrait « confiant », malgré les « vents contraires » dus à l’inflation monétaire. Si Elastic dessert des usages critiques, par exemple avec son SIEM, il n’est pas à l’abri de coup de rabot de la part de clients qui subiraient plus fortement ces vents contraires. Une solution cloud plus abordable pourrait convaincre les entreprises qui considèrent que la migration n’en vaut pas encore la peine.
« Lorsque les gens viendront sur notre cloud, ils pourront choisir entre l’architecture actuelle et la nouvelle architecture Stateless. »
Shay BanonCTO et cofondateur d’Elastic
« La nouvelle architecture devrait être pertinente pour les dix prochaines années », assure le CTO.
Toutefois, il ne faut pas introduire de changement cassant pour les clients existants ou pour ceux qui maîtriseraient déjà l’ancienne architecture. En tout cas, pas tout de suite. « Nos clients utilisent l’ancienne architecture, tout comme nous. Lorsque les gens viendront sur notre cloud, ils pourront choisir entre l’architecture actuelle et la nouvelle architecture Stateless », promet-il. « Et nous les maintiendrons côte à côte pendant des années ».
Certains clients ne pourront pas adopter ce modèle d’architecture s’il est uniquement pensé pour le cloud. Lors d’ElastiCon, LeMagIT a pu constater l’existence de cas d’usage des produits Elastic qui ne peuvent être migrés pour des raisons évidentes de conformité.
Enfin, la nouvelle architecture n’est pas encore hybride sur le papier. Ce n’est que depuis cette année que l’éditeur propose des fonctions pour fédérer la recherche et la réplication entre les clouds et les datacenters. « Pour l’instant, nous nous concentrons à adapter notre architecture aux services de Google Cloud, AWS et Azure », affirme Shay Banon.
