Post

MongoDB Local Seoul 2025 후기

Posted Updated
MongoDB Local Seoul 2025 후기

미루고 미루다 연휴를 맞아 MongoDB 2025 후기를 올립니다

기억에 남는 것

기조연설

  • 8.0에 새로 도입된 쿼리 차단 필터, 클러스터 전체에 대한 ReadTimeout
  • 8.0에서 샤드키를 선택하지 않고도 샤딩 가능
  • Resharding이 필요할 때 최대 50배 더 빠르게 가능 -> 피크 수요를 위해 확장/축소 원활히 가능
  • 8.0에서 데이터를 암호화해서 저장하고, 암호화된 데이터를 검색할 수 있는 기능
  • IntelliJ 플러그인 지원 -> 네이티브 MongoDB
  • VSCode + Copilot 통합 쿼리 작업 가능

기업용 검색 : MongoDB를 통해 하이브리드 검색을 도입하는 방법

  • 8.1 이후 버전에서 $rankFusion 를 통해 벡터검색+전문검색이 가능함

MongoDB 데이터 모델링의 기초와 방법론

  • RDBMS는 데이터 모델링 -> 워크로드 정의 하는 반면, MongoDB에서는 워크로드를 먼저 정의한 뒤 데이터를 모델링한다.
  • 워크로드란 어플리케이션이 데이터에 말을 거는 방식으로, 어플리케이션이 데이터에게 말을 거는 방식. 가장 자주 던지는 질문이 무엇인지 / 데이터는 얼마나 자주 바뀌는지 등을 의미한다.
  • 워크로드는 아래와 같이 분류된다
    • 쓰기 많음
    • 읽기 많음
    • 빠르게 읽어야함
    • 저장 데이터가 엄청 많음
    • 심플함이 중요함

머니워크: MongoDB Atlas와 함께 롤러코스터를 타다

  • Query Profiler 보는 습관을 가지자

Action Item

  • MongoDB Atlas 모니터링 습관들이기
  • IntelliJ, VSCode + Copliot 쿼리 작업 해보기
  • MongoDB MCP 사용해보기
  • 워크로드 분석하는 습관 가지기

작성한 내용

기조연설

AI 시대 해결해야 할 문제 -> 얘네를 해결해야 트랜스포메이션 가능

  • 빠른 개발
  • 덜 복잡
  • 기술 부채 제거(현대화)

MongoDB 8.0

  • 현대적인 DB가 할 수 있는 역할
  • 8.0 allocator는 몽고 성능을 예측가능하게 함. DB는 메모리를 많이 쓰는 구조. 메모리 관리에서 작은 비효율이 발생해도 성능이 저하됨. => 새 얼로케이터로 메모리를 안정적으로 관리
  • 모든게 예측가능한건 아니니 신속하게 대응해야 함.
  • 쿼리 차단 필터 : 과도한 리소스를 사용하는 쿼리를 차단 가능
  • 클러스터 전체에 대한 Read Timeout : 제어 불가능하게 하는 쿼리가 전체 성능을 떨어트리는걸 방지

Scalability 확장성

  • 임베디드 구성 서버
  • Move Unshareded Collections
    • 샤드키를 선택하지 않고도 확장 가능
  • Faster Resharding
    • 리샤딩 필요할 때 8.0 에서 최대 50배 빠르게 가능. 따라서 피크 수요를 위해 확장/축소를 하던 원활하게 가능

보안 Security

  • Queryable Encryption : 쿼리 가능한 암호화
  • 필드 암호화해서 전송/저장/사용중에도 안정적으로 가능
  • 팀도, MongoDB도 프로바이더도 데이터를 볼 수 없음
  • 암호화된 데이터에서 정확히 일치하는 값을 검색 가능 -> 민감한 고객 정보를 보호 가능
  • 8.0에서는 이를 range쿼리까지 확장. 쿼리 과정에서 암복호화 불필요

