MongoDB Internals

(주)카디날정보기술

MongoDB 모니터링 툴인 mongostat의 웹 버전 mongoowl을 출시하였다. mongoowl은 1초 단위의 라이브 모니터링과 HTML5 기반의 동적 그래프 시각화를 지원하며, 모바일 디바이스를 통한 서비스가 가능한 any device를 지원한다. mongoowl은 2013년 7월 신소프트웨어 대상 추천작으로 전자신문에 아래와 같이 개제되었으며, 무료로 다운로드 받을 수 있다.

출처 : 전자신문 유선일 기자

카디날정보기술(대표 김지연)은 실시간 그래프 차트 기반의 모니터링 툴 `몽고아울(mongoowl)`을 출품했다.

분산 데이터베이스(DB) 몽고DB를 이용해 프로그램을 개발하면 실시간으로 변동사항을 파악해 개발·설계에 반영할 수 있다. 별도의 웹 컨테이너 없이 스탠드 얼론(stand alone) 형태로 구동된다. 실시간으로 주요 모니터링 요소를 대시보드에 그래프로 출력한다.

몽고아울은 대규모 분산환경 모니터링이 아닌 몽고DB 단일 데몬에 대한 실시간 모니터링용 제품이다. 적은 리소스로 구동 가능하고 직관적인 그래프로 구동 상황을 확인할 수 있다.

WAR 파일 실행만으로 간단히 설치할 수 있고, 설치 후 웹 브라우저에서 실행하는 간소한 절차를 통해 주요 모니터링 현황을 파악할 수 있다. 확인하려는 몽고DB 노드(node)의 IP와 포트 정보 및 사용자 권한 입력을 위한 인트로 페이지, 해당 노드의 모니터링 항목을 확인할 수 있는 대시보드 페이지로 구성된다.

대시보드 페이지에서는 인서트(INSERT), 쿼리(QUERY), 업데이트(UPDATE), 폴트(FAULT) 정보를 아이콘과 수치로 확인할 수 있다. 하단에 실시간 그래프를 출력해 직관적으로 현재 상태 정보를 파악할 수 있다.

[주요특징]

▶OS:JDK 호환 가능한 모든 OS

▶몽고DB용 실시간 그래프 차트 기반 모니터링 툴

▶(070)8255-6461

[김지연 대표 인터뷰]

“국내 개발자들이 몽고DB 적용을 주저하는 것은 우선 새로운 DB를 공부해야 한다는 부담감 때문입니다. 또 몽고DB는 콘솔 명령만 제공하기 때문에 지속적인 화면 모니터링을 통한 튜닝 포인트 확인이 어렵다는 문제도 있습니다.”

김지연 카디날정보기술 대표는 이 같은 문제를 해결하기 위해 종전 `몽고버드(mongobird)`라는 모니터링 전문 솔루션을 개발했고, 개발과정에서 얻은 핵심 기술과 가시화(Visualization) 기술을 접목해 이번에 몽고아울을 출시했다고 말했다.

김 대표는 “개발자들은 지속적으로 프로그램 개발 현황을 확인해 업무 효율을 극대화할 수 있다”며 “몽고DB의 특성을 직관적으로 파악할 수 있고 몽고DB 내부 구조도 보다 쉽게 파악 가능하다”고 말했다.

카디날정보기술은 개인 사용자나 연구 목적이면 무상으로 몽고아울을 제공하고 상업용으로 이용할 때는 별도의 라이선스 계약을 맺어 보급할 방침이다. 또 몽고DB 내부구조 연구 결과를 공유하기 위해 운영 중인 블로그 `몽고DB 인터널스(MongoDB Internals)`의 영문 서비스를 시작해 해외 시장 진출을 위한 기반을 다질 계획이다.

