[김인범의 '지금은 오픈소스 시대'] NoSQL의 선두주자, MongoDB (3화)

안녕하세요, 김인범입니다. 

지난 2화(http://blog.skcc.com/3225)에 이어 MongoDB에 대한 마지막 이야기를 진행하도록 하겠습니다.

MongoDB 편을 진행하는 과정 동안 MongoDB의 release update가 이루어져 이번에는 MongoDB 3.4 버전에 대한 이야기를 잠깐 하고 넘어가도록 하겠습니다.

8. Release 3.4

기존 release 업데이트에 비해 3.4는 그렇게 큰 변화가 없었습니다. 하지만 그 와중에도 나름의 의미 있는 변화는 존재했으며, 이에 대해 간단하게 살펴보겠습니다.

 

Multi-model done right
다양한 model이 하나의 데이터베이스에서 가능해짐
: document, graph, key value, search with faceted navigation
1) graph processing
  : graph 또는 tree 구조 데이터의 처리를 가능하게 만들어 줌
  : 이는 데이터 간의 간접적인 관계를 파악하는데 용이하게 만들어 줌

2) faceted navigation
  : 관련이 깊은 카테고리로 묶어 사용자가 검색 조건을 제시하기 전에 선택할 수 있는 범위를 좁혀주는 기능 (검색, 분석 애플리케이션에서 사용됨)

Mission-critical apps
강화된 보안과 더불어 support platform 범위 증가로 인해 mission-critical deployments를 가능하게 함 

Modernized tooling
operation, 분석 등을 위한 툴의 진화. 이처럼 눈에 띌만한 기능 추가는 없었지만, 기존에 존재했던 다양한 기능들에 대한 강화가 이루어졌습니다. 또한 모니터링, 분석 등에 쓰이는 툴들에 대한 전반적인 개선이 이루어져 엔터프라이즈버전에 대한 메리트를 조금씩 확장해나감을 확인할 수 있었습니다.

8. MongoDB 활용 사례 (국외)

MongoDB는 미국을 중심으로 그 활용이 확산되었으며, release 2.x 에 접어들면서 다양한 활용사례가 등장하기 시작했습니다. 앞서 말씀 드린 제품의 특징의 영향을 받아 주로 소셜 서비스를 제공하는 업체 위주로 사용이 되다가 이제는 금융, 정부기관, 게임 등 전 산업에 걸쳐 널리 사용되고 있습니다. 처음에는 부가적인 서비스, 내부 직원 전용 서비스 등 비중이 작은 서비스부터 시작되어 이제는 많은 곳의 주요 서비스 용도로 사용되기에 이르렀습니다.

SourceForge는 MongoDB의 대표적인 적용 사례입니다. SourceForge는 "Project Summary", "File Browser", "Download" 등과 같은 페이지에 대부분의 부하가 집중되었는데, 이러한 백엔드 저장소로서 MongoDB를 적용해 사용 중입니다.

해당 시스템에서는 주로 읽기(read)가 많이 발생하며, 간헐적으로 Develop으로부터 변경(update)이 발생하며, MongoDB의 도입은 이러한 처리의 성능을 높이게 해주었습니다. 

MongoDB는 데이터 복제와 백업을 편하게 해 주었고, 스키마의 자유로운 특성 때문에 상대적으로 잦은 마이그레이션을 방지해 줬습니다. 확장성 또한 향상되었으며, 무엇보다 비약적인 성능의 향상을 경험할 수 있었습니다. (서버 별 초당 75개 이상의 동적 페이지 요청 처리) 

워싱턴포스트(WP) 역시 대표적인 MongoDB use case reference 입니다.

워싱턴포스트는 MongoDB가 포함된 MEAN stack (MongoDB, ExpressJS, AngularJS, and NodeJS) 기반에 ElasticSearch 까지 더한 아키텍처를 구성하였습니다.

워싱턴포스트 내에서 MongoDB를 사용하는 주요 기능(앱)에는 Pagebuilder(washingtonpost.com), Arc 퍼블리싱 앱, Comments API, 추천(recommendations), 비디오 플레이어 등등이 존재합니다.

이외에도 FIFA Online 3(EA Sports), ebay, github, MetLife, 골드만 삭스 등 많은 회사들은 분야를 막론하고 대량의 데이터를 효율적으로 다루기 위해 MongoDB를 채택하고 있습니다.

8. MongoDB 활용 사례 (국내)

국내에서는 다음(지금의 다음카카오)등을 비롯한 소셜 서비스를 제공하는 업체들을 중심으로 MongoDB의 활용이 확산되어 갔습니다. 

다음의 MyAgora 서비스는 시간이 지날수록 빈번하게 발생하는 insert와 기하급수적으로 늘어나는 data에 대한 효과적인 처리를 위해 MongoDB를 도입한 바 있습니다. 도입 전 후보 군으로 MongoDB, Cassandra, Couchbase 3가지를 고려하였으며, 언어와 성능 등을 고려하여 최종적으로 MongoDB를 선택하게 되었습니다.

LG유플러스는 상용 그룹웨어 서비스에 MongoDB를 적용 한 바 있습니다. 그룹웨어 서비스는 100명 이하의 중소기업을 대상 고객으로 메일, 메신저, 전자결재, 게시판 등의 기능을 제공합니다.

그룹웨어 서비스에서 생성되는 데이터 중 알림로그, 쪽지, 그리고 인증로그를 처리하기 위해 MongoDB를 도입하였으며, 이는 발생 빈도가 높고 큰 저장 용량을 필요로 한다는 공통점이 있습니다. 