Performance 성능

  • 가장 자주 사용하는 연산
  • Reads : 저지연의 read를 쉬지않고 앱에 전달
    • cmd 명령이 신속하게 도달해야함
    • 8.0에서는 명령실행경로를 간소화함
    • 지연에 민감한 instruction을 37% 줄임
    • expression path : 단순쿼리를 위함. 빠르고 클러스터링된 인덱스, 모든 필드에 대한 매치를 지원
  • Writes : 대다수의 레플리카셋에
    • 병렬처리 지원. 훨씬 더 빠른 인식을 대부분의 Writes에 지원
  • Expressive Queries 를 위한 최적화 : 고급쿼리
  • Block Processing : 시계열 데이터
    • 한 번에 하나씩 도큐먼트 처리하는 대신에 배치로 처리함. 벌크 접근법 사용해서 비싼연산을 배치. ㅓㄴ체에 분산시켜서 효율성 증가.
    • 이동 평균 계산, 데이터 롤업 등….8.0으로 옮겨가면 지연 줄이고 처리량 늘릴 수 있음
  • 벤치마크 테스트 해보면
    • Readonly : 36%
    • 혼합 : 32%
    • bulk insert : 56%
    • timeserise : 200% 블록프로세스 때문에 아주빨라짐

아틀라스

  • 50%빠른 수직확장
  • 5배빠른 오토스케일링
  • 독립 샤드스케일링
  • 아틀라스가 탁월한 가용성~

툴

  • AtlasCLI
    • 도커컴포즈도 가능하고 CMD명령 가능함!
    • 전문검색을 랩탑에서 가능!!
  • VSCode + Copilot 통합되어서 쿼리작업 가능!!! -> 퍼블릭 프리뷰에 있음
  • IntelliJ : 네이티브 MonogoDB 가능! IntelliJ For Java
    • 오… MongoDB for IntelliJ Plugin

MongoDB MCP Server

  • 코드, 몽고DB 디플로드 다리역할….
  • 윈드서프, 커서로 IDE로 개발할 때 MCP로 MongoDB 클러스터와 연결하여 IDE만으로 가능
  • Chat과 인터렉션해서…
  • 맥락 인지적이라 완결된 MonogDB 쿼리 생성 가능
  • Agentic System : MCP 사용해서 액션트리거 실시간으로 가능

AI Application

  • LLM 모델 : 임베딩, 전문검색, 리랭킹(교차평가로 신뢰도, 정확도 높은 답을 제공)
  • MongoDB + Voyage AI : 최첨단 임베딩, 리랭킹 모델~.
    • 벡터, 운영 워크로드가 독립적으로 확장됨.. 최고 수준의 임베딩 모델 및 리랭킹~

모든 상호작용은 신호이자 행동할 수 있는 기회입니다~

  • 개인화 피드(Personalized Feed)
  • 자동셧다운
  • 실시간 재고 업데이트 -> 카프카 같은 스트리밍 이용 : 신호 이용하려면 스트리밍 처리 기술이 필요 -> 기존 스트리밍 프로세싱 기술은 경직화된 스키마… -> Atlas Stream Processing
  • 도큐먼트 모델 활용해서 지속적인 처리를 통합된 경험으로 처리…

현대화

  • 코드베이스 분석….
  • 테스트…. 처음부터 생성해야함
  • Convert 모놀리스 분해하는거나 코드 분해하는거나…
  • Migrate : 새 아키텍쳐에 맞게 변환해서 마이그레이션 해야함….

Lift and shift is not modernization

  • 진정한 현대화는 아키텍쳐, 코드베이스, 테크스텍 전체를 재편하는 것
  • 즉, 비즈니스와 함께 진화할 수 있는 기반을 구축
  • 지난 2년간 새 접근방식 구축…. 현대화로 혁신 실현

Agentic Framework / Tools&AI Agents -> 플랫폼 구축해서 몽고 현대화 할 수있도록 ~

기업용 검색 : MongoDB를 통해 하이브리드 검색을 도입하는 방법

