La plateforme managée Opensearch d'AWS (basé sur le fork d'Elasticsearch) s’enrichit d'un moteur optimisé pour l’analyse des logs. Il pourrait aider les entreprises à faire face à l’augmentation des coûts liés à la conservation des données de télémétrie pour les applications IA « bavardes ». Selon AWS, le moteur pourrait réduire les coûts de stockage de 70 % tout en offrant un meilleur rapport qualité-prix. Les applications IA et agentiques génèrent plus de données télémétriques, une surcharge que les architectures d’observabilité conventionnelles ne savent pas gérer de manière économique. Les entreprises doivent donc trouver un équilibre entre la conservation des données opérationnelles nécessaires à la sécurité, à la conformité et à la gestion des incidents, et la hausse des coûts d’infrastructure associés.

« Avec le moteur d’AWS, les clients pourront continuer à utiliser la même console de gestion, les mêmes API, le même modèle de sécurité et la même configuration réseau que le moteur polyvalent existant du service, tout en stockant les données au format en colonnes Apache Parquet et en conservant les index de recherche Lucene pour les champs consultables », a indiqué le fournisseur. « Le moteur utilise Apache Calcite pour analyser et optimiser les requêtes avant d’acheminer les opérations analytiques vers Apache DataFusion et les prédicats de recherche vers Lucene, ce qui permet d’exécuter la recherche et l’agrégation analytique au sein d’une même requête », ont écrit des responsables d’AWS dans un article de blog. Selon eux, ce moteur optimisé prend en charge SQL et le langage PPL (Piped Processing Language).

Réduire les coûts sans perdre en précision

Dans une récente enquête sur les pratiques de gestion des logs des entreprises, Dynatrace a constaté que les charges de travail liées à l’IA avaient entraîné une augmentation de 93 % du volume des journaux par rapport à l’année précédente, ce qui a conduit les organisations à exclure en moyenne 86 % des données de journaux afin de maîtriser les coûts et la capacité du système. « Gérer des volumes de logs croissants tout en maintenant les coûts pratiquement stables est un défi récurrent auquel toutes les entreprises sont confrontées », a déclaré Ashish Chaturvedi, directeur de recherche chez HFS Research. « La plupart finissent par réduire les durées de conservation ou par échantillonner les logs, ce qui entraîne précisément la perte des données nécessaires en cas d’incidents imprévus », a-t-il ajouté. Shashi Bellamkonda, directeur principal de recherche chez Info-Tech Research Group, reconnait que le traitement des données des agents IA n’a plus rien à voir avec un usage courant d’OpenSearch : « Les requêtes constantes en arrière-plan des agents accédant aux logs ne correspondaient pas aux hypothèses de coût et de performance intégrées au moteur d’origine. La facture est devenue trop élevée. Les entreprises ont commencé à se priver volontairement de certaines informations. »

Mais Stephanie Walter, analyste spécialisée dans les piles IA chez HyperFrame Research, pense que le moteur d’AWS pourrait apporter une solution, même si les utilisateurs ne profitent que d’une partie des avantages promis par l’hyperscaler. « La baisse des coûts de stockage peut se traduire par des durées de conservation plus longues, une meilleure prise en charge de la conformité et des enquêtes d’incident plus complètes », a estimé Mme Walter. Et selon M. Bellamkonda, une conservation moins coûteuse pourrait également aider les DSI à limiter la prolifération des outils, car elle les incite moins à fragmenter les outils d’observabilité entre différents fournisseurs dans le seul but de réaliser des économies. « La multiplication des outils a un coût : des frais d’intégration, mais aussi le personnel nécessaire pour gérer cinq tableaux de bord au lieu d’un seul », a-t-il souligné.

La migration et la compatibilité, des freins à l’adoption

Mais les analystes craignent que la concrétisation de ces avantages nécessite davantage de travail par rapport à la compatibilité vantée par AWS. « Il précise que le moteur optimisé ne peut pas être ajouté à un domaine existant et ne peut pas être activé sur des index individuels au sein d’un domaine à usage général. Son adoption implique de créer un nouveau domaine et d’y migrer les pipelines d’ingestion, ce qui rend la transition plus complexe pour les équipes d’ingénierie qu’un simple ‘lift-and-shift’ », a fait remarquer M. Bellamkonda. Selon M. Chaturvedi, un autre inconvénient du moteur est son absence de prise en charge des langages DSL dédiés (Domain Specific Language, DSL). Cela signifie que les entreprises disposant de déploiements OpenSearch existants basés sur des requêtes DSL ou dont les charges de travail nécessitent des mises à jour fréquentes pourraient devoir réécrire leurs tableaux de bord, leurs alertes et leurs workflows d’automatisation avant de passer au moteur optimisé, ce qui pourrait allonger les délais de migration », a expliqué M. Chaturvedi.

« Ces considérations liées à la mise en œuvre pourraient peser davantage sur le rythme d’adoption du moteur que la technologie qui le sous-tend », a encore déclaré M. Bellamkonda. « Ce sont les difficultés liées à la migration, et non le coût, qui poussent généralement les entreprises à conserver une infrastructure devenue obsolète », a-t-il poursuivi. « AWS a réduit les frictions liées à la migration en prenant en charge l’ingestion via la même API Bulk et les mêmes bibliothèques clientes, ce qui signifie qu’aucune modification n’est nécessaire au niveau des pipelines d’ingestion ou du code des applications. Cependant, cela n’a pas supprimé entièrement les frictions liées à la migration », a-t-il ajouté.