김 대표는 “이 같은 전략으로 우리의 높은 기술력을 인정받을 수 있을 것”이라며 “몽고DB 개발사인 텐젠(10gen)과 기술 파트너십도 맺을 예정”이라고 말했다. 이어 “수년 동안 몽고DB 연구개발(R&D)에서 전문적인 노하우를 쌓아 왔다”며 “일종의 `몽고DB 에코 시스템`이라고 할 수 있는 제품 라인업을 갖출 계획”이라고 덧붙였다.

글 : 이승용

MongoDB가 NoSQL의 강자로 자리잡기 시작하면서 장단점에 대한 기사를 종종 읽게 된다. 하지만, 세상만사 모든 일이 똑같지만 장점보다는 단점이 두각 되는 것은 어쩔 수 없는 이치인 것 같다. 2012년 초반에 PASTEBIN에 포스팅된 ‘Don’t use MongoDB’에도 MongoDB를 사용하면 안 되는 이유가 개제된 적이 있고, 거의 1년 만에 Bloter.net에서 다시 기사화된 것을 보면 MongoDB도 전세계적으로 유명한 데이터베이스가 되었구나 하는 생각이 든다.[1] 그리고, 1년 전에 논의된 내용이 아직도 유효한지는 모르겠지만,[2] 급변하는 IT 기술에 맞추어 볼 때, 필자는 오픈 소스 기술을 대하는 우리들의 자세가 문제가 있지 않나 생각해 본다.

대부분의 유명한 오픈 소스 기술들은 처음에 그들이 주장하는 기술이나 개념은 매우 놀라울 정도로 앞선 것들이다. 이러한 기술들이 개발자들에게 흥미를 유발시키고, 그리고 그 기술이 모든 것을 해결해 줄 수 있는 컴컴한 바닷가의 등불과 같이 안도의 길을 보게 한다. 기대가 크면 실망도 크기 마련이다. 해당 기술에 대한 정확한 분석이 있기 전까지 그들이 말하는 내용을 자기의 상황에 맞추어 모든 것이 해결된다고 판단해 버린 개발자는 신을 믿듯이 맹신하게 되고, 그 기대감이 자신의 기대치에 미치지 못한다고 판단하면, 홈쇼핑에서 물건을 잘 못산 것처럼 끔직한 비평가가 된다.

‘그들은 거짓말을 하고 있다.’ ‘그들이 다 된다고 했는데, 내가 원하는 기능이 아니다.’ 라는 식의 평가 없는 비평은 오픈 소스에 대한 바른 평가가 될 수 없다. 오픈 소스의 정신은 도전과 올바른 비평을 통해 발전의 방향을 공유하는 것이다. 만약 그들이 분석을 통한 비평으로 오픈 소스 기술을 올바르게 사용할 수 있는 방법을 연구하였다면, 전혀 새로운 기능들을 볼 수 있을 것이다. 오픈 소스는 상용화된 제품과는 달리 모든 기능들이 잘 정형화된 문서로 남지 않는다. 그렇다면, ‘어떻게 분석할 것인가?’ 바로 소스를 보는 것이다. 오픈된 소스를 통해 그들이 지원하지 않는 방법을 알아내고 이를 회피하는 방법 또는 보강하는 방법을 통해 새로운 기술을 습득하는 것이다.

그리고, 자신이 알아낸 기술을 인터넷을 통해 공유함으로써, 다음 버전에서 더 좋은 제품이 될 수 있도록 지원할 수 있어야 하며, 또는 그러한 기술을 통해 새로운 사업 아이템을 모색하는 것도 좋을 것이다. 그러면, 비평하는 개발자는 초기 맹신논자처럼 무조건 적인 맹신이 아니라, 분석 있는 날카로운 비평가가 될 수 있고, 자신의 실력이 올라가고 있음을 알 수 있을 것이다.

필자가 바라본 MongoDB는 다른 어떤 제품보다도 매혹적인 부분이 충분히 있으며, 또한 10gen이 왜 이렇게 만들었을까 하는 부분도 보인다.[3] MongoDB는 다른 솔루션과 마찬가지로 아무런 준비 없이 바로 대규모 시스템에 도입할 수 있는 제품은 아니다. 충분히 분석하고 연구함으로써 자신의 시스템에 맞게 구축할 수 있는 최상의 오픈 소스임에는 틀림없다.