LLM을 잘 활용하기 위해서는

  • 올바를 정보 제공
  • 정보의 저장과 검색 : LLM을 활용해 실용적인 RAG, Agentic AI 구축의 필수조건
    • 올바른 맥락 전달
    • LLM 환각 감소
    • 고품질의 유용한 답변 생성 가능

검색의 진화

  • ~1990 : SQL, 키워드 매칭 - 정확학 키워드 일치. 랭킹이나 맥락 정보 없고 대용량 처리 시 성능 저하
  • 2000~2010년대 : Full-Text 검색 - 역색인 구조 기반 빠른검색(ElasticSearch … ) -> 검색속도가 획기적으로 빨라지고 부분매칭&자동완성 같은 편의기능, Facet 검색등의 필터링 => 키워드 의존적,… 맥락 파악은 어려움
  • 2010년대 후반 ~ : AI기반 벡터 검색 - 의미 기반 유사성 검색. ANN 알고리즘 이용해서 자연어 검색 쿼리, 맥락과 의도 이해, 멀티모달 데이터 지원.. 높은 컴퓨팅 비용과 임베딩 전처리 필요
  • 발전 배경
    • 데이터 복잡성 증가, 비정형 검색 데이터베이스 필요성
    • 각 방법의 공존 -> 검색 목적에 따라 적합한 방법이 상이함. 완전한 대체보다는 역할 분담… (검색 목적에 따라 SQL, 풀텍스트, AI기반 등을 적절히 활용)

“지난달에 샀던 . 그러닝화랑 비슷한 제품 추천해줘”

  • 에이전트가 여러 방식을 도구로 사용해야함
    1. DB SQL : 사용자 구매 이력 정보
    2. Full-Text 검색 : 사용자가 구매한 운동화와 유사한 운동화들 리스트를 검색
    3. AI 기반 벡터 검색 : 의미적이고 추상적인 검색 추천 가능(ex: 페가수스 같은 입문용 러닝화..) 유기적 통합이 핵심

복잡한 데이터 환경의 현실…

  • 다양한 시스템이 얽혀있음.. 이런 시스템 하나하나가 각각의 방식을 사용함. 새 DB 추가할 때 마다 새로운 방식을 익혀아함

MongoDB Atlas

  • 하나의 인터페이스로 개발 단순화하고 혁신 가속화
  • 아틀라스서치
  • 벡터서치…

풀텍스트와 벡터를 통합하면 맥락파악하고 정확한 정보를 전달 가능

  • FullText 검색 : 정확한 키워드 매칭 기반 명시적ㅇ ㅛㅇ어 및 스펙 검색
  • 벡터 검색 : 의미 기반 유사성 검색,자연어 표현 및 개념 이해, 맥락 파악
  • 하이브리드 검색 : 각 검색의 장점을 활용
    • $rankFusion : MongoDB 8.1+ => 하이브리드 검색을 쉽고 빠르게. Aggregation 파이프라인에서 제공. 여러 종류 검색을 통합 가능 (match, vectorSearch, goeNear, search … ) 다양한 방식을 서브파이프라인으로 제공 + 같은 종류의 검색도 통합가능함(vectorSearch+vectorSearch 등)
    • rankFusion 이전에는 -> 수동 결과 병합하고, 랭킹 로직 직접 구현해야 함. 개발부담도 크고 실수도…. 최적화되지 않은 랭킹 로직….유지보수 어려워지고 복잡한 구현……
    • rankFusion : 중복결과 자동 제거 및 RRF알고리즘(랭킹 통합 로직) 내재화 / 단순한 파이프라인 구성 / 다양한 검색 기능 조합 지원

AI시대에는 다양한 검색방법이 각각의 역할을 하면서 공존한다 MongoDB Atlas는 하나의 플랫폼에서 모든 검색기능을 통합제공함 $rankFusion으로 하이브리드 검색 구현 간소화

Agentic RAG를 활용한 AICC 구축 사례

