MongoDB

안녕하세요. MC에몽입니다.

오늘은 Database 중 하나인 MongoDB에 대해 알아보는 시간을 가지겠습니다. 

 

 

MongoDB는 클라우드, 빅데이터가 출현함으로써 이를 효율적으로 처리할 빅데이터 솔루션이 필요해짐에 따라 NoSQL의 등장으로 대량의 데이터를 빠른 속도로 처리가능 (SQL의 부족한 기능을 돕는 기능, 완벽하게 대처는 불가능), NoSQL의 종류 중 하나인 document key/Value Store의 대표 데이터베이스가 MongoDB 입니다.

Document Key/Value Store란?

• Key/Value Store의 확장된 형태
• Value타입으로 Document라는 구조화된 데이터 타입을 사용 (JSON, XML, YAML) 등등
• 복잡한 데이터 구조 사용 가능
• 사용빈도: MongoDB > Cassandra > Hbase > Redis ( 2017년 자료 )

Document 형식 예제 입니다.

 

MongoDB의 특징은?

• 메모리맵 형태의 파일엔진 DB이기 때문에 메모리에 의존적
• 쌓아놓고 삭제가 없는 경우 적합
• 트랜잭션이 필요한 금융, 결제, 빌링, 회원정보 등에는 부적합
• 모든 것을 MongoDB로 하는 것이 아니라 적절하고 필요한 경우 사용, 일관성을 유지해야하고 보완성이 필요한 중요정보 등의 경우 RDBMS를 사용

 

Replica Set 이란?

• replica set 은 클라이언트와 직접적으로 접촉하여 읽기/쓰기를 담당하는 Primary 노드가 있고, 이 Primary의 정보를 동기화하는 Secondary 노드가 있다. 그 외의 정보와 상관없이 replica set의 복구를 담당하는 Arbiter 노드도 있습니다.

• 기본적으로는 각 노드들은 서로 문제가 없는지 10초마다 핑을 보내 확인한다. 이러한 작업을 heartbeat라 부른다. aws에서는 health check라 부르고, 이름만 다르고 개념은 같다.
• 만약 Primary에 문제가 생긴 것을 감지하면, Primary를 대처할 구성원을 선출하는 선거를 진행한다. Secondary 구성원은 피선거권, 선거권을 가지고 Arbiter는 선거권만 가진다.

 

Primary

• 클라이언트와 직접적으로 소통하는 노드이다. 당연히 replica set에서 단 하나만 존재할 수 있다.

 

Secondary

• Primary와 연결되어 정보를 복제한다. Primary가 문제가 생기면 Secondary 중 하나가 Primary가 된다. 고가용성을 위한 복제 외에도 Secondary는 읽기 요청을 분담할 수 있다.
• Read Preference (읽기 신호) 설정을 변경하면 클라이언트가 요청하는 정보를 Secondary에서 불러와 읽어오게 만들 수 있다. 그러나 Secondary 노드는 Primary에 쓰인 내용을 곧바로 반영하지는 않으므로 쓰자마자 곧바로 읽어야 하는 경우에는 Secondary 에서 읽어오지 않는 것이 좋다.

  

그런데 고의적으로 특정 Secondary 노드에 Primary 노드의 정보를 일정 시간 늦게 복제하도록 만들 수 있다. 이러한 Secondary 노드는 롤백에 유용하다. 대규모

업데이트를 한 후에 되돌리고 싶을 때 늦게 복제하게 만들어진 노드를 Primary로 

지정하면 된다.

 

 

Arbiter

• 아비터는 정보 복제와 상관 없는 구성원이다. 단순히 failover 때 투표를 하는 역할을 한다. 왜 투표만 하는 역할인 Arbiter가 존재해야 하는지는,MongoDB failover 시 선거 과정 때문이다.
• Primary와 Secondary 각각 1개만 존재한다고 가정한다. 그런데 Primary와 Secondary 사이의 네트워크에 이상이 발생했다. 그렇다면 교체하기 위한 선거가 열려야 하는데 선거는 하트비트를 통해 Primary의 이상을 감지한 구성원이 과반이어야만 열린다. 문제는 Primary와 Secondary의 연결이 끊어졌기 때문에 과반의 인원이 동의할 수 없는 상태가 되어 버렸고, 선거 없이 Primary는 Secondary로 전환되고 Primary는 공석이 된다. 유저는 쓰거나 불러오는 작업을 할 수 없게 된다.
• 따라서, failover에 대처하기 위한 최소한의 replica set 구성원의 숫자는 3개이다. P, S, S로 구성을 하게 되면 failover를 구성할 수는 있겠으나 아무래도 DB를 하나 더 만드는 일이기 때문에 비용이 들어가는 일이다. 최소한의 비용으로 replica set을 구성하기 위해서는 투표 만 하는 Arbiter가 필요하다. 이것이 Arbiter의 존재 의의다.
• 좋은 성능의 서버에 P, S를 저장해두고, 낮은 성능의 서버에 A를 저장해두면 저럼한 비용으로 failover에 대처할 수 있게 된다.
• 물론 이 구성도 Primary가 선출되지 못하는 상황이 발생할 수도 있다. 세 구성원중 두 구성원이 죽는 상황이다. 이런 일은 보통 하나의 서버에 두 구성원을 넣었을 때 발생한다. P와 A를 같은 서버에 돌아가고 있는 도중에 서버가 죽으면 말이다.
• 따라서, P, S, A는 최대한 각각 독립적인 환경으로 구성하는 것이 좋다.

See you later!

 

참고자료

[1]

https://rastalion.me/mongodb-replica-set-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0/

[2]

https://darrengwon.tistory.com/675

[3]

https://hoing.io/archives/4282

[4]

https://freedeveloper.tistory.com/341

[5]

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-professional/view/

[6]

https://givemesource.tistory.com/82

[7]

https://blckchainetc.tistory.com/350