▲

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

 (opensearch.org)
10P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 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 시대에 맞춘 확장성과 투명한 거버넌스를 강조하며, 누구나 참여 가능한 생태계 지향
  • 자세한 릴리스 정보는 공식 블로그 및 릴리스 노트에서 확인 가능
▲
GN⁺ 1일전  [-]
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를 시도해봤는지 질문, 본인의 직장에서는 꽤 괜찮게 쓰고 있음

답변달기