AICC

  • 상담 코드 추천 / 상담 요약 : AI가 대화를 분석해서 상담 코드를 추천하고 주요 내용 요약
  • 실시간 지식 추천 / 검색 : 고객 대화 이력 기반으로 상담에 필요한 지식을 추천하고 검색함

기술적 허들

  • Naive RAG : 저수준의 RAG… 제한적인 정확도. 비정형문서로 시작하여 마크다운 형태 파일을 임베딩모델로 다차원횡렬로 표현 -> 이 때 부터 고객이 쿼리 던지면 유사도 검색으로 LLM 청크로 답변 가능
  • 원본문서를 AI가 이해할 수 있도록 파싱하는 작업 (도표를 이해할 수 있도록 하고, 자주 수정됨)
    • HTML 변환 (순서도는 mermade로 변환)
    • MD 변환 : html이 좀 더 구조화된….
    • 더 극악무도한 케이스 (색깔표시, 그림 등) -> 데이터 파이프라인 설계(지속적 업데이트 때문에) / 파싱도 전통적인 OCR모델 말고…
    • Font layout 조정 -> PDF변환(이미지랑 텍스트가 구분되니까) -> 텍스트와 Image 따로 분리해서(AI가 판단할 수 있도록) -> 콘텍스트+이미지 합쳐서 -> HTML, MD로 변환하여 몽고에 넘김 Advanced RAG
  • Live RAG 대비…
  • Contextual Retrieval : 청크를 벡터화 하기 전에 전체 문서에서 맥락상 어떤 역할을 하는지..

에이전틱하다(Agentic Something)

  • AI가 어떤걸 스스로 결졍할 때 & 결정한걸 실행할 때

Agentic RAG

  • Supervisor 에이전트가 상단에 존재하고, 각각의 스페셜 에이전트(각각의 역할을 스페셜하게 수행할 수 있는 애들) -> 슈퍼바이저가 스페셜에 전달….
    1. Supervisor는 Long-term 메모리 내의 요금제 카탈로그를 참고하여 Reasoning
    2. 질의에 따라 역할이 부여된 스페셜 에이전트로 라우팅
    3. 개별 스페셜 에이전트는 어떤 툴을 사용할지 추론 후 콘텍스트 가져와서 답변 생성

MongoDB는 어떻게 사용하는지

  • 메인DB
  • 롱텀메모리, 숏텀메모리 저장소로도 몽고디비가 라이브러리 잘 되어있음
  • Document 내의 Vector값을 하나의 Field로 취급하므로 원본 데이터와 벡터 값 릴레이션을 유지할 필요가 없음
  • 하이브리드 서치 등 강력한 프레임워크 인테그리에션으로 별도 구현 필요 없음
  • 아틀라스 : Performance Advisior의 Index Recommendation Feature 기능~ 쿼리기반으로 인덱스 추천해주는거….

집중하고 있는거

  • Evaluation
  • Long/Short term memory
  • multi agent

MongoDB 데이터 모델링의 기초와 방법론

정규화는 MongoDB로 설계를 할 때 적절한 해결책이 아님 어떻게 해야 최적의 모델인지, 어떤게 좋은 디자인인지?

  • NoSQL을 위한 모델링이 필요한 이유
    • 우리는 왜 모델링을 할까 -> 여러 제약 조건에 대응 / 다양한 이해관계자와 소통 /문서화
    • 제약조건 : 물리적 제약(절대불변 -> 서울-뉴욕간 거리 차이 등…) / 하드웨어제약(개선가능) / 소프트웨어제약(지속변화)
    • 다양한 이해관계자와 소통
    • 문서화 : 합의와 분석의 결과를 기록하는데 그치지 않고, 다양한 상황에서의 빠른 대처를 위해 필요
    • 여러 직면한 제약을 해결하기 위해 모델링을 한다…
  • MongoDB를 위한 데이터 모델링 방법론
  • 스키마 디자인 패턴 적용

