OpenSearch 3.0 릴리즈 - 벡터 데이터베이스 성능 및 AI 기반 검색 인프라 대폭 강화

• OpenSearch 3.0이 정식 출시되며, OpenSearch 1.3 대비 9.5배 향상된 성능을 제공
• GPU 가속, AI 에이전트 연동, 저장소 최적화 등 벡터 검색을 위한 혁신적 기능 다수 추가
• gRPC, Kafka 스트리밍, 인덱스 자동 식별 등으로 데이터 처리 효율과 유연성 강화
• 검색 인프라 측면에서는 Lucene 10, Java 21, 모듈형 아키텍처를 적용해 미래 확장성과 유지보수성 개선
• AI 및 RAG 기반 검색 수요 증가에 대응하는 오픈소스 커뮤니티 기반의 차세대 검색 플랫폼으로 자리매김

---

OpenSearch 3.0 정식 출시: AI 시대를 위한 벡터 검색 최적화

• OpenSearch Software Foundation은 OpenSearch 3.0 정식 버전을 공개하며, OpenSearch 1.3 대비 9.5배 성능 향상 발표
• AI 검색, 추천 시스템, RAG 등에서 요구되는 대규모 벡터 데이터 처리 성능을 개선

벡터 엔진 혁신: 성능과 비용 효율 동시 확보

• GPU 가속 (NVIDIA cuVS 기반): 인덱스 빌드 시간 최대 9.3배 단축, 고성능 워크로드 처리
• Model Context Protocol (MCP) 지원: AI 에이전트와의 연동을 통해 유연한 검색 솔루션 구축 가능
• Derived Source 기능: 중복 벡터 데이터 제거로 저장소 사용량 1/3 감소

데이터 관리 기능: 유연성과 확장성 강화

• gRPC 지원: 노드 간 및 클라이언트-서버 간 데이터 전송을 고속화 (실험적)
• Pull 기반 데이터 수집: Kafka, Kinesis 등 외부 스트리밍 시스템에서 OpenSearch가 직접 데이터 가져오는 구조 적용
• Reader-Writer 분리: 검색과 인덱싱을 분리해 각 작업의 안정성과 성능 확보
• Apache Calcite 통합: SQL/PPL에서 직관적인 쿼리 빌더 기능 제공
• 인덱스 유형 감지: 자동으로 로그 인덱스를 식별해 적절한 분석 옵션 제공

검색 인프라 및 플랫폼 코어 개선

• Lucene 10 업그레이드: 병렬 작업 성능 향상 및 검색 기능 고도화
• Java 21 최소 지원 런타임: 최신 언어 기능 및 성능 활용 가능
• Java 모듈 시스템 도입: 모놀리식 구조를 라이브러리 기반으로 전환해 유지보수성 향상

오픈 커뮤니티 중심의 지속 가능한 혁신

• OpenSearch는 Linux Foundation 산하 독립 커뮤니티 기반의 오픈소스 검색 플랫폼
• AWS, SAP, Uber 등 주요 기업과 수천 명의 기여자가 참여
• 벡터 DB 시대에 맞춘 확장성과 투명한 거버넌스를 강조하며, 누구나 참여 가능한 생태계 지향
• 자세한 릴리스 정보는 공식 블로그 및 릴리스 노트에서 확인 가능

[kaydash]

엘라스틱서치가 AGPL 이라 쓰기가 겁나서 계속 오픈서치만 온프레미스로 쓰고있어요

[GN⁺]

Hacker News 의견

