MongoDB Internals

글 : 이승용

MongoDB의 복제 정책은 기본적으로 Master-Slave 방식을 채택하고 있으며, master가 죽더라도 slave들 중에서 master를 선출할 수 있는 master 선출 방법을 채택하고 있다. 즉, Master가 죽으면, slave들이 투표를 진행하고 투표된 결과에 따라 새로운 master가 선출된다.

[그림 2-1]

[그림 2-1]은 MongoDB의 복제 정책을 보여준다. MongoDB의 master는 쓰기 연산을 담당한다. 즉, 일반 Master-Slave 방식과 동일하게 쓰기는 master에서만 이루어진다. 이때 MongoDB는 쓰기 연산을 데이터 저장소와 Oplog라는 두 군데 영역에 저장한다. 데이터 저장소에는 B+ 트리로 구성된 데이터 저장소를 말하는 것으로, 쓰기 연산을 수행한 결과를 저장한다. 반면 Oplog는 데이터 저장소에 저장된 데이터와는 달리 연산 수행과 관련된 명령 자체를 타임스탬프와 같이 저장한다.

MongoDB의 slave는 아주 빠른 주기적으로 master에게 자신의 optime[1]보다 큰 oplog를 달라고 요청한다. Slave의 요청은 master에 oplog 데이터를 요청할 때, 질의 요청 옵션을 QueryOption_AwaitData으로 보낸다. QueryOption_AwaitData는 대기하는 일정 시간 안에 응답할 데이터가 존재한다면 바로 응답하고, 응답할 데이터가 없다면, 일정 시간을 대기한다는 것을 의미한다. Oplog 질의에 대한 대기 시간은 5초이다. 즉, 5초안에 master에서 쓰기 연산이 발생하면 바로 데이터를 응답해 주고, 5초안에 쓰기 연산이 발생하지 않는다면, 데이터가 존재하지 않는다는 응답을 보내준다. Slave는 요구한 Oplog의 데이터가 존재하면 자신의 Oplog에 데이터를 저장한 다음에 바로 mater에 다시 Oplog 질의를 수행한다.

Slave의 동기화 처리는 쓰레드 한 개가 지속적으로 담당하고 있다. 만약, master와의 연결이 단절되어 Oplog를 동기화 시키지 못하게 되는 경우는 자신의 Oplog의 마지막 연산 시간을 저장하고, Oplog를 비우고 난 다음에 메모리에 보관된 모든 데이터를 데이터 저장소에 저장시킨다. 그리고, 5초 이후에 다시 master와의 연결을 시도한다.

Master 역시 slave와의 동기화를 위해 한 개의 쓰레드를 만들어 slave와의 통신을 담당하고 slave가 요구하는 데이터를 전달한다. 따라서 master는 능동적 동기화 보다는 수동적 동기화 입장이므로, slave들의 요구에 따라 데이터를 전송하는 부담만 지게 된다. 이러한 MongoDB의 철학은 master의 역할을 쓰기 연산에 집중 하도록 구성하여 빠른 속도를 구사할 수 있도록 만들고 있다. 실제 성능 테스트를 수행하였을 경우에도, 복제를 설정한 상태에서 master의 부하가 가중되지는 않는다. 성능 이슈는 5%[2] 정도로 복제가 전체 시스템의 성능 여하를 결정하지 않는다. 다만, 복제를 위한 slave의 개수를 많이 둘 경우에는 master의 동기화 요구가 많아지게 되므로, 그 만큼의 속도 저하는 고려하여야 한다.

다음글 : MongoDB의 복제 동기화 및 마스터 선출