워크로드는 각 오브젝트를 콜렉션으로 그룹화하는 최적의 방법을 결정함

  • 워크로드 : 어플리케이션이 데이터에게 말을 거는 방식. 가장 자주 던지는 질문이 무엇인지 / 데이터는 얼마나 자주 바뀌는지 등
  • 프로젝트(워크로드)에 대한 분석 및 분류
    • 쓰기 많음
    • 읽기 많음
    • 빠르게 읽어야 함
    • 저장 데이터가 엄청 많음
    • 심플함이 중요함

MongoDB를 위한 데이터 모델링 방법론

  • RDBMS : 데이터 모델링 -> 워크로드 정의
  • MongoDB : 워크로드 정의 -> 데이터 모델링

데이터 모델링 방법론

  1. 요구사항(Requirements) 분석 : 우리 어플리케이션의 엔티티 추출. 주요 등장인물을 찾기. 메인 엔티티를 찾기.
  2. 워크로드(Workload) : Operation 목록 작성.
    • write, read…. 모든 operation이 동일하게 중요하지는 않음. 한정된 자원안에서 최고성능이 나도록 선택과집중
    • 핵심 operation 기준으로 어떤 워크로드가 중요한가 선정.
    • 중요도가 높은 operation을 분석(쓰기인가 읽기인가) -> 숫자로 세부 내용을 정의(하루에 nnn건 작업이 nn분 간격으로 발생… nn년 저장됨 등등)
    • 워크로드 분석은 모델의 설계 기준선(baseline)을 만드는 과정. 이 기준이 명확해야 미래의 변화에 흔들리지 않음. 기준이 명확하면 감이 아니라 숫자로 답할수 있음.
  3. 관계(Relationship) : 엔티티를 어떻게 묶고 나눌것인가.
    • 비싼 조립을 할 필요 없음
    • 애플리케이션에서 함께 사용되는것은 DB에서도 함께 저장해야함
    • 레퍼런싱(Referencing) : RDB의 Join
    • Embedding : 관련된 데이터를 하나의 DB에 한번에 저장 -> 어플리케이션은 이 문서 하나만 읽으면 원하는 정보를 한번에 내보낼 수 있음.
    • 어플리케이션에 따라 가이드라인 기준을 보고 의사결정 진행
  4. 패턴(Pattern)
    • 스키마 디자인 패턴 구조 : 계산 / 그룹핑 / 생명 주기 / 다형성 / 관계
    • 디자인패턴은 필요할때만, 스키마는 단순하게 하는게 좋다.
    • 가장 좋은 스키마는 단순한 모델이다…..
    • 어려운 문제를 풀기 위한 필살기로만 남겨두고 남발하지 말자

자주 함께 사용되는 정보는 임베딩해서 추가

Computed Pattern

  • 읽기 시점에 비싼걸 쓰기 시점에 옮겨서…. 쓰기 시점에 작업을 더 하자

Archive Pattern

  • 오래된건 별도의 아카이브로 옮겨두자.
  • 장기로 저장해야하면 비싸니까~

성공적인 시스템은 반드시 변화를 겪게 되며

Key Takeaways

  • 모델링 필요성
  • 모델링 방법론
  • 스키마 디자인 패턴 적용

<고객사례> 코코네

Migration(Backup&Restore) 준비

마이그레이션 후마주친 현상

  • M50 오픈 이후 IOPS 증가 ->.Aggregate 함수 이슈
  • Cursor 값 증가 -> 고객들의 지연시간….

서비스 안정화를 위한 긴급 대응

  • IOPS 변경 (3000 -> 6000 -> 8000) : 아틀라스에 대한 이해와 노하우가 부족해서 EC2 대응 방식을 지속적으로 고려
  • 세컨더리 추가 생성
    • 밀어올리는과정에서 동기화 . 할때 리소스를 사용해서 동일한 이슈가 발생함.
  • 마지막 선택 : 아틀라스 티어 업그레이드 (M50 -> M60 -> M80에 32CPU 128RAM… ) 서비스는 안정화 되었는데 비용폭탄
    • CPU와 IOPS를 잡아야한다 -> 리팩토링

