OpenSearch AWS kNN Search Observability
OpenSearch est le fork Apache-2.0 d'Elasticsearch 7.10, soutenu par AWS et une large communauté open source. Nous provisionnons et exploitons des clusters managés AWS OpenSearch Service, migrons les charges de travail en production depuis Elasticsearch 7.10 et supérieur, construisons des pipelines d'analyse de logs et SIEM avec OpenSearch Dashboards, et déployons la recherche sémantique vectorielle kNN pour les équipes produit américaines et européennes qui ont besoin d'une licence open source, d'une intégration native AWS et d'une configuration de sécurité prête pour l'audit.
OpenSearch est le fork Apache-2.0 d'Elasticsearch 7.10, soutenu par AWS et une large communauté open source. Nous provisionnons et exploitons des clusters managés AWS OpenSearch Service, migrons les charges de travail en production depuis Elasticsearch 7.10 et supérieur, construisons des pipelines d'analyse de logs et SIEM avec OpenSearch Dashboards, et déployons la recherche sémantique vectorielle kNN pour les équipes produit américaines et européennes qui ont besoin d'une licence open source, d'une intégration native AWS et d'une configuration de sécurité prête pour l'audit.
Défis
Les équipes copient souvent les nombres de shards Elasticsearch sans les adapter aux volumes de données OpenSearch, ce qui génère des milliers de petits shards qui consomment le heap JVM et ralentissent les opérations d'état du cluster. Nous dimensionnons les index à la plage recommandée de 20-50 Go par shard et consolidons les alias de rollover pour maintenir un nombre de shards gérable à mesure que les données croissent.
Les grands caches field-data, les agrégations non bornées et les déséquilibres de nœuds chauds provoquent des pauses GC JVM répétées et des évictions de nœuds sur les clusters OpenSearch. Nous auditons l'utilisation des field-data, remplaçons les field-data à chargement anticipé par des doc-values lorsque c'est possible, distribuons les index chauds sur les nœuds avec une conscience d'allocation des shards, et configurons des disjoncteurs adaptés à la classe d'instance.
Le fork Apache-2.0 a divergé à Elasticsearch 7.10 : les fonctionnalités propriétaires d'Elastic (Elastic APM, EQL dans les versions ultérieures, API spécifiques à Kibana) n'ont pas d'équivalents directs. Les bibliothèques clientes utilisant le protocole transport plutôt que REST nécessitent également des mises à jour. Nous auditons la surface API exacte utilisée par votre application, la mappons vers des équivalents OpenSearch ou OpenSearch Dashboards, et effectuons une validation parallèle avant la bascule.
La pagination profonde, les requêtes préfixe avec joker et les agrégations imbriquées à forte cardinalité sont disproportionnellement coûteuses sur OpenSearch. Nous profilons les requêtes lentes via l'API Profile, remplaçons le scroll non borné par search_after pour la pagination, appliquons shard_preference pour router les agrégations répétées vers des nœuds avec cache chaud, et introduisons des agrégations composites lorsque la cardinalité le permet.
Le plugin de sécurité OpenSearch prend en charge les locataires, les rôles, le masquage de champs et la sécurité au niveau des documents, mais une mauvaise configuration laisse soit des accès sur-privilégiés soit des pannes applicatives. Nous concevons des hiérarchies de rôles alignées sur les personas applicatifs, testons chaque rôle avec un compte de service dédié avant la mise en production, et documentons le modèle de permissions pour les revues d'audit.
Les index k-NN dans OpenSearch chargent les graphes FAISS ou NMSLIB dans le heap JVM, ce qui entre directement en concurrence avec le cache de requêtes sur le même nœud. Les déploiements kNN naïfs épuisent le heap sur des instances de taille modeste. Nous séparons les index kNN sur des nœuds de données dédiés avec des types d'instances optimisés pour la mémoire, ajustons ef_search et ef_construction selon les objectifs rappel/latence, et combinons kNN avec BM25 dans un pipeline de scoring hybride pour une recherche sémantique de qualité production.
Solutions
Provisionnement de bout en bout des domaines AWS OpenSearch Service : placement VPC, dimensionnement des instances, nœuds maîtres dédiés, niveaux de stockage UltraWarm et cold, snapshots S3 automatisés et alertes CloudWatch. Nous gérons les opérations quotidiennes — mises à niveau progressives, rééquilibrage des shards, gouvernance des templates d'index — afin que votre équipe ne porte pas la charge d'astreinte pour la couche de recherche.
Migration structurée d'Elasticsearch 7.10 et supérieur vers OpenSearch : audit de la surface API, mise à jour des bibliothèques clientes (opensearch-py, opensearch-js), révision des templates d'index et de mapping, validation par indexation shadow en parallèle et bascule blue/green. Nous préservons les politiques ILM existantes en équivalents ISM et documentons chaque différence de comportement découverte pendant la fenêtre de migration.
Ingestion centralisée des logs via OpenSearch Ingestion (Data Prepper) ou Fluent Bit, structurés dans des index de séries temporelles avec gestion du cycle de vie ISM. Les visualisations OpenSearch Dashboards, les moniteurs de détection d'anomalies et les notifications d'alerte vers PagerDuty ou Mattermost donnent aux équipes sécurité et opérations une couche d'observabilité complète construite entièrement sur des composants open source.
Recherche kNN en production avec le plugin k-NN d'OpenSearch et les moteurs FAISS ou NMSLIB : conception du pipeline d'embedding (Sentence Transformers, Amazon Titan, modèles personnalisés), configuration de l'index selon les objectifs rappel/latence, et scoring hybride BM25 + kNN pour une pertinence supérieure à la récupération purement lexicale ou purement vectorielle. Déployé pour la découverte de produits, la similarité de documents et la récupération augmentée RAG.
Politiques ISM qui déplacent les index automatiquement entre les niveaux hot, warm, UltraWarm et cold, déclenchées par l'âge, la taille ou le taux de requêtes. Force-merge et compression sur les index fermés. Alias de rollover qui maintiennent des tailles d'index individuelles prévisibles. Nous auditons les clusters existants pour le gaspillage de shards et fournissons un plan de dimensionnement avec la réduction de coût projetée avant tout changement.
Configuration du plugin de sécurité pour le masquage au niveau des champs, les filtres de sécurité au niveau des documents, OpenSearch Dashboards multi-locataire et la liaison de rôles aux comptes de service. Journalisation d'audit routée vers un index dédié, accessible aux équipes de conformité sans accorder d'accès cluster-admin. Certificats TLS gérés via AWS Certificate Manager ou Let's Encrypt avec rotation automatisée.
Stack
OpenSearch, OpenSearch Dashboards, AWS OpenSearch Service (clusters managés), conception des index et des shards, ISM (Index State Management), recherche vectorielle k-NN (moteurs FAISS/NMSLIB), OpenSearch Ingestion (Data Prepper), plugin d'alerting, plugin de sécurité (RBAC fin, sécurité au niveau des champs et des documents), snapshots vers S3, réplication cross-cluster, Logstash, Fluent Bit.
Conformité
Infrastructure de recherche prête pour l'audit · Contrôle d'accès fin au niveau des champs et des documents · TLS nœud à nœud + chiffrement au repos · Politiques de rétention ISM pour la gouvernance des données
Études de cas
Refonte et reconstruction Android + iOS pour un opérateur logistique allemand du dernier kilomètre — planification d'itinéraires multi-points, suivi des chauffeurs en temps réel et facturation intégrée, en production dans l'UE.
Plateforme de réservation de courses à trois applications — chauffeur, passager, répartiteur — avec GPS en temps réel, vérification des documents, paiements en espèces et par carte.
Application d'actualités sportives multiplateforme et portail web — CMS via bot Telegram plutôt qu'un admin personnalisé, pipeline de publication Markdown.
Pourquoi YuSMP
OpenSearch est sous licence Apache-2.0 — aucune restriction SSPL d'Elastic, aucun risque d'audit de licence à mesure que votre cluster évolue. Nous nous appuyons sur AWS OpenSearch Service managé lorsque cela réduit la charge opérationnelle, mais la technologie sous-jacente est entièrement open source et portable, protégeant votre investissement dans la conception des index, les mappings et les intégrations applicatives.
La frontière du fork 7.10 introduit des différences spécifiques d'API et de comportement faciles à négliger lors d'une réindexation directe. Nos ingénieurs ont exécuté des migrations dans de multiples environnements clients et maintiennent une matrice de compatibilité documentée couvrant les bibliothèques clientes, les paramètres d'index, le comportement des agrégations et les équivalents Dashboards pour les visualisations Kibana.
OpenSearch gère à la fois la recherche applicative et l'analyse des logs/SIEM sur la même infrastructure de cluster. Les équipes qui géreraient sinon des piles Elasticsearch et ELK séparées peuvent consolider sur AWS OpenSearch Service, réduisant les coûts d'infrastructure et la complexité opérationnelle tout en bénéficiant d'un RBAC fin sur les deux charges de travail.
FAQ
OpenSearch (Apache-2.0) est le bon choix si vous êtes sur AWS, souhaitez éviter la licence SSPL d'Elastic pour les déploiements auto-gérés, ou avez besoin d'une intégration étroite avec les services AWS (S3, CloudWatch, IAM). Elasticsearch (licence Elastic ou SSPL) est préférable si votre équipe utilise déjà Elastic Cloud, Elastic APM ou des fonctionnalités Kibana sans équivalent OpenSearch. L'API REST est compatible pour la plupart des opérations de requête et d'indexation jusqu'à la base 7.10, ce qui rend la migration applicative généralement simple pour ce sous-ensemble.
La base 7.10 garantit la compatibilité des API de recherche, d'agrégation et kNN, mais les fonctionnalités propriétaires d'Elastic ajoutées après 7.10 — raffinements EQL, certaines API spécifiques à Kibana, format wire d'Elastic APM — n'ont pas d'équivalent direct dans OpenSearch. Nous commençons chaque migration par un audit de la surface API par rapport au code applicatif et aux templates d'index existants, identifions les écarts et les associons à des alternatives OpenSearch avant d'écrire la moindre ligne de script de migration. La plupart des applications REST migrent proprement en une à trois semaines de travail d'ingénierie.
AWS gère le provisionnement matériel, les correctifs OS, les mises à niveau de version OpenSearch (avec votre accord), les snapshots automatisés vers S3, la réplication multi-AZ et les métriques CloudWatch de base. Vous — et nous en votre nom — gérez la conception des index, le dimensionnement des shards, les templates de mapping, les politiques ISM, la configuration du plugin de sécurité, le contrôle d'accès fin, les tableaux de bord personnalisés et l'optimisation des requêtes au niveau applicatif. Choisir AWS OpenSearch Service élimine la charge opérationnelle serveur, mais ne supprime pas le besoin d'expertise en ingénierie de recherche.
Le plugin k-NN d'OpenSearch ajoute un type de champ knn_vector reposant sur des graphes d'approximation des plus proches voisins FAISS ou NMSLIB stockés en mémoire off-heap JVM. Au moment de la requête, une requête knn renvoie les k vecteurs de documents les plus similaires à un embedding de requête. En production, nous combinons kNN avec BM25 via une requête hybride et un pipeline de processeur de normalisation, ce qui surpasse systématiquement chaque approche prise séparément pour la récupération sémantique de documents. Le dimensionnement des instances doit tenir compte de la mémoire du graphe kNN en plus de l'allocation standard du cache de requêtes.
Pour de nombreuses équipes, oui. OpenSearch Ingestion (Data Prepper) ingère des logs depuis Fluent Bit, Logstash ou des sources HTTP directes, applique l'extraction et l'enrichissement de champs, et écrit dans des index de séries temporelles. OpenSearch Dashboards fournit la visualisation, la détection d'anomalies et les alertes comparables à la pile ELK. Le plugin d'analyse de sécurité ajoute des règles de détection de menaces au format Sigma. Pour les environnements réglementés, il délivre la surveillance continue exigée par NIS2 à une fraction du coût des plateformes SIEM commerciales, sans licence par événement.
Le plugin de sécurité superpose plusieurs mécanismes de contrôle d'accès : permissions au niveau du cluster, permissions au niveau de l'index, masquage au niveau des champs (hachage ou anonymisation de champs spécifiques) et sécurité au niveau des documents (clauses de filtre appliquées automatiquement par rôle). La multi-location dans OpenSearch Dashboards isole les visualisations et les patterns d'index entre équipes. Nous configurons des rôles de comptes de service dédiés pour chaque application, séparons les principaux de lecture et d'écriture, et routons les événements d'audit vers un index que les équipes opérationnelles ou de conformité peuvent interroger sans accès cluster-admin.
Sur AWS OpenSearch Service, le coût est dominé par le nombre d'instances et le stockage EBS. Les principaux leviers sont : le dimensionnement du nombre de shards à 20-50 Go par shard (le sur-sharding gaspille le heap du nœud maître), l'activation d'UltraWarm pour les index peu fréquemment interrogés (sauvegardés sur S3, environ 90 % moins cher qu'EBS), le déplacement des données froides vers le niveau cold ou leur suppression via ISM après la fenêtre de rétention, et l'utilisation de force-merge sur les index historiques en lecture seule pour réduire le nombre de segments. Nous fournissons un audit des coûts avec des politiques ISM spécifiques et des recommandations d'instances avant tout changement appliqué en production.
Réponse sous 1 jour ouvrable. NDA sur demande.
Partagez quelques détails et un consultant senior vous répondra sous un jour ouvrable.