• OpenSearch에 대해 이제 막 알게 되었음, Elasticsearch 라이선스 변경 후 2021년에 포크된 프로젝트임, 여전히 Elasticsearch의 대체제로 쓸 수 있는지, 그리고 성능 및 기능 비교에 궁금증을 가짐

  • Kotlin으로 Elasticsearch와 OpenSearch 모두를 위한 클라이언트(kt-search) 유지 관리 중임

    • 대부분의 자주 사용하는 기능에서는 아직 API가 호환됨

    • 벡터 검색같이 포크 이후에 추가된 기능은 예외임

    • search_after 같은 일부 기능이 서로 다르게 동작함, 클라이언트에서 이를 보완해줌

    • 두 제품 모두 SQL 쿼리 기능이 있지만, 구현 방식을 다르게 함

    • 기능 면에서는 Elastic이 여전히 앞섬, 특히 Kibana의 기능이 Amazon 포크보다 풍부함

    • 집계 기능에서도 Elastic이 최근 몇 년간 많은 최적화와 업그레이드에 집중함

    • 성능은 사용 목적에 따라 달라짐, 두 제품 모두 Lucene(오픈소스 검색 라이브러리)을 기반으로 함

    • Elastic Cloud가 AWS에서의 OpenSearch보다 조금 더 좋음

    • 직접 호스팅 및 튜닝하면 두 제품이 매우 비슷해짐

    • Elastic 9.0과 OpenSearch 3.0 모두 새로운 Lucene 버전을 사용, 클라이언트가 이를 모두 지원함

    • 컨설팅 고객 중 오픈소스 라이선스와 AWS 지원 때문에 OpenSearch를 선호하는 경우가 많아짐

    • 레거시 Elasticsearch에서 OpenSearch로 옮기려면 모든 데이터를 다시 인덱싱해야 하며, 라이브러리도 바꿔야 할 수 있음, 꽤 번거로움, 그래서 kt-search를 만들게 됨

    • 옛날 Elasticsearch 2.3 데이터베이스들이 많아서, 각 데이터베이스에 대해 OpenSearch를 병렬로 세우고 서비스 시작 시 데이터 일괄 복사 진행했음, 지금까지 OpenSearch에 대체로 만족함

    • 자세한 설명에 감사 표시와 유용함에 대한 긍정 의견 제시

  • OpenSearch에서 최근에 아쉬웠던 점은 enrich processors 기능이 없다는 것임(문서 링크 제공)

    • 표준 문서 수집 및 검색 기능만 사용한다면 대부분 호환됨
    • 유료 버전에서 제공되던 고급 기능은 호환되지 않거나 누락된 경우가 많음

  • Elasticsearch가 버전 9.0 이상으로 발전했고, OpenSearch보다 27,000개의 커밋이 더 많음

    • 이제는 'drop-in replacement'라고 보기 어려운 상황임
    • 그 중 몇 개가 핵심 기능인지는 모르지만, 두 프로젝트가 얼마나 달라졌는지 알 수 있음

  • 2024년 9월부터 Elasticsearch가 다시 완전히 오픈소스 라이선스(AGPLv3)로 전환했음

    • 이에 대해 예전에 속았던 경험 회상식 의견

    • 여전히 Elastic Search는 오픈코어임, "엔터프라이즈" 기능은 오픈소스 버전에 절대 포함되지 않을 것임, 반면 OpenSearch는 이런 제약이 없음

  • OpenSearch는 '완전한' 대체는 아니지만 거의 호환임, 1.x 버전은 Elasticsearch 7.10과 호환됨

  • 같은 하드웨어에서 OpenSearch가 다소 느림, UI가 필요하다면 주의 필요함, Kibana 포크는 느리고 버그가 많음

    • 실상은 조금 더 복잡함, 두 제품 모두 강점이 있는 워크플로우가 있음
    • 회사에서 두 제품을 포괄적으로 벤치마크함, 결과가 궁금하다면 해당 블로그 포스팅 참조 권유

  • OpenSearch라는 이름은 원래 Amazon의 자회사 A9에서 개발한 개인 검색 결과 집계 서비스에서 유래함

    • 동일한 이름이 여러 의미를 가질 수도 있음을 언급함

• OpenSearch 프로젝트에 대한 안타까움 표명

  • Elasticsearch 라이선스 변경에 반발해 AWS와 함께 만든 반사적 프로젝트임

  • 커뮤니티가 비활성화된 멀티플레이어 게임과도 같아서 오픈소스 프로젝트에 필수적인 활력이 부족함

  • Elastic Search를 대체할 수 있는 회사나 엔터프라이즈 고객을 들어본 적 없음, 아직 검증되지 않았고 장기적인 커밋에 대한 신뢰도 부족

  • 각 SIEM 플랫폼들이 저마다 자체 검색 플랫폼을 만들고 있는 실정임

  • Elastic도 SIEM 플랫폼(Elastic Security) 출시함

  • Elastic이 다시 오픈소스라고 공개했지만, 경영진이 검증되지 않은 포크에 마이그레이션 비용을 들이지 않을 것임, 프로젝트 목적성이 불확실해짐

    • Elastic을 다시 쓰고 싶지 않음, Lucene–Solr–커스텀 확장판 순으로 직접 써왔고 Elastic Search는 AWS 쓸 때만 필요했음, 그래도 OpenSearch 이주 후에는 괜찮게 사용 중임

    • Elastic이 오랜 기간 OpenSearch와 AWS에 의해 경제적으로 타격을 입은 것으로 생각함