리팩토링

  • 아이템 하나하나를 SeqNo로 관리하면서 상태관리를 함(선물,교환,착용/해제/폐기) -> RDB스타일
  • Reference 를 Embedding 모델로 리팩토링
    • UserId와 ItemNo 기준으로 그룹핑
    • 새롭게 생성한 콜렉션은 Active User의 Item Data 만 관리
  • Application Refactoring
    • Aggregation 파이프라인제거

UserItem Collection Re-Modeling

  • userId와 itemNo 하나의 복합인덱스로 리모델링
  • Collection 구조 변경 처리 : FacadeService 추가하여 2개 콜렉션으로 동작 분리 /. ㅣㄴ규 콜렉션은 액티브 유저만 처리…
  • Query 리팩토링
  • cache

Refactoring 결과

  • Normalized Process CPU => M80 32CPU

Atlas로 전환해야 하는가?

  • XaaS(X as a Service)는 언제나 비용이 이슈임
    • 풀managed DBaaS잉ㄴ 아틀라스도 예외는 아님
    • 비용이슈가 해결되면 사용하지 않을 이유는 없음. 고사양 Atals Tier 사용하면 최적화 튜닝은 필수적
  • 코코네에서 Atlas 사용하는 이유
    • DBA가 아닌 서버 개발자들이 Atlas Dashboard를 통해 DB 상태를 접검할 . 수있다는 점.
    • 운영 코스트가 거의 제로에 가깝고 사용이 쉽다는 장점.

Atlas Migiration 생각해 볼만한 것들

  • 컨설턴트의 제안이나 조언은 성배가 아님 -> 좋은 이야기만 함
    • 제일 중요한, 서비스 내부 구조에 대해서는 아예 모름
    • 서비스를 제일 . 잘아는사람은 담당 개발자
  • 리팩토링에서 정말 중요한건 DB가 아니라 어플리케이션
    • DB성능개선은 버전업과 시스템 스케일업으로는 한계가 명확
    • DB성능 개선이 되더라도 비즈니스 로직이 같이 개선되지 않으면 지속가능한 서비스를 만들어내기 어려움
  • 시뮬레이션, 테스트 결과 과신 X -> 특히 대용량 환경에서는…
    • 성능지표들이 예상과 다르게 움직일 수 있음

<고객사례> 성능 최적화 실전 사례

올거나이즈 : NLU 기술에 집중해서 기업이 AI를 활용해서 다양한 문제점을 찾을 수 있도록

왜 MongoDB, Atlas를 사용하는가?

  • 빠른실험/유연성/운영
  • Index Usage

스트림 프로세싱

  • AWS 애저에 지역 센터마다 워커노드 배치할 수 있는 옵션을 제공함
  • MongoDB Atlas 에서 네이티브 스트림처리
  • 스트리밍 전용 옵션을 통해 aggregation 프레임워크를 활용해 확장
  • 이벤트를 처리하기 위한 아키텍쳐를 구성할 . 때아키텍쳐를 간소화하는게 목표
  • 이벤트 처리하는 매커니즘을 만든다 할 때, 인스턴스 만들고 파이프라인 형태로 등록… 이벤트를 전달받고 뭘 하고 그런 연결 체인들을 간단하게 만든다

스트림 프로세싱을 할 수 있는 데모가 있음

<고객사례> 머니워크 : MongoDB Atlas와 함께 롤러코스터를 타다

  • MongoDB Atlas : Schemaless, Simple, Performant, Cloud
    • SaaS형으로 쓰기 때문에….
  • DB Tier를 M140 에서 M60, 피크시간의 ReadQuery Latency를 1s에서 1ms로

MongoDB Atlas Ignite Package

  • 리포트… DB를 어떻게 사용하고 있고(Health Check), 다양한 것들을 해결책으로 제시해주심

Index Tuning(Performance Advision & Query Profiler)

  • 쿼리가 인덱스를 잘 타도록 변경하거나 추가
  • 계속된 관찰이 필요하기 때문에 생각보다 쉽지 않음
  • 어떤 쿼리가 비효율적인지 범인을 찾아내줌
  • Query Profiler : 재앙의 씨앗이 보임. MongoDB를 사용하면 이 페이지는 꼭 하루에 한 번 이상 봐라

