리뷰

[세미나] 2024 MongoDB.local 후기

nooblette 2024. 9. 14. 15:49

목차

    배경

    지난 9월 3일 MongoDB.local Seoul에 당첨되어 세미나를 다녀왔다. 적어도 국내에서 가장 널리쓰이는 NoSQL인 MongoDB에서 주최하는 세미나인 만큼 방향성과 활용 사례를 가장 가까이 느낄 수 있다는 생각에 신청했고, 운이 좋게 당첨되어 다녀올 수 있었다. 내용 뿐만아니라 모든 개발자가 열정적으로 세션에 참여하여, 질문을 주고받으며 공유하는 환경 속에서 동기부여와 열정 또한 얻어갈 수 있었다.

     

     

    세션은 AWS, 구글을 비롯한 국내 기업의 활용 사례와 Mongo DB의 제품 소개로 이루어져 있었는데, 국내 기업 사례를 제외하고는 대부분 영어로 진행되었다. 물론 동시 통역을 제공하고 있어 이해하는데 큰 어려움은 없었다. 참여 상품으로는 AWS 티셔츠, 구글 클라우드 후드티, MongoDB 네임택 등 다양한 상품을 받았다.

    기존 RDB와 Mongo DB

    기조 연설과 함께 본격적인 세션 소개에 앞서 기존 RDB와 Mongo DB의 차이점을 소개하였다. 컨퍼런스에서 소개한 내용에 따르면 RDB는 딱딱하고 유연하지 못하다. 또한 구축하기 어렵고, 스케일 업이 까다롭다. 반면 MongoDB Document 모델로 유연하게(Flexible) 스키마를 설계할 수 있고, 스케일 업이 용이하다.

     

    또한 Mongo DB의 앞으로 방향성을 간략하게 들을 수 있었다. 시간이 갈수록 웹 애플리케이션을 비롯한 IT 서비스에서는 다양한 요구사항 (OLTP, Time series, FullTextSearch, Realtiem analytics, Stream processing, Vector Search)이 등장한다. 이에 따라 MongoDB는 우아하고 간단하게 대처하고자 한다. 결국 Mongo가 제공할테니, 개발자는 구체적으로 구현을 알 필요가 없다는 것이다.

    Mongo 8.0

    다음으로는 신규 버전인 Mongo 8.0의 핵심 영역을 위주로 주요 변경 사항을 설명하였다. 보다 개발자 친화적이고 유연한 개발 환경, 애플리케이션이 요구하는 보안과 확정성을 제공하기위해 노력하였으며, 생성형 AI 애플리케이션을 위한 데이터 환경을 제공하는 것에 많은 노력을 기울이는 듯한 인상을 받았다.

     

    Mongo DB에 대한 깊은 이해와 사용은 아직 경험한 적이 없어 기존 버전과 비교했을때 두드러진 발전과 모든 용어와 개념을 제대로 이해하지는 못했지만 간략하게 그 내용을 정리해보면 다음과 같다.

     

    Optimal performance (고가용성, 고확장성 클러스터 성능)

    Command Path와 Query Optimizations 데이터베이스 읽기/쓰기 최적화를 달성했다고 하였다. 또한 Express 단계를 도입하여 단일 인덱스에 대해 성능 향상을 도모하였고, TC malloc을 도입하여 18% 개선을 달성하였다고 한다.

     

    Workload management during increased usage and spikes (부하 발생시 관리 개선)

    시스템의 트래픽이 급증하면 관리자와 개발자는 그 이유를 파악하고 대응해야한다. 몽고는 이 상황에서 어떻게 빠르고 정확히 상황을 인지하고 개발자와 관리자에게 알림을 보낼지 고민한다. 이에 따라 8.0부터는 Mongo Compass GUI 툴에 데이터베이스 부하 증가와 원인 분석을 위한 신규 Namespace Insights와 Query Profiler 탭을 추가하였다. 각각의 역할은 다음과 같다.

     

    • Namespace Insights : 컬렉션별 쿼리 latency에 대한 분석을 볼 수 있다.
    • Query Profiler : 문제가생기는 쿼리와 Query Shape를 보고 쿼리에서 무슨일이 일어나고 있는지 파악할 수 있다.
    • Query Shape : 해시값을 통해 수행중인 쿼리를 bson 형태로 확인
    • Query Shape를 통해 비용이 많이 드는 쿼리를 빠르고 정확히 인지하고 대응할 수 있다.
    • Query Shape의 Reject filter를 보고 Mongo에 가는 부하 자체를 차단한다.

    기존 Index filter의 동작 방식도 다음과 같이 개선되어 Persistent Query Settings를 제공한다.

     

    • (기존) index filter는 서버를 재기동하면 다시 세팅해야해서 유지관리하기 어렵다.
    • (8.0) query shape 별로 인덱스필터를 설정하고 서버를 재기동해도 유지된다.

    Faster and more flexible scaling (유연하고 비용 효율적인 샤딩과 수평 스케일 업)

    기존보다 50배 더 빠르게 리샤딩이 가능, 몇시간만에 대규모 컬렉션을 리샤딩을 지원한다. 또한 리샤딩을 진행하는 동안 기존 작업에 영향을 주지 않는다. 특히 이전 버전과 비교했을 때 샤드키를 변경하지 않고도 리샤딩할 수 있도록 개선되었다.

     

    Atlas Stream Processing으로 이벤트 기반 애플리케이션 구축하기

    주요 활용 사례로 먼저 평소에 관심이 있던 이벤트 기반 애플리케이션에 대한 세션을 들었다. 최신 애플리케이션은 이벤트 스트림이 리얼타임으로 처리되며, 이 리얼타임 처리가 곧 최신 앱의 핵심이다. 광고 추천, 인스타 피드, 넷플릭스 추천, 해외결제시 바로 확인 전화(익일에 메일로 전송되는 카드사도 많음) 등 실시간 스트리밍은 다양한 형태로 활용되는데, 요지는 이 때 발생하는 스트리밍 이벤트 데이터는 document에 최적화 되어있다는 것이다.

     

    결국 이 상황에서 Mongo DB의 목적은 '스트리밍을 잘 처리하도록 DB가 먼저 나서주면 안돼?' 이다. 쉽게 말해 이벤트 기반 애플리케이션을 구축하면서 카프카를 잘 쓰기 위해서 Mongo DB에서 많은 기능을 지원해주겠다는 것이다. 다른 세션에서도 강조했지만 Mongo DB의 스트리밍 데이터 처리와 연산 기능은 Kafka를 대체하기 위한 것이 아닌 Kafka와 Mongo DB가 상호 보완하여 더욱 완성도 높은 애플리케이션을 구축하기 위함이다.

     

    Atlas Stream Processing

    실시간으로 들어오는 스트리밍 이벤트 데이터를 지속적으로 가공하여 병합한다. 실시간 이벤트 데이터는 연속적이고 지속적으로 들어온다. 지속적으로 데이터가 들어오면 지속적으로 검증한다.(e..g. DLQ) 그리고 지속적인 병합이 이루어진다. 이 때 카프카에서 모든 처리를 하면 데이터 변환을 비롯한 연산이 번거롭지만, Mongo는 JSON 형태를 바로 받을 수 있다. 예를 들어 카프카에서 연산 로직을 심으려면 백엔드를 거쳐야한다. 하지만 몽고로 바로 스트리밍 처리가 가능하다. 따라서 간단한 연산은 DB 레벨에서 지원하고 이를 통해 개발 생산성을 크게 향상할 수 있다.

     

    Schema validation options($validation)

    스트리밍 데이터는 Document 형식이고 fliexible하니 Mongo가 적합하다. (statueful이기도 하고) 추가적으로 스트리밍 데이터는 중구난방으로 들어온다. 즉, 정해진 형식이 없다. 이때 mongo의 schema validation을 사용하면 꼭 지켜야하는 데이터 형식만 검증하여 Collection에 넣고 그 후에 비즈니스 로직을 태울 수 있다. (validation에 실패하면 DLQ에 넣는다.) 결국 목적은 개발 생산성을 향상하는 것에 있다.

     

    언론사의 디지털 전환: 한겨레의 MongoDB Atlas 도입 사례

    다음으로는 언론사인 한겨레 신문의 MongoDB Atlas 도입 사례 세션을 들었다. Mongo DB Altas를 왜 채택했고, 어떻게 도입했으며, 어떤 성과를 낳았는지 가장 잘 이해할 수 있었다. 

     

    한겨례 신문에서는 서비스를 제공하며 데이터베이스 변경 요구 사항 자주 발생했고, 최근 미디어 데이터가 다양화되는 어려움을 겪었다고 한다. 기존에는 RDB를 사용했었는데 요구사항 변경에 따라 매번 테이블 구조를 변경하고 서비스를 재구성하는데에 너무 큰 리소스가 들어 어려웠고, IT 기업이 아닌 만큼 적은 전문 인력으로 리소스를 투입하는데 많은 한계가 있었다고 한다. 이런 상황에서 Schema 구조가 없는 Mongo DB는 많은 이점을 주었다고 한다.

     

    또한 언론사 특성상 예상치 못한 부하(특종, 속보 발생시) 와 예상 가능한 부하(e.g. 선거 기간)가 발생하면서 특정 시점에만 트래픽이 급증되었고 이에 따라 유연한 스케일 업 지원이 요구되었다. 이런 환경에서 Saas 형태로 제공하는 Mongo DB Atlas가 많은 도움이 되었다고 한다.

     

    마지막으로 뉴스 요약, 뉴스 추천 등 미디어 데이터를 다양한 형태로 제공하기 위한 노력하고 있다고 하며 세션을 마무리지었다.

     

    MongoDB Atlas, 야놀자의 데이터 관리 패러다임을 바꾸다.

    야놀자는 왜 Mongo DB Atlas를 도입했고, 어떻게 쓰고있고 어떻게 확대할 것인지 엿볼 수 있었다. 야놀자는 현재 Public cloud에서 서비스별로 RDB를 구축하여 MSA를 운영 중에 있다. 이때 RDB는 DBA가 직접 중앙 관리형태로 운영/관리하여 전문화된 운영과 빠른 장애 대응이 가능하고 성능, 보안, 비용 최적화를 지원한다. 반면 NoSQL은 개발자가 직접 관리 및 운영한다. 운영과 관리에 발생하는 비용 최적화를 포기하는 대신 성능향상을 도모하는 목적인데 표준화된 사용 방식이 없으므로 이슈 발생시 담당자가 아니라면 대응에 어려움이 발생했다.

     

    이에 따라 전문 DB 엔지니어가 RDB, NoSQL 통합 운영을 시도하는데에 있어 직접 운영/관리, 성능과 보안, 비용최적화가 가능한 NoSQL 환경을 제공하려는 시도로 MongoDB Atlas를 채택하였다. 여러 환경의 NoSQL DB를 중앙관리체계의 Atlas 환경으로 이관하여 전문적인 엔지니어가 RDB와 NoSQL을 중앙관리체계로 안정성과 효율성 향상을 도모한다는 것이다.

     

    앞으로는 서비스별로 파편화된 aws nosql 환경을 Atlas로 마이그레이션을 진행하고 있다. 그 후 멀티 클라우드 환경(aws, gcp, azure)에 Mongo DB를 도입하여 다양한 서비스로 확장하여 (현재는 대부분 AWS, 사내서비스는 azure, 빅데이터는 gcp에서 운영 중) 용도에 맞는 다양한 서비스가 동작하는 다양한 퍼블릭 클라우드에서 동작하도록 지원하는 것을 목표한다고 한다.

     

    쏘카에서 MongoDB Atlas Search로 쉽고 빠르게 검색엔진 구축하기

    쏘카는 왜 Atlas Search를 선택해서 검색 엔진을 구축했고, 어떻게 사용하고 있는지 들을 수 있었다. 먼저 쏘카에서 숙박 서비스를 신규로 런칭하면서 다양한 숙박 서비스로부터 비정형화된 숙소 데이터를 받아와야한다는 요구사항이 발생했다고 한다. (이때 서비스를 채널이라고 한다.) 하지만 채널에서 제공하는 데이터 형태는 서로 달랐고, 통합 DB에는 다양한 채널로부터 데이터를 받아와 적재해야하는데 그 데이터의 형태가 중구난방이였다. 또한 뛰어난 성능을 제공하는 검색 엔진 필요했다.

     

    이런 요구사항에 있어 Mongo DB는 Flexible schema를 제공하여 유연한 데이터 관리를 가능케한다. 또한 샤딩을 통해 수평 확장(스케일 업)지원하고 대규모 데이터 처리와 처리를 여러 서버로 분산 가능하다. 마지막으로 복잡한 데이터 조회에 편리한 연산을 제공하고 빠른 조회를 제공하여 트랜잭션 볼륨이 큰 애플리케이션에서도 적합하였다.

     

    검색 엔진으로는 MongoDB Atlas Search를 선정하였는데 그 이유로 먼저 Mongo DB 데이터에 고급화 검색을 제공하고 있어 정렬, 랭크, 필터링, 인덱싱을 통한 성능 향상 등 연산이 간단했다고 한다. 또한 이를 통해 시스템 아키텍쳐 단순화도 가능했다고 한다. 기존 아키텍쳐는 DB ↔ Data pipeline ↔ Search를 거쳐가며 설정과 운영이 복잡해서 데이터 관리에 대한 부담이 증가했다. 하지만 MongoDB Atlas Search를 통해 복잡한 아키텍쳐를 통합하고 하나의 일관된 환경에서 운영을 할 수 있었다.


    또한 주소 검색, 지역 검색(애월, 강릉, 제주 등) 다양한 검색 조건이 요구되는 상황에서 신규 검색 조건이 추가될 때마다 매번 확장하기 어려웠고, 채널별로 상이한 호텔 평점, 숙소 유형 등을 대응하는데 RDB로는 한계가 명확했다. 이에 따라 쏘카에서는 다양한 채널로부터 비정형 데이터를 스프링 배치로 수신받고, 인덱스와 쿼리를 설정하여 빠른 검색 성능 제공하였다고 한다.

     

    이벤트를 적용하는 숙소만 필터링해달라는 신규 요건이 발생한 적이 있었는데, 이 때 Collection에 검색용 필드만 추가하고 aggregate에 해당 필드를 추가하여 빠르게 문제를 해결할 수 있었다고 한다. 또한 숙소의 지도 정보를 제공해야했는데, 이때 Mongo에서 제공하는 Geo Type으로 손쉽게 구현이 가능했다고 한다.(Geo Data는 채널로부터 받아온다.)

    마지막으로 MongoDB Atals UI로 간단히 테스트도 가능 했으며 모니터링 툴도 제공하여 모니터링이 용이했다고 한다. Datadog으로 성능 확인 p90일떄 15ms, p99일때 18ms를 달성했다고 한다.

     

    후기

    Mongo DB를 메인 데이터 저장소로 사용한 적이 없어 모든 발표 내용을 완전히 이해할 수는 없었지만, 어떤 상황에서 어떻게 Mongo DB를 사용할 때 적절한 결과를 낳을 수 있는지 사례를 간접적으로 경험할 수 있었다. 결국 문제 해결 전략과 결과를 경험할 수 있어 만족스러웠다.

     

    AWS, Google, Samsung 등 다양한 기업에서 소개하는 사례를 들을 수 있어 좋았고, 그러한 사람들이 모인 환경에 있다는 것 자체만으로 큰 열정과 동기부여를 얻을 수 있었다. 다음에도 기회가 주어진다면, Mongo DB를 비롯해서 다양한 기술 컨퍼런스에 참여하고자 한다.

    저작자표시