MongoDB Internals

글 : 이승용

Mongos에 응용의 관계는 앞장에서 살펴본 MongoDB의 일관성 문제의 연속으로 보여진다. 1장에서 다룬 일관성 문제는 응용과 MongoDB와의 직접 연결에 관한 사항으로, 정확하게 표현하자면 mongod와 응용간의 관계이다. 하지만, 본 절에서 다루는 문제는 mongos와 응용에 관한 것이다. 따라서, 응용은 직접 mongod로 데이터를 전송하는 것이 아니라, MongoDB의 라우터 – mongos -를 통해 데이터를 mongod에 저장한다. 따라서, 샤딩 구조에서의 MongoDB는 응용의 데이터 저장 구조를 3단계^tier로 가지고 간다.

 

 

[그림 4-6]은 3단계로 구성된 mongos를 이용한 응용에서의 MongoDB를 사용하는 구조를 보여준다. 응용에서는 sendToMongos()[1]라는 함수를 이용하여 mongos에 데이터를 전송한다. Mongos는 응용으로부터 전달 받은 데이터를 읽어 들여, 유효한 샤드를 검색하여 해당 샤드의 master로 sendTomongod() 함수를 통해 수행된다. 여기서 sendToMongos()와 sendToMongod() 함수의 차이점은 sendToMongos()는 mongos로부터 응답을 기다리고 있는 block mode 통신이고, sendToMongod()는 1장에서 살펴본 것과 같이 mongod의 소켓 버퍼에 데이터가 전달되었다는 것만 확인하고 리턴하는 함수이다. 즉, 응용과 mongos와의 통신은 일관성 SAFE와 유사하고, mongos와 mongod의 통신은 일관성 NORMAL과 동일하다.

한가지 주의할 점은 응용과 mongos의 통신이 일관성 SAFE와 유사하다고 해서, SAFE 모드로 동작한다는 것은 아니다. 여기서 유사라는 것은 SAFE 모드와 같이 저 수준의 소켓 라이브러리의 ACK가 아닌, 상대편의 응답을 기다리는 블록 모드라는 것이 동일한 개념이라는 것이다. 만약, 응용의 sendToMongos()가 일관성 SAFE 모드로 동작한다면, [그림 4-7]과 같이 동작한다.

 

 

MongoDB의 일관성 모드 SAFE는 데이터 저장소에 저장되었다는 것을 의미하므로, [그림 4-6]의 서버에 데이터가 도착하였다는 것보다, 데이터 저장 처리를 더 수행하여 mongod가 보내준 완료 메시지를 mongos가 받을 때까지 블록 모드로 대기한다.샤딩 모드와 독립 모드에서의 MongoDB의 성능을 고려해 보자. 독립 모드에서의 NORMAL은 [그림 1-4]와 같은 구조로 동작되고, 샤딩 모드에서는 [그림 4-6]과 같이 동작한다. 그림의 차이에서 보듯이 샤딩 모드에서는 중간에 mongos가 동작하고, mongos와 응용은 블록 모드로 동작하는 시간이 독립 모드보다 더 첨가되었다. SAFE 일관성은 독립 모드에서의 동작은 [그림 1-5]와 같고, 샤딩 모드에서는 [그림 4-7]과 같다. 따라서, 샤딩 모드가 독립 모드보다 느리며, 실 성능 평가에서도 샤딩 모드가 3배 정도 느리게 나타난다.

그렇다면, 왜 샤딩 모드로 MongoDB를 사용한다면 성능은 포기하여야 하는가? 하는 의문점이 생긴다. 앞에서 논한 3배 정도의 속도 저하는 독립 모드와 1:1:1로[2] 구성된 한 개의 샤드 모드의 성능 평가에 따른 것이다. 속도가 느려지는 이유는 mongos의 데이터 처리 과정이 단순 데이터 전송이 아니라, 샤드를 선택하는 일련의 과정이 필요하기 때문이다. Mongos는 응용에서 전달된 샤드 키의 범위에 따라 특정 샤드를 선택하고, 데이터 균등 분배를 위한 밸런스 역할을 담당하는 mongos의 기능이 있다. 따라서, 샤딩 모드에서의 mongod의 성능은 독립 모드와 동일하다. 그렇다면 mongos와 mongod가 1;1의 관계를 가지지 않는다면, mongod의 성능을 최대로 구현할 수 있을 것이다. 그렇다. MongoDB는 mongos와 mongod의 비율을 꼭 1:1로 가져가지 않는다. Mongos와 응용과 mongod를 연결시켜주는 라우터로, 한 개의 mongod에 2개 이상의 mongos를 사용할 수 있다. [그림 4-8]은 mongod와 mongos의 관계를 1:n으로 구성한 예를 보여준다.

 

 

샤딩 모드가 독립 모드보다 약 3배 정도 느리기 때문에 [그림 4-8]과 같이 구성시킬 경우는 독립 모드에 준하는 성능까지 향상시킬 수 있다. 하지만, [그림 4-8]과 같이 구성할 이유는 전혀 없다. 이는 독립 모드로 구성시킨다면 응용을 포함하여 2대면 될 것을 구태여 4대 또는 7대로 구성할 필요가 없기 때문이다.[3]  [그림 4-8]에서 조금 더 나아가 보자. Mongos와 응용의 관계는 1:1로 유지되어야 하는가? 하는 의문도 생긴다. MongoDB는 응용이 mongos와의 개별적인 연결을 수행하기 때문에 꼭 1:1의 관계를 가질 필요는 없다. [그림 4-8]에서 응용을 3대가 아닌 1대로 [그림 4-9]와 같이 구성한다고 가정하자.[그림 4-9]의 응용의 성능 이슈가 있을 수 있지만, 샤딩 모드에서 부하는 mongos에서 이루어진다. 따라서, 응용의 성능에 따라 [그림 4-8]과 [그림 4-9]는 동일한 성능이 나타난다. 하지만, [그림 4-9]의 문제점이 없는 것은 아니다. 이 역시 이와 같이 사용할 경우는 응용이 연결하고자 하는 mongos를 관리하고 있어야 하며, 특정 mongos가 fail 되었는지를 항상 모니터링하고 있어야 한다.

 

 

[그림 4-10]은 [그림 4-9]의 mongos의 상태를 모니터링하는 문제점을 해결하기 위해 스위치에 가상 IP를 만들어 부하 분산을 시키고 있다. 이와 같을 경우, 응용은 가상 IP를 통해 한 개의 mongos만 연결을 시도한다. 만약 mongos #1이 fail 되었다면, 스위치는 자동으로 인식하여 해당 서버로 데이터를 보내지 않을 것이다. 또한 응용은 자신이 보낸 연산이 에러가 발생하였다면, 가상 IP로 재 연산을 시도하면 새로운 mongos로 연결되어 연산 처리를 계속 수행한다.상기와 같이 샤딩 구조에서 응용, mongos와 mongod와의 관계는 여러 가지 존재한다. 서비스를 구성할 때, 질의가 많은 시스템이라면, [그림 4-9]과 적합할 것이고, 쓰기 만을 수행하는 구조라면 경제성 있는 [그림 4-10]과 같이 적은 수의 응용으로 최적화 시킬 수 있을 것이다. 모든 분산 시스템과 마찬가지로 MongoDB 역시 모듈 별 구성 방법은 QC를 통한 시스템 성격에 맞추어 가장 최적의 상태를 찾아 설계하는 것이 바람직하다.

 

이전글 : mongos와 mongod

다음글 : MongoDB의 분산 락