MongoDB Cluster Version Update

  • 생각보다 유의미하게 빨ㄹㅏ짐

Covered Query

  • 읽기 쿼리 수행하면… 인덱스를 타고 -> 인덱스로 찾은 데이터의 리턴할 정보를 찾는 2차 과정이 필요함
  • 2차 과정을 아예 하지 않음 : 쿼리에 필요한 모든 정보가 인덱스에 모두 포함되어 있음
    • Projection을 넣어줘서….
  • Field to Field 매칭에는 아주 탁월함.

Archiving

  • DB에 있는 내용을 모두 S3에 카피한뒤에 삭제한다
  • S3에 있는걸 MongoDB 쿼리 랭귀지로 뽑을 수 있는걸 아틀라스에서 제공함
    • 잘 접근하지 않는 히스토리성 테이블에 제공…
    • 쿼리는 느리지만 쿼리가 가능하긴 함

Analytics Node

  • 분석용 노드 : BI노드에 쓰면 되는데!!!!! -> 석우님께 제안
  • Atlas에서 Analytics Node 제공함
    • 사용자가 사용하는 일반 노드에 비해 가격도 1/3 수준이라고 함

In-Memory Caching

  • 작은데 많이 사용되는 쿼리들
  • 쿼리들중에 상수형태를 띄는 쿼리들 (global configuration…)
  • 매번 mongoDB를 읽을 필요가 없음
  • ECS - MongoDB 사이 캐시레이어 있으면.. 그 때도 도움됨

AI Code Review For Index

  • 인덱스를 안타는 쿼리들
  • PR이 추가되는 쿼리에 대해 인덱스 안탈 가능성이 높은걸 AI 에이전트로 추가할 수 있다…
  • 찾아보면 많이 나옴ㅋㅋ

Query Profiler

  • 이 화면을 매번 하루에 한번씩 모니터링해라.
  • 못보던 색상이 나오면 주의해라

벡터서치

  • 디자이너가 이미지를 생성했을 때 등록하면 언제든 이미지를 검색할 수 있는것 -> 벡터서치로 이미지를 검색 가능
  • 검색엔진을 잘 쓰게 하기 위해 넣는 순간 이름을 만드는 것 까지…
  • 이미지가 필요할 때 다시 만들지 않아도 가져올 수 있는 기반을 추가
  • 편의성 측면에서 다른 DB 압도함

<고객사례> 구글클라우드 MonogDB

사용자가 많아질수록 문제가 많아짐

Query Insights

  • 느리게실행되는 DB작업 모니터링 도구
  • 왜? : 쿼리 성능 문제에 대한 가시성을 제공
  • Use Cases
    • 생산 성능 급증… 문제있는 쿼리 찾아내기

Operation Rejection Filters

  • 특정 쿼리 형식의 작업 거부
  • Behavior
    • 해당 쿼리 형식의 모든 수신 쿼리를 거부
    • 자원 소모가 많은 쿼리가 추가적인 문제를 일으키는걸 방지
    • 시스템 정책 세밀한 제어 : 사용량 급증하는 비정상적인 상황 발생 시

모든걸 종합해 보면

  1. 실시간 메트릭을 확인해 성능 문제 파악
  2. 쿼리 인사이트를 사용해 문제 쿼리 확인
  3. Operation Rejection Filter를 사용해 쿼리 실행 안되도록 조치
  4. 한숨 돌리고 근본 원인에 대해 조치

Compound Wildcard Indexes

  • 알려진 필드와 와일드카드(알려지지 않거나 중첩된 필드용)를 포함하는 단일 인덱스
  • 왜? : 복잡한 스키마에서도 다중인덱스 없이 효율적인 쿼리 수행
  • UseCases
    • 타겟팅 광고 : 브랜드 X기기 사용자를 식별하고