별도의 샤딩 구성이 없는 심플한 3-노드 복제 세트 구성으로 이뤄졌지만, 초기에 구성한 서비스 부하를 처리하는 데는 문제가 없는 형태입니다. 확장이 용이하기에 서비스 증가량 정도에 따라 충분히 추가 구성 역시 가능합니다.

이외에도 다음카카오를 비롯한 다양한 소셜 서비스 업체를 비롯하여 통신, 금융 분야에서도 MongoDB 도입 또는 도입 검토 등의 단계를 진행하고 있습니다.

8. Tips for MongoDB

다음은 MongoDB를 사용하면서 알게 된 점, 느낀 점들에 대해 정리한 내용입니다. 독자 분들이 MongoDB를 사용할 때 알아두면 좋은 점들 위주로 정리해 봤습니다.

1) CPU & Memory는 가능하면 높은 사양으로 구성할 것 

MongoDB는 확장이 용이한, 즉 scale out이 잘 어울리는 제품이지만, 실제 scale up과 scale out 중 선택을 할 수 있는 상황이 발생한다면 우선 순위는 scale up으로 가져가는 것이 좋습니다. scale up이 성능적인 측면을 가시적으로 높이기에 좋으며, scale up을 충분히 한 뒤에 scale out을 시도해볼 것을 권장합니다.

 

2) release 업데이트 별 버전 관리가 필요함(특히 API)

MongoDB는 6~8개월에 한 번씩 release 업데이트가 발생합니다(이 주기가 항상 정확한 것만은 아닙니다). release 업데이트 발생시에 가끔씩 기존에 존재하는 API가 사라지거나 이름이 바뀌는 등의 변화가 발생할 수 있습니다. 이럴 경우 기존에 MongoDB의 API를 사용하는 소스 코드가 존재할 경우 바로 error를 발생시키게 되므로 release 업데이트에 따른 변화내용을 충분히 살펴볼 필요가 있습니다.

 

3) 복제는 필수, 샤딩은 충분한 고민이 필요 

데이터의 안정적 보관을 위해 복제는 반드시 필요합니다. 반면 샤딩은 빅데이터를 효율적으로 처리하기에 좋은 수단이지만, 샤드 키가 제대로 설정되지 않으면 특정 노드에 부하가 몰리게 되어 오히려 장애를 유발시키는 요인이 되기 쉽습니다. 따라서 샤딩은 충분한 고민 뒤 설정할 것을 권고합니다.

 

4) 데이터에 대한 이해가 없다면, shard key는 포기할 것 

앞서 3)에 말씀드린 내용과 연결되는 부분입니다. 샤딩은 shard key를 기준으로 발생하며, 이러한 shard key가 잘못 설정되면 균등하지 않은 샤딩(데이터 분배)이 발생하지 않습니다. 따라서 실제로 다루게 되는 서비스 데이터에 대한 이해가 제대로 되어 있지 않다면 shard key는 포기하는 것이 더 나은 선택입니다.

5) 성능을 극대화하고 싶다면 동적 스키마를 배제할 것 

MongoDB의 최대 장점은 스키마가 없다는 것이며, 이는 곳 유동성을 갖는 스키마임을 의미합니다. 이러한 ‘동적 스키마’는 다루는 데이터의 범위를 넓혀주지만, 이러한 데이터를 저장하고 가공하는 단계에서 수많은 유동적인 스키마 변경이 발생합니다. 이는 하나하나가 매우 사소할 수 있지만, 규모가 큰 시스템에 있어서는 성능을 결정하는 중요한 요소가 될 수도 있습니다. 따라서 미세한 성능까지 챙겨야 하는 시스템이라면 이러한 동적 스키마는 최대한 자제하는 것이 좋습니다. 

8. 마치며 

개인적으로 MongoDB를 처음 발견하고 쓰기 시작한 2011년부터 현재까지 지속적으로 MongoDB를 사용해오고 있습니다. 그 과정 동안 수많은 발전과 변화가 있었으며, 이러한 변화는 제품의 수준을 비약적으로 향상시키는 데 일조했습니다. 단순히 제약이 없는 데이터베이스(혹은 데이터스토어)의 수준을 넘어 이제는 다양한 오픈 소스와 연계될 수 있는 나름의 생태계로 발전을 시도하고 있습니다. 

초기의 MongoDB는 그 어떤 제품과도 비교하기 어려울 정도로 부족한 것이 많았지만, 이제 어느덧 NoSQL 중 가장 뛰어나고 안정적인 제품으로 인식되고 있습니다. MongoDB社(과거 10gen社)의 지속적인 개선 노력과 더불어 Big Data시대에 적합한 제품의 특징, 그리고 이러한 제품을 다양하게 활용하고 있는 주요 레퍼런스 등의 요소가 결헙 되어 이제는 메인스트림으로의 진입을 시도하고 있습니다. 국외에 비할 수는 없지만, 국내에서도 이러한 도입 시도는 지속적으로 이루어지고 있습니다. 서비스 성격에 맞게 잘 활용할 수 있다면, MongoDB 역시 단순히 big data 연구나 소셜 데이터 수집&저장 뿐만 아니라 기존에 RDBMS가 수행하던 역할 역시 일정 수준 이상 대체할 수 있을 것이라 생각됩니다. 

지속적인 발전을 이루고 있는 MongoDB의 앞으로의 모습을 기대해 보겠습니다.