OpenSearch AWS kNN Search Observabilidad
Ofrecemos servicios de OpenSearch, el fork con licencia Apache-2.0 de Elasticsearch 7.10, respaldado por AWS y por una amplia comunidad de código abierto. Aprovisionamos y operamos clústeres gestionados de AWS OpenSearch Service, migramos cargas de producción desde Elasticsearch 7.10 y posteriores, construimos pipelines de analítica de logs y SIEM con OpenSearch Dashboards y entregamos búsqueda semántica vectorial kNN para equipos de producto de EE. UU. y la UE que necesitan licencias de código abierto, integración nativa con AWS y una configuración de seguridad lista para auditoría.
Ofrecemos servicios de OpenSearch, el fork con licencia Apache-2.0 de Elasticsearch 7.10, respaldado por AWS y por una amplia comunidad de código abierto. Aprovisionamos y operamos clústeres gestionados de AWS OpenSearch Service, migramos cargas de producción desde Elasticsearch 7.10 y posteriores, construimos pipelines de analítica de logs y SIEM con OpenSearch Dashboards y entregamos búsqueda semántica vectorial kNN para equipos de producto de EE. UU. y la UE que necesitan licencias de código abierto, integración nativa con AWS y una configuración de seguridad lista para auditoría.
Retos
Los equipos suelen copiar el número de shards de Elasticsearch sin adaptarlo a los volúmenes de datos de OpenSearch, y acaban con miles de shards diminutos que consumen heap de la JVM y ralentizan las operaciones del estado del clúster. Dimensionamos los índices en el rango recomendado de 20-50 GB por shard y consolidamos los alias de rollover para mantener manejable el número de shards a medida que crecen los datos.
Las cachés grandes de field data, las agregaciones sin límite y los desequilibrios de nodos calientes provocan pausas repetidas del GC de la JVM y expulsiones de nodos en los clústeres de OpenSearch. Auditamos el uso de field data, sustituimos el field data ansioso por doc-values cuando es posible, distribuimos los índices calientes entre nodos con shard allocation awareness y configuramos circuit breakers adecuados a la clase de instancia.
El fork con licencia Apache-2.0 se separó en Elasticsearch 7.10: las funciones propietarias de Elastic (Elastic APM, EQL en versiones posteriores, API específicas de Kibana) no tienen equivalentes directos. Las bibliotecas cliente que usan el protocolo de transporte en lugar de REST también requieren actualizaciones. Auditamos la superficie exacta de API que usa su aplicación, la asociamos a equivalentes de OpenSearch o a OpenSearch Dashboards y ejecutamos una validación en paralelo antes del cutover.
La paginación profunda, las consultas con comodín al inicio y las agregaciones anidadas de alta cardinalidad son desproporcionadamente costosas en OpenSearch. Perfilamos las consultas lentas con la Profile API, sustituimos el scroll sin límite por search_after para la paginación, aplicamos shard_preference para dirigir las agregaciones repetidas a nodos con caché caliente e introducimos agregaciones compuestas cuando la cardinalidad lo permite.
El plugin de seguridad de OpenSearch admite tenants, roles, enmascaramiento de campos y seguridad a nivel de documento, pero una mala configuración deja accesos con privilegios excesivos o rompe la aplicación. Diseñamos jerarquías de roles alineadas con los perfiles de la aplicación, probamos cada rol con una cuenta de servicio dedicada antes de salir a producción y documentamos el modelo de permisos para las revisiones de auditoría.
Los índices k-NN de OpenSearch cargan grafos de FAISS o NMSLIB en el heap de la JVM, que compite directamente con la caché de consultas del mismo nodo. Los despliegues kNN ingenuos agotan el heap en instancias de tamaño modesto. Separamos los índices kNN en nodos de datos dedicados con tipos de instancia optimizados para memoria, ajustamos ef_search y ef_construction según el objetivo de recall y latencia, y combinamos kNN con BM25 en un pipeline de puntuación híbrida para una búsqueda semántica de calidad de producción.
Soluciones
Aprovisionamiento integral de dominios de AWS OpenSearch Service: ubicación en la VPC, dimensionado de instancias, nodos maestros dedicados, niveles de almacenamiento UltraWarm y cold, snapshots automatizados en S3 y alertas en CloudWatch. Nos encargamos de las operaciones del día dos (actualizaciones graduales, reequilibrado de shards, gobierno de plantillas de índices) para que su equipo no cargue con la guardia de la capa de búsqueda.
Migración estructurada desde Elasticsearch 7.10 y posteriores a OpenSearch: auditoría de la superficie de API, actualización de bibliotecas cliente (opensearch-py, opensearch-js), revisión de plantillas de índices y mappings, validación con shadow-indexing en paralelo y cutover blue/green. Conservamos las políticas ILM existentes como equivalentes en ISM y documentamos cada diferencia de comportamiento descubierta durante la ventana de migración.
Ingesta centralizada de logs mediante OpenSearch Ingestion (Data Prepper) o Fluent Bit, estructurada en índices de series temporales con gestión del ciclo de vida mediante ISM. Las visualizaciones de OpenSearch Dashboards, los monitores de detección de anomalías y las notificaciones de alertas a PagerDuty o Mattermost dan a los equipos de seguridad y operaciones una capa completa de observabilidad construida íntegramente con componentes de código abierto.
Búsqueda kNN de producción con el plugin k-NN de OpenSearch y los motores FAISS o NMSLIB: diseño del pipeline de embeddings (Sentence Transformers, Amazon Titan, modelos propios), configuración de índices para los objetivos de recall y latencia, y puntuación híbrida BM25 + kNN para una relevancia superior a la de la recuperación puramente léxica o puramente vectorial. Desplegada para descubrimiento de productos, similitud de documentos y aumento de recuperación en RAG.
Políticas ISM que mueven los índices automáticamente por los niveles hot, warm, UltraWarm y cold, según la antigüedad, el tamaño o la tasa de consultas. Force-merge y compresión en índices cerrados. Alias de rollover que mantienen predecible el tamaño de cada índice. Auditamos los clústeres existentes en busca de desperdicio de shards y entregamos un plan de ajuste con la reducción de costes prevista antes de aplicar ningún cambio.
Configuración del plugin de seguridad para el enmascaramiento a nivel de campo, filtros de seguridad a nivel de documento, OpenSearch Dashboards multi-tenant y asignación de roles a cuentas de servicio. Registro de auditoría enviado a un índice dedicado, accesible a los equipos de cumplimiento sin concederles acceso de administrador del clúster. Certificados TLS gestionados con AWS Certificate Manager o Let's Encrypt con rotación automatizada.
Stack
OpenSearch, OpenSearch Dashboards, AWS OpenSearch Service (clústeres gestionados), diseño de índices y shards, ISM (Index State Management), búsqueda vectorial k-NN (motores FAISS/NMSLIB), OpenSearch Ingestion (Data Prepper), plugin de alertas, plugin de seguridad (RBAC de grano fino, seguridad a nivel de campo y de documento), snapshots en S3, replicación entre clústeres, Logstash, Fluent Bit.
Cumplimiento
Infraestructura de búsqueda lista para auditoría · Control de acceso de grano fino a nivel de campo y de documento · TLS entre nodos + cifrado en reposo · Políticas de retención ISM para la gobernanza de datos
Casos
Refactorización y reconstrucción en Android e iOS para un operador alemán de logística de última milla: planificación de rutas multipunto, seguimiento de conductores en tiempo real y facturación en la app, en producción en la UE.
Plataforma de transporte con conductor con tres apps (conductor, pasajero y despachador), con GPS en tiempo real, verificación de documentos y doble método de pago en efectivo y con tarjeta.
App multiplataforma de noticias deportivas y portal web: CMS mediante un bot de Telegram en lugar de un panel de administración a medida y un pipeline de publicación en Markdown.
Por qué YuSMP
OpenSearch tiene licencia Apache-2.0: sin las restricciones de la SSPL de Elastic y sin riesgo de auditoría de licencias a medida que escala su clúster. Construimos sobre AWS OpenSearch Service gestionado cuando reduce la carga operativa, pero la tecnología de base es totalmente de código abierto y portable, lo que protege su inversión en diseño de índices, mappings e integraciones de aplicaciones.
La frontera del fork en la 7.10 introduce diferencias específicas de API y de comportamiento que son fáciles de pasar por alto en una reindexación directa. Nuestros ingenieros han ejecutado migraciones en varios entornos de clientes y mantienen una matriz de compatibilidad documentada que cubre bibliotecas cliente, ajustes de índices, comportamiento de las agregaciones y equivalentes de Dashboards para las visualizaciones de Kibana.
OpenSearch gestiona tanto la búsqueda de aplicaciones como la analítica de logs y SIEM sobre la misma infraestructura de clúster. Los equipos que de otro modo ejecutarían stacks separados de Elasticsearch y ELK pueden consolidarse en AWS OpenSearch Service, reduciendo el coste de infraestructura y la complejidad operativa y ganando RBAC de grano fino en ambas cargas.
Preguntas frecuentes
OpenSearch (Apache-2.0) es la elección adecuada cuando se está en AWS, se quiere evitar la licencia SSPL de Elastic en despliegues autogestionados o se necesita una integración estrecha con servicios de AWS (S3, CloudWatch, IAM). Elasticsearch (licencia de Elastic o SSPL) es preferible cuando su equipo ya usa Elastic Cloud, Elastic APM o funciones de Kibana sin equivalente en OpenSearch. La API REST es compatible para la mayoría de las operaciones de consulta e indexación hasta la base 7.10, por lo que la migración a nivel de aplicación suele ser sencilla para ese subconjunto.
La base 7.10 significa que las API principales de búsqueda, agregación y kNN son compatibles, pero las funciones propietarias de Elastic añadidas después de la 7.10 (mejoras de EQL, ciertas API específicas de Kibana, el formato de red de Elastic APM) no tienen un equivalente directo en OpenSearch. Empezamos cada migración con una auditoría de la superficie de API frente al código de su aplicación y a sus plantillas de índices actuales, identificamos las carencias y asociamos cada una a una alternativa de OpenSearch antes de escribir una sola línea de script de migración. La mayoría de las aplicaciones basadas en REST migran sin problemas en una a tres semanas de trabajo de ingeniería.
AWS gestiona el aprovisionamiento del hardware, los parches del sistema operativo, las actualizaciones de versión de OpenSearch (con su aprobación), los snapshots automáticos en S3, la replicación multi-AZ y las métricas básicas de CloudWatch. Usted (y nosotros, en su nombre) gestionan el diseño de índices, el dimensionado de shards, las plantillas de mappings, las políticas ISM, la configuración del plugin de seguridad, el control de acceso de grano fino, los dashboards personalizados y la optimización de consultas en la capa de aplicación. Elegir AWS OpenSearch Service elimina la carga de operar servidores, pero no elimina la necesidad de experiencia en ingeniería de búsqueda.
El plugin k-NN de OpenSearch añade un tipo de campo knn_vector respaldado por grafos de vecinos más cercanos aproximados de FAISS o NMSLIB almacenados en memoria fuera del heap de la JVM. En el momento de la consulta, una consulta knn devuelve los k vectores de documento más similares a un embedding de consulta. En producción combinamos kNN con BM25 mediante una consulta híbrida y un pipeline de procesador de normalización, que supera de forma constante a cualquiera de los dos enfoques por separado en la recuperación semántica de documentos. El dimensionado de las instancias debe tener en cuenta la memoria del grafo kNN además de la asignación estándar de caché de consultas.
Para muchos equipos, sí. OpenSearch Ingestion (Data Prepper) ingiere logs de Fluent Bit, Logstash o fuentes HTTP directas, aplica extracción y enriquecimiento de campos y escribe en índices de series temporales. OpenSearch Dashboards ofrece visualización, detección de anomalías y alertas comparables a las del stack ELK. El plugin de analítica de seguridad añade reglas de detección de amenazas en formato Sigma. En entornos regulados proporciona la monitorización continua que exige NIS2 por una fracción del coste de las plataformas SIEM comerciales, sin licencias por evento.
El plugin de seguridad superpone varios mecanismos de control de acceso: permisos a nivel de clúster, permisos a nivel de índice, enmascaramiento a nivel de campo (hash o anonimización de campos concretos) y seguridad a nivel de documento (cláusulas de filtro aplicadas automáticamente por rol). La multi-tenancy de OpenSearch Dashboards aísla las visualizaciones y los patrones de índices entre equipos. Configuramos roles de cuenta de servicio dedicados para cada aplicación, separamos los principales de lectura y de escritura y enviamos los eventos de auditoría a un índice que el personal de operaciones o de cumplimiento puede consultar sin acceso de administrador del clúster.
El coste en AWS OpenSearch Service está dominado por el número de instancias y el almacenamiento EBS. Las palancas principales son: ajustar el número de shards a 20-50 GB por shard (el exceso de shards desperdicia heap de los nodos maestros), activar UltraWarm para los índices que se consultan poco (respaldado por S3, un ~90 % más barato que EBS), mover los datos fríos al nivel cold o eliminarlos mediante ISM tras la ventana de retención, y usar force-merge en los índices históricos de solo lectura para reducir el número de segmentos. Entregamos una auditoría de costes con políticas ISM concretas y recomendaciones de instancias antes de aplicar ningún cambio en producción.
Respuesta en 1 día hábil. NDA a petición.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.