MongoDB Monitoring 어떤 것이 좋을까?

MongoDB Korea 김인범

Intro

저는 김인범입니다. MongoDB Korea에서 활동하고 있습니다. 회사는 판교(SK C&C), 프로젝트는 보라매 오늘은 MongoDB Monitoring과 관련된 이야기를 하려 합니다.

Q1. MongoDB.. 많이들 쓰시나요?

Q2. MongoDB Monitoring

어떻게 하세요?

그 외에...

ganglia, cacti, nagios... mongostat, mongotop (내장기능) shell scripting (능력자들)

이대로 괜찮은가..?(1)

사실은 괜찮다... 문제는 항상 높아지는 기대치... 개발 보다는 운영 시점에 항상 화두가 되는 monitoring 문제

이대로 괜찮은가..?(2)

기존 대부분의 tool은 실시간 반영의 문제를 내포함

제품 자체의 불안정성 문제 그래서 MMS를 쓰도록 유도하지만…

결국 문제는 비용, 돈!

MMS → Enterprise ver

많은 제품이 일정 기준 초과시 유료 전환 monitoring과 비용의 함정에 갇히는 일상

결국 선택할 수 있는 건...

MMS or 상용 tool 사용 기존 무료 tool 제한적 사용

shell command의 절묘한 조합 새로운 대안

우선...

새로운 상용 tool을 찾아 봤습니다. 일정 기준 이하에서는 무료였습니다.

앞서 열거한 제품들은 제외했습니다.

Q3. 앞서 열거한 제품들을

제외한 이유?

고객의 요구사항

일단 비용 지출 없는 걸로... 이왕 지불할거라면 모니터링 상황을 체계적으로 볼 수 있는 걸로...

“대용량 데이터 처리”에 대해 실시간 모니터링이 가능한 걸로...

A3-1. 그럼 어떤 제품을 살펴봤는가?

Pandora FMS

Open Source(GPL2) (Ent. Ver가 따로 존재함) Ent. Ver는 100 agent부터 비용이 책정됨.

별도의 기술문의와 error fix를 위한 블로그 운영 (http://blog.pandorafms.org/)

Pandora FMS

동일 서버에 pandora agent & server가 설치되어야 함.

MongoDB Plugin까지 내려받아 설정해주면 완료.

좋아 보였지만...

언급하지 않은 복잡한 추가설정 필요

제품에 대한 feedback 문제 ent ver 제품 구매 문의 10여회 시도...

그러나... 응답없음.(아직까지도…)

A3-2. 또 다른 대안은?

Meteor를 이용한 monitoring 구성

web & mobile app을 구축하기 위한 js open source 플랫폼 실시간 업데이트 가능 (매번 빌드 하거나, 서버를 내렸다 올리지 않아도 자동 갱신)

데이터 동기화 시 자체적으로 지연 보정 수행

민감한 코드는 서버 보안 영역에 분리하여 실행 가능

Meteor를 이용한 monitoring 구성

Meteor는 MongoDB의 Oplog를 이용한 Monitoring 수행 javascript 빠에게 좋은 선택(javascript 기반)

‘실시간’ 모니터링 가능

app 구성하기에 따라서 visualization이 가능

Oplog를 이용한 monitoring...(1)

Meteor는 MongoDB의 Oplog를 이용한 Monitoring 수행 * oplog : 복제셋 형태로 운영되는 MongoDB 서버간의 동기화를 위해 DB의 변경사항을 저장하는 로그

Meteor의 기본 observe driver는 polling 방식 기반이며, 이는 Meteor를 매우 느리게 만들고 곧 서버 리소스에 부담이 됨

해결책으로서, Meteor는 data변화를 탐지하고 observer를 작동시키기 위해 oplog를 사용한다.

Oplog를 이용한 monitoring...(2)

Meteor는 Primary를 tailing하는 Secondary처럼 행동함

Meteor는 메모리 안의 데이터에 대한 캐시를 유지하고 이를 observer를 활성화시키는 동안에 적용한다.

Meteor는 Oplog로부터 나오는 모든 데이터에 대한 것이 아닌 observer와 관련된 데이터에 대한 것만을 caching한다.

A4. Meteor 사용시 주의점?

Meteor 사용시 고려사항...(1)

MONGO_OPLOG_URL 변수 설정 필요 이때 MONGO_OPLOG_URL은 레플리카 셋 local db의 Mongo URL을 가리키고 있어야 함. MONGO_OPLOG_URL=mongodb://user:pass@host1:port,host2:port,host3:port/local

Oplog는 레플리카 셋의 이용 가능한 모든 DB의 변화를 포함 Meteor는 MONGO_URL에 명시한 DB의 변화만을 tailing

Meteor 사용시 고려사항...(2)

필요성 여부를 제외하고 DB의 모든 변화에 대해 Meteor가 대응 하는 건 부담이 될 수 있음 만약 observer를 동작시키지 않는 대량의 write operation이 발생한다면...?

ex) 오프라인 pre-aggregation, 다른 app으로부터의 write

Meteor 사용시 고려사항...(3)

도메인 or DB에 대한 이해가 필요

write가 자주 발생하는 collection에 대해 별도 DB로 분리 또는 이동

결국은...

다양한 상황을 고려한 Killer-app은 없는 상태

monitoring에 대한 고민은 곧 서비스에 대한 고민과 직결 (monitoring factor문제)

더 나은 대안을 위한 노력 필요

결론 (Meteor는 이때 사용)

비용이 충분하다면 MMS

비용이 고려되어야 하고

대용량 데이터에 대한 실시간 처리가 가능하며, 개발 skill-set이 있는 인력으로 dev-ops를 생각하신다면...

OUTLO

저의 경험을 이야기 했습니다. 많은 분들이 의견을 주실수록 정답에 가까워 질 것 같습니다. 저는 그저 하나의 새로운 가능성을 제시하려 노력했을 뿐

누구에게나 동일한 best choice는 없으니까요.

Q & A Q & A

Thank You

inbum85@gmail.com https://www.facebook.com/revolutionistK https://www.facebook.com/groups/krmug/