글 : 이승용

MongoDB 2.4 버전에서 우리가 주목할 점은 hashed-index와 자비스크립트 엔진이 구글의 V8 엔진으로 변경되었다는 점이다. Hashed-index에 대해서는 저번 글에서 간단하게 살펴보았고, 이번에는 자비스크립트 V8 엔진에 대해서 살펴보기로 한다.

MongoDB의 자바스크립트 엔진은 버전 2.4가 발표되기 전에 모질라의 SpiderMonkey 엔진을 사용하고 있었다. 한가지 우리가 집고 넘어가야 할 점은 버전 2.4 이전에 자바스크립트 엔진을 V8로 사용하지 못하는 것은 아니었다는 점이다. 실제로 10gen은 MongoDB의 자바스크립트 엔진을 SpiderMonkey와 V8 둘 중에 하나로 빌드 할 수 있도록 제공하고 있었다.

이 두 자바 스크립트 엔진의 가장 큰 차이점은 멀티 쓰레드와 속도이다. SpiderMonkey 엔진은 멀티 쓰레드를 지원하지 않지만 V8 엔진보다 빠르고, V8 엔진은 멀티 쓰레드를 지원한다. 10gen은 MongoDB 버전 2.4 이전까지 SpiderMonkey를 유지하고 있었던 것은 쓰레드 환경보다는 자바 스크립트 엔진의 빠른 속도가 더 중요시 되었기 때문으로 보인다. 실제로 MongoDB는 $where, mapreduce, group, eval 문으로 작성된 질의를 자바스크립트 엔진을 이용하여 처리하고 있기 때문에, 무엇보다 빠른 속도의 자바스크립트 엔진이 필요했을 것이다.

하지만, 10gend은 MongoDB의 락 시스템이 global lock에서 database lock으로 변경되고, 또 앞으로 collection lock으로 변경될 것이라는 로드 맵을 보여주고 있다. 락 시스템의 변경은 데이터베이스에서 병렬 처리를 위한 가장 핵심이 되는 항목이다. 락 범위가 크다는 것은 락 선점 시간이 커지기 때문에 동시 처리가 줄어들게 되는 반면, 자원을 독점하여 빠른 처리를 할 수 있다. 하지만, 멀티 코어에 따른 하드웨어의 발전은 범위 큰 락에 의한 CPU 활용도가 떨어지는 현상을 유발하게 되었고, MongoDB도 락 범위의 축소와 함께, CPU 활용도를 늘리는 정책으로 선회한 것으로 보인다.

필자의 개인적인 의견으로도, V8 엔진을 사용하는 것이 바람직하다고 보인다. 자바 스크립트로 동작하는 MapReduce를 수행할 때, 많은 시간을 걸리는 MapReduce 작업이 끝날 때까지 질의를 수행하지 못한다는 것은 끔직한 일이기 때문이다. 인터넷 자바스크립트 엔진의 성능 비교 사이트의 자료를 보면 SpiderMonkey가 V8보다 약 30% 정도 빠르다고 나온다. 하지만 실질적인 테스트를 수행해 보면, 15% 정도의 차이가 있다. 하지만, 동접 처리를 할 수 있는 장점에 비한다면 15%의 속도 문제는 그다지 큰 문제점으로 보이지 않는다.

개발자들이 MongoDB 버전 2.4를 사용할 때 주의할 점은, V8 자바스크립트 엔진은 ECMAscript 5^th edition을 지원하고 있기 때문에, 기존 SpiderMonkey가 가지고 있던 비표준 기능은 사용할 수 없다는 것이다. 따라서, 기존에 작업하였던 자바스크립트 로직에서 syntax error가 발생할 수 있음에 주의하자.