Elasticsearch Service : quand l'efficacité du stockage des données livre des stratégies de réduction des coûts

Des milliers de clients ont opté pour l'offre officielle Elasticsearch Service (ESS) sur Elastic Cloud. Il y exécutent Elasticsearch, mais aussi des produits exclusifs tels qu'Elastic Logs, Elastic APM, Elastic SIEM, et plus encore. Avec plus de sept ans d'existence sur le marché, ESS est le seul service géré à proposer l'expérience Elasticsearch complète, avec toutes les fonctionnalités, toutes les solutions, et tout le support directement fourni par Elastic. Sans oublier les nombreux avantages en termes d'exécution et de déploiement qui viennent compléter ces produits.

Dans un précédent article, nous avions abordé les frais cachés imputables au réseau lorsqu'on utilise une solution SaaS qui ne se trouve pas dans la même région que vos services, votre infrastructure, ou vos appareils de logging, ce qui peut faire exploser les coûts. Aujourd'hui, nous allons voir comment Elasticsearch Service sur Elastic Cloud vous laisse la liberté de choisir différentes stratégies pour maîtriser les coûts à mesure que vous montez en charge.

Lorsqu'un déploiement prend de l'importance, notamment dans les domaines de l'observabilité et de la sécurité, cela entraîne toujours une extension de l'infrastructure nécessaire au stockage et à l'analyse des logs, des indicateurs et des traces APM, ou encore au stockage des événements de sécurité générés par vos applications. Et tout cela entraîne un surcoût. Avec ESS, vous avez différents moyens de gérer vos données pour en limiter les coûts, tout en conservant celles qui vous intéressent sur de longues périodes. Et pendant ce temps, vous continuez d'exploiter toutes les précieuses fonctionnalités de la Suite Elastic : consolidation des données provenant de différentes sources, options de visualisation, alerting, ou encore détection des anomalies, pour n'en citer que quelques-unes.

Nous allons donc examiner les possibilités qui s'offrent à vous pour réduire les coûts associés aux données temporelles, par exemple dans des cas d'utilisation comme l'observabilité et la sécurité. À des fins d'illustration, nous nous pencherons sur le monitoring de l'infrastructure, qui est l'une des applications les plus courantes de la Suite Elastic. Rappelons aussi que la Suite Elastic comprend Beats, une famille d'agents de transfert léger qui s'exécutent sur vos clients et transfèrent les données vers votre cluster. Un très grand nombre d'utilisateurs exploitent ainsi Metricbeat pour envoyer des indicateurs système : utilisation du processeur, nombre d'E/S par seconde sur le disque, ou encore données télémétriques de conteneur pour les applications exécutées sur Kubernetes.

À mesure que s'étend votre empreinte applicative, vos besoins de monitoring exigent plus de stockage, afin d'accueillir les indicateurs générés. Définir une période de conservation est l'une des stratégies que choisissent aujourd'hui les équipes pour gérer les données temporelles à grande échelle. Dans cet article, nous allons découvrir d'autres possibilités de stockage efficaces, qui sont directement exploitables avec ESS aujourd'hui.

Scénario

Pour garder le même ordre de grandeur que l'article précédent, nous prendrons l'exemple d'un cluster qui assure le monitoring de 1 000 hôtes, et dans lequel chaque agent collecte 100 octets par indicateur et 100 indicateurs toutes les 10 secondes, avec une période de conservation des données égale à 30 jours, et nous verrons de près les stratégies de réduction des coûts que nous pouvons appliquer. Nous allons aussi stocker un réplica des données dans le cluster pour en assurer la haute disponibilité, ce qui évite la perte de données en cas de défaillance d'un nœud. Calculons maintenant la taille du stockage qu'il nous faut :

Pour stocker ces indicateurs, nous avons donc besoin de 5, 2 To. Pour simplifier, nous allons ignorer le stockage nécessaire à l'exécution du cluster Elasticsearch.

Récapitulons :

Doper l'efficacité du stockage grâce aux déploiements hot-warm et à la gestion du cycle de vie des index

Dans les cas d'utilisation d'observabilité comme le logging et les indicateurs, les données deviennent moins utiles avec le temps. En général, les équipes exploitent les données récentes pour analyser rapidement les incidents système, les pics inattendus du trafic réseau ou les alertes de sécurité. À mesure que les données vieillissent, on les recherche moins fréquemment, mais elles demeurent néanmoins dans le cluster et consomment les mêmes ressources de calcul, de mémoire et de stockage que le reste. Résultat, nous avons deux modèles très différents d'accès aux données. Cependant, le cluster n'est optimisé que pour l'ingestion rapide et les recherches fréquentes, et non pour le stockage de données peu exploitées.

