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

지난1화(http://skccblog.tistory.com/2844)에 이어 MongoDB에 대한 이야기를 이어서 진행하도록 하겠습니다.


4. MongoDB 기본 구성

MongoDB mongod, mongos, config server 등의 세 가지 요소를 기본으로 하여 그 구조를 이루고 있습니다.


mongod

- MongoDB 시스템의 주요 데몬

- 데이터 요청을 다루고, 데이터 접근을 관리하며, 백그라운드 관리 operation 수행

mongos

- Client의 요청을 받아 환경 설정 서버의 partitioning 정보를 참고해 적절한 데이터 서버로 요청을 포워딩 함

 

config server

- Sharded Cluster에 대한 메타데이터를 저장

- 메타데이터는 Sharded Cluster에 존재하는 모든 데이터와 컴포넌트에 대한 상태 및 구성정보를 가짐


아래 그림 1에서와 같이 MongoDB Client로부터 mongos로 요청이 전달되면, config server에 적재된 메타데이터 정보를 확인하여 mongod에서 실제처리가 발생하는 구조입니다. 

기본적으로는 각 데몬들을 위한 별도의 서버를 갖춰야 하지만, 상황에 따라(예산 및 아키텍처 구조) 한정된 개수의 서버로 구성을 하기도 합니다(물론 권장 사항은 아닙니다). 

그림 1에서 각 데몬별로 복수개의 인스턴스가 보이는 것은 replication sharding을 위해 다수의 서버로 시스템을 구성하는 것을 권장하기 때문이며, 일반적으로는 3 replication & 3 sharding을 권장하고 있습니다.



그림 1. MongoDB Architecture Diagram

(출처 : http://www.browniethoughts.com/2013/02/nosql-databases-key-value-and-document.html)



그렇다면 replication sharding은 무엇일까요?


Replication

Replication은 데이터의 안정적인 보관을 위해 복수개의 서버에 동일한 데이터를 적재하는 방식을 의미합니다. 권장 사항은 3 replication이며, 이는 3대의 서버에 동일한 데이터를 각각 보관하는 것을 의미합니다.


그림 2. MongoDB Replication

(출처 : https://docs.mongodb.com/manual/replication/)



위의 그림 2에서와 같이 3 Replication 시에는 1 Primary, 2 secondary로 구성이 되며, 각 노드 간에는 주기적으로 heartbeat 통신을 통해 상호 상태를 체크하도록 되어 있습니다. 

이렇게 구성이 된 replication Primary 노드에 문제가 생겨 heartbeat 통신이 끊어지면 secondary 간에 선출(elections) 과정을 통해 새로운 Primary 를 선출하게 됩니다.



그림 3. Primary 선출 과정

(출처 : https://docs.mongodb.com/manual/replication/)



그럼 이와 같은 의문을 제기할 수 있습니다.

선출 과정에 많은 시간이 소요되지는 않을까요?” 물론 선출 과정에 아주 오랜 시간이 걸리지는 않지만, 선출 과정동안 write 작업은 불가능하다는 점에서 이슈를 제기할 수도 있습니다.

이와 같은 부담을 없애기 위해 아비터(Arbiter)라는 것을 사용할 수 있습니다. 

아비터는 실제 데이터를 저장하지는 않지만, 새로운 Primary를 선출할 때 어떤 노드를 Primary로 선출할 것인지에 대한 투표 권한만을 가지고 있습니다. 미리 정해진 1표이기 때문에 선출 과정에서의 시간을 줄일 수 있다는 장점이 존재합니다.




그림 4. Arbiter 노드가 포함된 Replication

(출처 : https://docs.mongodb.com/manual/replication/)



위의 그림 4에서와 같이 Arbiter 노드는 실제 데이터 저장이 발생하지 않으며, 상호간의 Heartbeat 통신만 주고 받게 됩니다. 

하지만 서버(노드) 하나를 데이터 저장 없이 선출 용도로만 사용하게 되는 것이므로 고스펙 장비 보다는 저스펙 장비를 선정하여 구성하면 많은 부담을 덜 수 있을 것입니다.


Sharding

Sharding MongoDB가 내세우는 대표적인 기능 중의 하나입니다.

아래 그림 5에서와 같이 Sharding 클러스터를 구성하기 위해서는 다음과 같이 3개의 컴포넌트를 필요로 합니다.


shard

- 각 샤드(shard)는 샤딩된 데이터의 부분집합

mongos

- mongos는 쿼리 라우터처럼 동작하며, client 애플리케이션과 sharding 클러스터간의 인터페이스를 제공

 

config server

- 클러스터 구성 정보와 메타데이터를 저장



그림 5. MongoDB Sharding

(출처 : https://docs.mongodb.com/manual/sharding/)



쉽게 말해 샤딩은 대용량으로 쏟아지는 데이터를 동시에 여러 갈래로 나누어 각각의 노드에 저장하는 기술을 의미합니다. 일종의 병렬처리라 볼 수 있습니다. 3TB의 데이터를 하나의 파이프라인으로 처리하기 보다 3개의 파이프라인으로 균일하게 처리할 수 있다면 처리 속도는 적어도 3배 이상 빨라질 것입니다. 

Cloud Computing Big Data 기술에서 언급되는 공통된 요소 중 하나인 분산처리와도 맞닿아 있는 기술이며, 이 때문에 빠르고 효율적인 big data 처리를 필요로 하는 곳은 MongoDB를 사용하고 있습니다. 

이후에 기술하겠지만, RDBMS에서 사용하는 용어 중 테이블(table)”과 동일한 개념으로 쓰이는 용어가컬렉션(collection)”입니다. 데이터를 분산하여 저장하는 기술인 sharding은 컬렉션 단위까지 적용이 가능하여 동일한 컬렉션에 존재하는 데이터도 샤딩 적용 여부에 따라 서로 다른 두 개 이상의 노드에 저장될 수도 있습니다.(아래 그림 6 참고)



그림 6. Collection Sharding

(출처 : https://docs.mongodb.com/manual/sharding/




MongoDB 관련 알아두어야 할 개념들 

지금까지 MongoDB의 주요 기능인 replication sharding 위주로 내용을 전개하였습니다다음은 MongoDB 사용시 자주 접하는 단어들에 대한 개념이며, 추후 MongoDB 관련 문서를 접할 때 자주 언급될 것입니다.


document

- MongoDB를 구성하는 최소의 단위. RDBMS의 행(row)과 동일한 개념

collection

- Document의 모음이며, RDBMS의 테이블(table)과 동일한 개념

- Collection 단위로 sharding이 가능함

 

replication

- 데이터 보존을 위해 N개 이상의 노드에 동일 데이터를 복제하여 적재하는 기술

 

sharding

- 대용량의 데이터를 일정 기준으로 나누어 서로 다른 노드에 적재하는 기술

- 대용량 분산처리를 위해 반드시 필요한 기술

 

Primary

- replication 구성 시 master의 역할을 담당하는 노드. 마스터 노드라고도 한다.

 

secondary

- replication 구성 시 slave의 역할을 담당하는 노드. 슬레이브 노드라고도 한다.

- Primary node down되면 선출과정을 통해 secondary node 중 하나가 Primary로 선출되며, 기존의 Primary secondary로 전환된다.

 

RDBMS와 자주 비교되는 편이며, 이에 대한 용어 비교는 아래 표1을 통해 확인할 수 있습니다.


SQL

MongoDB

Database

Database

Table

Collection

Row

Document

Column

Field

Join

Embedded Document & Linking

Index

Index

1. SQL vs MongoDB 용어 비교표 

 


2편에서는 MongoDB의 주요 구성요소와 아키텍쳐 구조를 살펴보았습니다이어 3편에서는 MongoDB 활용사례와 활용 Tip등에 대해 알아보도록 하겠습니다. 

(3편에서 계속)





저작자 표시 비영리 변경 금지
신고

  1. BlogIcon 오프너 2017.03.02 17:03 신고

    좋은 글이네요. 3화에서는 실제 Mongo DB 가 사용된 사례에 대해서도 공유해 주시면 더 쉽게 다가갈 수 있을 것 같습니다.

  2. Favicon of http://talkit.tistory.com BlogIcon 가야태자 2017.03.03 18:05 신고

    좋은글 잘 봤습니다. 맨날맨날 rdbms만 사용중이라서 3화를 기대합니다.

티스토리 툴바