기록하는 공간

MongoDB Day 2022 후기

19 Oct 2022

MongoDB Day 2022

이메일을 보다가 몽고디비에서 컨퍼런스를 개최한다는 소식을 알게 되었다. 반가운 마음에 바로 등록을 했다. 행사 당일에는 우아콘이 시작되기도 하고 저녁에는 구름에서 COMMIT이라는 이름으로 세미나가 있어서 하루 종일 들을 게 많은 날이었다.

그래도 퇴사가 정해진 이후여서 시간 여유도 많았고 참가비도 무료였고 오늘 알게 된거였지만 점심도 제공해주는 행사였다. 몽고디비 코리아에서 이 컨퍼런스를 위해 많은 걸 준비했다는 게 느껴졌다. 그런만큼 발표도 좋았다.

몽고디비에서 다양한 기능을 제공한다는 걸 알게 되었고 그 기능들을 컨퍼런스를 통해 깊게 알지는 못해도 이런 기능이 있다는 걸 알게 되었으니, 이후에 필요하다면 알아볼 수 있을 것이다. 올해가 점점 끝나가는데 남은 시간들도 좋은 컨퍼런스를 많이 참가할 수 있으면 좋겠다.

이번 컨퍼런스의 아젠다는 아래와 같다.

Opening (신재성, MongoDB)

Keynote - MongoDB Developer Data Platform (Michael Cahil, MongoDB)

시리즈 A 스타트업이 검색엔진으로 MongoDB Atlas Search를 선택한 이유(이동욱, 인프랩)

MongoDB 6.0 새로운 기능 (김준, MongoDB)

MongoDB Atlas Search Deep-dive (최근한, MongoDB)

Confluent와 함께 분산된 데이터를 MongoDB로 연결하기(김현수, 컨플루언트)

MongoDB Atlas App Service (김규동, MongoDB)

MongoDB Atlas on AWS와 함께하는 MSA Journey (윤기원, AWS)

네이버의 MongoDB 활용사례(이재웅, NAVER Cloud)

늦어서 오프닝은 듣지 못하고 키노트는 거의 뒷부분만 들었지만 그 이후의 한국어 발표는 다 들을 수 있었다. 발표를 모두 들은 후에 경품 추첨은 아쉽게도 되지 않았지만 그래도 좋은 발표를 들을 수 있어서 좋았다. 모든 발표를 다 정리하지는 못했고 몇 가지만 정리하도록 했다.

MongoDB Day 2022

시리즈 A 스타트업이 검색엔진으로 MongoDB Atlas Search를 선택한 이유

MongoDB 도입 전

  • node.js 기반 레거시 시스템과 신규 node 시스템 함께 사용
  • Amazon Aurora PostgreSQL, Redis 사용
  • 분석, 검색, 로그성, 메인 DB가 하나의 DB에서 운영되고 있었음
  • 복잡한 조건 검색할 때마다 슬로우 쿼리 알림 발생하거나 CPU 튀어오르는 상황 발생
  • 레거시 기술 부채
    • 심리적 불안감
      • 테스트 코드 없음, 코멘트, 문서 없음
    • 높은 진입 장벽
      • 대중적이지 않은 라이브러리
    • 낮은 확장성
      • 하나의 프로젝트에 프론트엔드, 백엔드 같이 있음
  • 4일간 전체 서비스 다운되는 장애 발생
  • 내부 요구사항이 높아짐
    • 검색
    • 데이터 레이크
    • 과거 내역 보관
    • 전체 회원 알림 기록
  • 소수 개발팀, 레거시 개편, 높아진 장애 민감도, 다양한 기능 요구사항