Les architectures hot-warm d'Elasticsearch Service viennent bousculer tout cela. Cette option de déploiement propose deux profils matériels dans le même cluster Elasticsearch. Les nœuds hot gèrent alors l'ensemble des données récentes en entrée et disposent d'un stockage plus rapide, qui assure une ingestion et une récupération plus promptes des données. Les nœuds warm, quant à eux, présentent une plus grande densité de stockage et s'avèrent plus rentables pour la conservation des données à plus long terme.

Dans Elasticsearch Service, nous provisionnons en général des NVMe SSD connectés localement avec un ratio RAM:disque de 1:30 pour les nœuds hot, et des HDD haute densité à 1:160 pour les nœuds warm. Cette architecture ultraperformante va de paire avec une autre fonctionnalité essentielle : la gestion du cycle de vie des index (ILM, pour "index lifecycle management"). La gestion du cycle de vie des index permet d'automatiser la gestion des index au fil du temps, ce qui simplifie le déplacement des données depuis des nœuds hot vers des nœuds warm en fonction de certains critères, comme la taille de l'index, son ancienneté, ou encore le nombre de documents.

L'association de ces deux fonctionnalités vous permet d'avoir deux profils matériels distincts dans votre cluster – sans oublier les outils d'automatisation des index, qui vous permettent de déplacer les données d'un niveau à l'autre.

Nous allons maintenant migrer vers un déploiement hot-warm et configurer les règles relatives à la gestion du cycle de vie des index. Dans ESS, vous pouvez créer un déploiement hot-warm, avec la possibilité de restaurer le snapshot d'un autre cluster. Si vous disposez déjà d'un déploiement avec E/S hautes performances, il vous suffit d'ajouter des nœuds warm à votre cluster pour migrer vers un déploiement hot-warm. Grâce aux règles relatives à la gestion du cycle de vie des index, nous conservons les données dans le niveau hot pendant sept jours avant de les déplacer vers nos nœuds warm.

Sous le capot, lorsque les données passent en phase warm, vous ne pouvez plus écrire dans les index. Autrement dit, c'est une nouvelle occasion de réduire les coûts, puisque nous pouvons choisir de ne stocker aucun réplica dans nos nœuds warm. En cas de défaillance du nœud warm, on procèderait à une restauration depuis le dernier snapshot plutôt que depuis des réplicas.

L'inconvénient de cette approche, c'est que la restauration depuis un snapshot est généralement plus lente et peut impacter votre temps de résolution après défaillance. Cependant, dans bien des cas, cela ne pose pas de problème majeur, puisque les nœuds warm contiennent généralement des données peu recherchées : les conséquences sont donc en réalité limitées.

Pour terminer, nous allons supprimer les données une fois qu'elles auront atteint 30 jours d'ancienneté, afin de respecter notre règle de conservation initiale. Le calcul est similaire à celui que nous avons effectué plus haut. On pourrait résumer cette approche ainsi :

Cette approche vous permet donc de réduire vos coûts mensuels de 60 %, ce qui est remarquable, tout en conservant des données accessibles et résilientes. Vous pouvez ajuster les règles relatives à la gestion du cycle de vie des index (ILM) afin de trouver les périodes de roulement idéales et ainsi optimiser l'utilisation du stockage sur les nœuds warm.

Libérer plus d'espace de stockage grâce au cumul de données

Autre possibilité d'économiser le stockage : le cumul de données. En "cumulant" les données dans un seul document récapitulatif stocké dans Elasticsearch, les API de cumul vous permettent de résumer les données et de les stocker de manière plus dense. Vous pouvez alors archiver ou supprimer les données d'origine pour gagner de l'espace de stockage.

Lorsque vous créez un cumul, vous choisissez les champs qui vous intéressent pour de futures analyses, ce qui génère un nouvel index ne contenant que ces données cumulées. Cela s'avère particulièrement utile dans les cas d'utilisation de monitoring qui gèrent principalement des données numériques pouvant facilement être résumées à une granularité élevée (de l'ordre de la minute, de l'heure ou de la journée), tout en continuant d'indiquer les tendances au fil du temps. Les index résumés sont disponibles dans tout Kibana. Vous pouvez les ajouter avec vos tableaux de bord existants pour assurer la continuité de vos analyses. Et tout cela peut être configuré directement dans Kibana.