Queryable Encryption

  • 필드를 암호화하면서 expressive query를 지원. 날짜 . 및숫자에 대한 등호 및 범위쿼리 지원
  • 개인정보 보호하고 규정 준수 요건 충족
  • UseCases
    • 민감한 개인 식별 정보 보호
    • 원시데이터 노출 없이 타겟팅된 제안
  • 방법
    • key management system구성
    • 암호화된 스키마 정의
    • 암호화된 컬렉션 생성
      • 7.0은 equal만 가능. 8.0부터는 range 검색 지원

수평 확장 기본 개념 : Sharding

  • 8.0부터는 샤드에 대한 기능 개선됨
  • Atlas에서도 샤딩 가능….

Performance

  • 8.0 vs 7.0 성능… => TimeSeries에서 특히 200%이상 빨라졌다~
  • 업그레이드 하세요~

GoogleCloud가 어떻게 개발 성능을 가속화 할 수 있을지

  • MongoDB는 좋은 선택이다 / MongoDB + Vertex AI와 연계했을 때 새로운 혁신을!!

GoogleCloud

  • AI 전체 End-to-End하는곳은 구글뿐임ㅎ 어디가 병목이고 어디가 개선해야하고를 할 수 있는게 구글임.
  • 데이터쪽 : 운영DB(MongoDB)/분석DB(BigQuery)
    • MongoDB가 현실세계를 . 잘반영했기 때문에 운영하기 좋다….
  • Atlas는 플랫폼을 자유롭게 넘어갈 수 있다. -> 운영하기 아주 좋다.

메리츠 FDS

금감원 데이터 제공받으면 수상거래 탐지하여 바로 알랏 보내는 등 즉각적인 대응을 구축함 데이터를 수집함에 있어 프로젝트 초기에 어떤 어려움이 있었는지

  • 어떤 규모로 수집할지 ….
  • 이상탐지 데이터가 기간? 이. ㅏㄹ라서
  • 고객 데이터 실시간 분석해야 하고,대량데이터 안정적 처리해야함. 자동 failover, transaction 처리하는데 요구사항 충족이 어려움
  • NoSQL DB중에서도 왜 MongoDB였을지
    • 스키마가 자주 변하는 FDS에서 NoSQL이 필요했고
    • 안정성이 중요한데, 타 NoSQL은 국내 지사가 없거나 레퍼런스가 없고… MongoDB는 지사가 있음 PSR
  • 스키마 유연성

PSS 아키텍쳐

  • Atlas는 이 구조로 아키텍쳐가 배포됨.
  • MongoDB EA 운영 : Ops Manager를 활용
    • MongoDB EA에서 MongoDB Agent로 무상으로 제공함.

MongoDB EA 도입 이후 -> 운영 효율성 증가!

  • 비용 50% 절감
  • 무중단 서비스

레거시 애플리케이션 현대화하는 생성형 AI 기반 팩토리 접근 방식

MongoDB가 생각하는 진정한 현대화란

  • 현대화 = 이사가기
  • MongoDB의 근본적인 기술적 강점은 문서모델(document model)
  • Atlas : AI를 위한 데이터 플랫폼

AI를 어떻게 활용해서 현대화 프로그램에 적용했는지

  • MongoDB Modernization Factory
  • 기존의 현대화 프로젝트는 오래걸리고 고비용….

현대화 팩토리라는 프로젝트가 어떤거고, 어떻게 협업하는지

  • 현대화는 종종 한번의 리프트 앤 시프트 전환으로 끝남… -> 레거시에서 뉴 레거시로
  • 지속적이고 반복적으로 할 수 있도록 해야함
  • 진정한 현대화를 위해 AI가 대규모 현대화를 실현 가능하도록 함
  • GPT, 클로드 등의 LLM을 이용해 특정 코드 작성을 요구하는데 -> 테스트케이스 없고 50줄 이상이면 신뢰할 수가 없음…
ETC
후기 컨퍼런스 MongoDB
This post is licensed under CC BY 4.0 by the author.