새로운 기술 도입에 대한 고민

  • Amazon Opensearch, Amazon DynamoDB 고민
    • 기존 PostgreSQL, Redis와 새로운 기술 모두 안정적으로 운영하는 것에 대한 고민
  • 최고의 아키텍쳐보다 현재 가장 효율적인 방법을 찾고자 함
    • 비정형 데이터 처리, 검색 엔진, data lake -> MongoDB Atlas Search
  • 신규 아키텍쳐
    • SNS로 멀티 구독
    • SQS로 최종적 일관성 보장
    • Spring Boot로 배압 조절(back pressure)
    • zero payload 이용한 이벤트 순서 보장
    • 기존 서비스와 장애 격리되고 언제든 교체할 수 있는 구조가 됨
  • 결과
    • Amazon Aurora CPU 기존 대비 50% 감소
    • 컨텐츠 선택 전환율이 3.15% 향상
    • 검색 결과 0 비율이 18.82% 감소
    • 검색시 매출 전환율 약 15% 증가

단점

  • 국내 레퍼런스, 커뮤니티 부족
  • ES의 Term Vectors API 처럼 애널라이저고 분석된후 인덱스에 저장된 내용을 확인할 방법이 없음
  • 몽고디비 TestContainers의 검색 미지원으로 격리화된 단위 테스트 작성 불가능
  • 단어가 어떻게 tokenizing 되는지 확인할 수 있는 화면 미지원

장점

  • 적극적인 지원
  • MongoDB korea 팀과 함께 만드는 국내 레퍼런스
  • NodeJS & MongoDB 조합의 상대적 익숙함
  • 높은 SLA (99.995%)
  • 형태소분석기 (CJK Analyzer, Nori Analyzer, 한영 혼합 경우를 위한 multi analyzer 구성 가능)

스타트업은 기술 부채 관리가 중요하다

최소한의 도구로 다양한 문제를 일정 수준 이상으로 해결 가능하다

MongoDB 6.0의 새로운 기능

  • 규모에 따른 성능
    • initial sync의 4배 성능 향상
    • prometheus와 통합
    • 샤딩 환경에서 connection storm에 대한 기능 향상
    • 스토리지 엔진 개선(multi tenancy)
  • 데이터 이동성 및 글로벌 활용 범위
    • 전 세계에서 아틀라스 사용 가능
    • 하이브리드 환경, dr 혹은 hot-standby 환경에서 클러스터간 동기화 지원
    • mongodb relational migrator 지원
  • 사용 사례의 확장(workload 확장)
    • atlas search의 기능 향상 (교차검색, facet)
    • 전용 분석 노드/컬럼 인덱싱을 활용한 분석 워크로드에 대한 더 많은 유연성 제공
    • 시계열 컬렉션에 대한 기능 향상 - 보조 인덱싱 강화
    • Atlas Data Lake / Atlas SQL를 활용한 분석 데이터 수명 주기 확장
  • 개발자 워크플로우와 통합
    • Atlas Serverless 인스턴스 GA
    • Atlas Data API GA
    • New Atlas CLI Release
    • MongoDB Compass 기능 향상
    • Atlas K8s Operator GA
  • 보안, 데이터 프라이버시
    • 감사 로그에 대한 암호화
    • FLE 2.0
  • Time Series Collection