Pour reprendre le scénario ci-dessous, souvenez-vous que nous avions besoin de 5,2 To d'espace de stockage pour conserver l'équivalent de 30 jours de données d'indicateurs provenant de 1 000 hôtes, ainsi que d'un réplica défini pour assurer la haute disponibilité. Nous avons ensuite décrit un scénario faisant appel à un modèle de déploiement hot-warm. Nous allons maintenant utiliser l'API de cumul de données pour configurer une tâche de cumul à exécuter lorsque les données atteignent une ancienneté de 7 jours. Nous allons perdre un peu en granularité, mais libérer bien plus d'espace de stockage.

Nous allons définir notre tâche de cumul de données pour qu'elle cumule nos données d'indicateurs générées toutes les 10 secondes en documents résumés toutes les heures. Cela nous permettra toujours de rechercher et de visualiser nos anciens indicateurs à des intervalles d'une heure, que nous pouvons exploiter dans nos visualisations Kibana et Lens pour repérer des tendances et d'autres moments clés dans les données. Ensuite, nous supprimerons les documents d'origine que nous venons de cumuler, ce qui nous permettra de libérer un grand espace de stockage dans le cluster. Nous pouvons calculer l'espace de stockage nécessaire pour les données que nous venons de cumuler.

Les données initiales de ces documents cumulés avaient plus de 7 jours et étaient donc stockées sur des nœuds warm de notre cluster hot-warm. L'intégralité de ces 1,99 To de données peut être supprimée. Le résultat obtenu est présenté dans la colonne de droite :

Les économies réalisées sont impressionnantes. Lorsque nous ajoutons le cumul de données à notre cluster hot-warm existant, nous pouvons atteindre une réduction des coûts de 31 %. Les résultats sont encore plus radicaux si nous comparons notre scénario final à un cluster classique ne disposant que d'un seul niveau matériel : nous économisons alors 73% !

Déployez comme vous voudrez

Chaque méthode a des avantages et des inconvénients. Vous êtes libre d'affiner chaque stratégie afin qu'elle réponde le mieux à vos besoins.

Les règles de gestion du cycle de vie des index (ILM) vous permettent de définir des périodes de roulement en fonction de la taille de l'index, du nombre de documents ou de leur ancienneté. Vos données sont ensuite déplacées vers les nœuds warm de votre cluster hot-warm. Les nœuds warm peuvent assurer un stockage très dense et très efficace, ce qui vous permet d'économiser sur les coûts de calcul. Les temps de recherche peuvent ne pas se montrer aussi performants que sur les nœuds hot : cette approche reste donc plus adaptée aux données que vous ne recherchez pas souvent.

Le cumul de données vous permet de résumer les données dans des documents de moindre granularité, ce qui s'avère utile lorsque l'ancienneté de ces données ne justifie plus leur niveau de granularité initial. Les documents source peuvent alors être supprimés, ce qui vous permet de réduire le coût du stockage. Vous pouvez définir le degré de résumé des documents et le moment auquel où il doit intervenir. Trouvez le bon équilibre, afin que vos données cumulées continuent de vous fournir de précieuses informations, comme les tendances au fil du temps ou le comportement du système pendant un pic de trafic.

Vous voilà familiarisés avec des stratégies immédiatement exploitables, qui vous permettent d'optimiser les charges de travail des indicateurs de votre cluster Elasticsearch. Mais qu'allez-vous faire de tout cet espace de stockage disponible, maintenant ? La Suite Elastic est utilisée dans le monde entier pour répondre à une myriade de cas d'utilisation : logs, traces APM, événements d'audit, données de point de terminaison, et plus encore.

Elasticsearch Service sur Elastic Cloud vous offre les mêmes avantages que la Suite Elastic, ainsi que le savoir-faire opérationnel signé Elastic. Pas encore prêt à essayer de nouveaux cas d'utilisation ? Aucun problème. Vous pouvez optimiser le stockage et continuer de mettre votre cluster au travail. Vous pouvez aussi allonger les temps de conservation des données et en stocker encore plus pour un tarif similaire. Ou même réduire la taille de votre cluster en quelques clics sans compromettre la visibilité – ce qui se traduit par des économies.

Envie de vous lancer avec Elasticsearch Service sur Elastic Cloud ? Essayez gratuitement la version d'essai pendant 14 jours.