22. Meteor를 이용한 monitoring 구성
web & mobile app을 구축하기 위한 js open source 플랫폼
실시간 업데이트 가능 (매번 빌드 하거나, 서버를 내렸다 올리지 않아도 자동 갱신)
데이터 동기화 시 자체적으로 지연 보정 수행
민감한 코드는 서버 보안 영역에 분리하여 실행 가능
23. Meteor를 이용한 monitoring 구성
Meteor는 MongoDB의 Oplog를 이용한 Monitoring 수행
javascript 빠에게 좋은 선택(javascript 기반)
‘실시간’ 모니터링 가능
app 구성하기에 따라서 visualization이 가능
24. Oplog를 이용한 monitoring...(1)
Meteor는 MongoDB의 Oplog를 이용한 Monitoring 수행 * oplog : 복제셋 형태로 운영되는 MongoDB 서버간의 동기화를 위해 DB의 변경사항을 저장하는 로그
Meteor의 기본 observe driver는 polling 방식 기반이며, 이는 Meteor를 매우 느리게 만들고 곧 서버 리소스에 부담이 됨
해결책으로서, Meteor는 data변화를 탐지하고 observer를 작동시키기 위해 oplog를 사용한다.
25. Oplog를 이용한 monitoring...(2)
Meteor는 Primary를 tailing하는 Secondary처럼 행동함
Meteor는 메모리 안의 데이터에 대한 캐시를 유지하고 이를 observer를 활성화시키는 동안에 적용한다.
Meteor는 Oplog로부터 나오는 모든 데이터에 대한 것이 아닌 observer와 관련된 데이터에 대한 것만을 caching한다.
28. 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
29. Meteor 사용시 고려사항...(2)
필요성 여부를 제외하고 DB의 모든 변화에 대해 Meteor가 대응 하는 건 부담이 될 수 있음
만약 observer를 동작시키지 않는 대량의 write operation이 발생한다면...?
ex) 오프라인 pre-aggregation, 다른 app으로부터의 write
30. Meteor 사용시 고려사항...(3)
도메인 or DB에 대한 이해가 필요
write가 자주 발생하는 collection에 대해 별도 DB로 분리 또는 이동
31. 결국은...
다양한 상황을 고려한 Killer-app은 없는 상태
monitoring에 대한 고민은 곧 서비스에 대한 고민과 직결 (monitoring factor문제)
더 나은 대안을 위한 노력 필요
32. 결론 (Meteor는 이때 사용)
비용이 충분하다면 MMS
비용이 고려되어야 하고
대용량 데이터에 대한 실시간 처리가 가능하며,
개발 skill-set이 있는 인력으로 dev-ops를 생각하신다면...
33. OUTLO
저의 경험을 이야기 했습니다.
많은 분들이 의견을 주실수록 정답에 가까워 질 것 같습니다.
저는 그저 하나의 새로운 가능성을 제시하려 노력했을 뿐
누구에게나 동일한 best choice는 없으니까요.