MongoDB Atlas Search Deep-dive

  • 검색 / 풀 텍스트 검색
    • 모든 데이터를 검색하고 검색어와 얼마나 일치하는지에 따라 순서가 매겨진 결과 목록을 효율적으로 반화하는 기능
    • 점수를 기반으로 한 결과를 보여줌
  • 검색 기능 만드는 두 가지 방법
    • DB engine
      • 미리 정의된 쿼리를 통한 운영 DB 조회
      • 식별자를 통한 조회 / 정확한 결과
    • Search engine
      • 식별자가 아닌 일반 언어를 통한 검색
      • 사용자가 무엇을 검색할지 미리 알 수 없음
  • 사용자의 요구를 만족시키려면 두 가지 방법 모두 필요
  • 두 가지를 합쳐서 구현하기 위해서
    • 독립된 별개의 모듈이므로 원활하게 동작하고 연동하기 위한 개발 필요
    • 서로 동기화되어야 함
    • 예외, 오류 처리 필요
    • 최초 구성, 업그레이드, 모니터링, 보안 등의 시간과 비용 필요
  • Atlas가 제안한 방식
    • DB Engine에 완벽하게 관리되는 Apache Lucene engine 추가
    • 개발자의 생산성 상승
      • DB engine과 Lucene engine을 같은 query API, driver 통해 수행
    • 데이터 아키텍쳐의 단순화
      • 데이터, 스키마가 변경돼도 자동화된 데이터 동기화 기능 제공 가능
    • 완벽하게 관리되는 구조
  • Atlas Search
    • Atlas Cluser 생성
    • 데이터베이스와 컬렉션 생성
    • Search Index 구성
    • $search stage 사용
  • Replica set 환경
    • 각각 mongot, mongod 가짐
    • 장애 발생할 때도 유연한 대응 가능

Apache Lucene

  • Analyzer
    • 주어진 document를 읽어, 검색 가능한 term 반환
  • Inverted Index
    • analyzer가 생성한 term에 대해 인덱스를 만들고 각각의 term을 가진 document에 대한 목록을 유지
  • Score
    • 사용자가 검색한 질의가 얼만큼 연관있는지 표현하는 지표
    • 사용자의 결과는 score 기반으로 정렬됨
  • Analyzer 동작 방식
    • Tokenizing
      • 공백 기반으로 토큰 분리
    • Normalization
      • 소문자로 변환
      • 문장 부호 제거
      • 불용어 제거
    • Stemming
      • 단어의 여러 분사 형태를 찾아냄
  • 질의를 할 경우
    • 검색어의 term으로 document를 찾게 됨
  • 점수 계산
    • tf: search term이 document에서 얼마나 자주 등장하는지
    • idf: search term이 전체 document에서 얼마나 자주 등장하는지
    • 점수 커스터마이징 기능 제공 (boost, constant, function 등)

Features

  • autocomplete
  • hangul Analyzer
    • lucene.korean (lucene.cjk의 별칭)
      • text를 bigram으로 분리 (2음절씩 분리됨)
      • stopword 가짐
      • 영문/숫자 글자가 띄어쓰기 없이 붙어있을 경우, 원하는 bigram으로 분리되지 않을 수 있음
      • search index 크기가 상대적으로 커짐
    • lucene.nori
      • 세종 코퍼스 기반
      • 문자열을 형태소로 나눔
      • 품사를 통해 필터링
      • 신조어에 대해서 정확한 형태소 분석 실패할 수 있음
      • 정확하지 않은 검색 결과도 나올 수 있음
      • 상대적으로 적은 공간 차지
  • highlighting
  • fuzzy matching
    • 오타가 있어도 검색할 수 있음
  • faceting
  • 다양한 데이터 타입
  • synonyms
  • 커스텀 scoring

고려사항

  • 인덱스 구성
    • 검색이 꼭 필요한 필드만 인덱스 선언
    • multi analyzer는 각각 선언한 analyzer 개수만큼 인덱스를 가지게 되므로 필요한만큼 유지하는 것이 좋음
    • nGram 방식은 텍스트가 길수록 인덱스가 커지므로 대안으로 edgeGram
    • lucene의 제약으로 20억개 이상의 인덱스 엔트리 생성 불가. sharding으로 제약을 피할 수 있음
    • storedSource 옵션을 잘 사용하면 mongod 접근없이 mongot에서 결과 반환 가능(Covering index와 비슷한 기법)
  • $search stage
    • $search와 $match / $sort를 같이 사용하면 심각한 성능 저하 발생 가능
      • $match는 filter operator 사용
      • $sort는 커스텀 스코어링 사용
    • shard 환경에서 $search는 모든 샤드로 전파됨
    • highlight 기능은 테스트나 데이터를 확인할 때 주로 사용되는데 필요없으면 제거

Related Posts