• OpenSearch의 knn 및 벡터 기능에 대해 사용하는 사람이 있는지, 실제 대규모 운영에선 어떤지 궁금함

  • OpenSearch 구현은 모르지만, Redis용 벡터 셋을 직접 HNSW 구조로 구현해 본 경험 공유

    • HNSW가 잘 구현되면 상당히 큰 규모에서도 잘 동작함
    • 단일 HNSW 삽입 속도는 초당 수천 건 수준, 읽기는 훨씬 빠름(멀티코어 환경에서)
    • 최초 대량 인서트는 매우 느릴 수 있고, 병렬화가 가능함
    • HNSW가 비효율적인 부분은 메모리 사용량이 큼, 디스크에 저장하면 랜덤 시킹 발생
    • 1024차원 등 고차원 벡터는 quantization(양자화)이 필수임

  • 벡터 임베딩 차원이 높을 경우, knn 자체보다 HNSW 같은 근사 최근접 탐색 방식 추천

    • 자신은 opensearch로 텍스트, 멀티모달 임베딩 및 메타데이터 기반 하이브리드 검색에 활용 중
    • 아직 완전한 대규모 운영은 아니지만, opensearch라 확장성에는 긍정적 기대를 가짐

  • 자신의 경험상 항상 사용 중임, 성능은 임베딩 모델에 달렸고, 인덱스 튜닝이 중요함

    • Lucene HNSW 사용 시 자바 Heap RAM 많이 소모함
    • FAISS나 nmslib 플러그인 사용시 JNI RAM도 신경써야 함
    • 1억 개 벡터 이상 대규모 ANN을 쉽게 확장하는 건 쉽지 않음, 팀의 집중 지원이 필요함

  • 억셉트된 caveat가 있음, 수백만 문서 검색 성능은 양호하지만 KNN 검색 시 전체 임베딩 그래프를 RAM에 올려야 함, 램 관리가 관건임

    • 결과 품질은 결국 임베딩 품질에 좌우됨

• 간단하게 syslog 파싱과 필드 그래프화/검색이 되는 로그 인제스팅 툴을 원하지만, Opensearch 또는 ELK 설정이 너무 까다로웠음

  • Elastic, Opensearch 모두 이런 기본 세팅조차 의외로 어려움에 놀람

    • 모든 것이 설정 중심이라 직접 레시피를 구성해야 함

    • opentelemetry처럼 도움되는 툴이 있지만, 그래도 불편함 존재

    • 두 툴 모두 공식 가이드라인만 따르면 금방 쓸 수 있음, 문제는 커스텀 로직이 필요할 때임

    • 단순 요구라면 logstash 없이도 가능

    • Elastic, opensearch는 앱 메트릭스엔 적합하지 않음, 그럴 땐 prometheus, grafana 권장임

    • Elastic 생태계에 투자하면(beats, logstash 등) 여러 인덱스 템플릿과 파이프라인 구성이 가능함

    • 현재는 dynamic field mapping 덕분에 Elasticsearch에 데이터 입출력이 매우 쉬워짐

    • 성능 유지가 더 큰 고민임

  • Graylog를 시도해봤는지 질문, 본인의 직장에서는 꽤 괜찮게 쓰고 있음

[davidayo]

OpenSearch emerged in 2021 following Elasticsearch's license change, aiming to be a compatible replacement. While largely compatible, especially version 1.x with Elasticsearch 7.10, it's not a complete drop-in solution. Elasticsearch has evolved further, boasting more features and optimizations, particularly in Kibana and aggregations. Performance is application-dependent, with both built on Lucene. Some users find OpenSearch slower and its Kibana forks buggy. Despite Elasticsearch reverting to open source (AGPLv3) in September 2024, some prefer OpenSearch for its truly open-source nature and AWS support. While vector search is a key differentiator, large-scale implementations require careful RAM management. Ultimately, the choice depends on specific needs, with both having strengths and weaknesses. I am working on opensearch with Davidayo https://www.davidayo.com AI powerful tool "AskPromptAI" https://askpromptai.com.