'replica'에 해당되는 글 1건


Mongo DB를 사용한 Replication은 그 조합과 목적에 따라 여러 가지 구조로 구현된다. Master-Slave 이중화 및 다중화, Master-Master 이중화, Master-Master Circular 구조의 다중화, Cluster 기술이 적용된 Replica Set 등, ... 결국은 데이터베이스의 고가용성을 갖추기 위한 목적은 같지만 말이다.

가장 대표적이고 단순한 것은 Master-Slave이다. 이를 통해서 Data redundancy는 구현되지만, Fail-over 문제, 자원의 비효율적 사용 때문에 Master-Master 구조를 선호하는 것이 일반적이다. 또한 그 구조도 비교적 단순하며 Fail-over 를 통한 Availability 뿐 아니라 Read/Write 부하의 분산의 측면에서 아직까지 중/소규모 데이터 처리시에 효과적으로 활용될 수 있다. 물론 Database의 앞 쪽에 Load Balancer가 있어, 양쪽으로 부하를 분산해 줄 수 있을 경우 또는 드라이버나 Application 에서 Fail-over에 대응하는 접속 설정이 가능할 경우에 해당된다.

이 방식에서의 치명적인 단점은 바로 운영의 부담이 크다는 것이다. 데이터를 양쪽 노드에 모두 쓰기가 가능함으로 해서, Fail-over의 혜택을 누렸지만, 이를 복구한 이후에 재 투입을 할 경우, 짧은 순간이지만, 각 노드가 Master 이면서 Slave 이기 때문에 살아 있던 Master의 replication 옵션을 바꾸어서 장애 복구한 노드를 재 투입하여 Replication을 하고, 정상적으로 Replication될 경우 다시 한번 양 쪽의 raplication 옵션을 Master-Master 바꾸어서 재실행하여야 한다.

10Gen 에서는 MongoDB 초창기(1.4?) 부터 Master/Slave Replication 의 단점을 보완하고자 지금은 없어진 Replica Pair, Replica Set 기능을 개발 해 왔고 1.6.* 이후 부터 본격적으로 안정된 Replica Set 기능을 제공하고 있다. 즉 2대 이상의 서버를 이용해 Master-Slave(1:n) 구조로Data를 복제하여 저장하되, 정상 상황에서 하나의 Primary만 존재하여 작동하되, Primary에 문제가 생길 경우 Slave 중의 하나를 Primary로 선정(vote)하여 Master 기능을 넘겨 받는 구조이다.


[주의] 
모든 경우에 Replica Set이 만능은 될 수 없다. mongos와 Config server를 사용하여 쓰기 부하를 분산하도록 해야 하며, Master-Slave 이중화 구성에서 Replica Set으로 이전하려면, Application 측의 driver 를 변경하여 Primary 노드를 찾아가도록 하는 추가적인 노력이 필요한 점에 유의하여야 하며, 기존의 이중화 구성에서 사용한 Load Balancer의 설정 방식에도 변화를 주어야 한다. 하지만 한 번 적용해 놓으면 트리 구조의 단순성과 추가 노드 투입(확장성)또는 장애 대처의 편리성(운영 편의), 거의 100%에 가까운 가용성 때문에 중 대규모 데이터를 처리하고자 하는 환경인 경우에 지극히 효과적인 장점을 보이는 것은 분명하다.


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들