MongoDB의 Config 서버

Pinterest

글 : 이승용

MongoDB의 config 서버는 동일한 역할을 담당하고 있는 3대로 구성된다. 3대로 구성되어 있다면 일반적으로 config 서버 집합은 fail-over를 위한 복제 구조를 사용한다고 판단할 수 있다. 즉, 3대 중 한 대가 master가 되어 master 서버의 데이터를 나머지 두 대의 slave가 데이터를 동기화시키는 구조로 생각된다. 또는 master-master 구조로 어느 서버에 데이터를 저장하든 나머지 두 대가 저장된 데이터를 공유할 수 있다고 생각한다.

하지만, MongoDB의 config 서버는 매우 독특하다. Config 서버 자체는 매우 수동적인 서버로 자기 스스로 데이터를 취득하기 위한 능동적인 역할을 하지 않는다. 그렇다면, 3대의 Config 서버들은 어떻게 데이터를 동기화시키는가? 방법은 간단하다. Config 서버와 연결되어 있는 mongos를 통해 데이터를 동기화시킨다.

 

[그림 4-4]

 

[그림 4-4]는 mongos와 config 서버와의 연결을 보여준다. 우선 [그림 4-4]에서 mongos가 하나도 설치되지 않았다고 가정하면, config 서버 3개는 단지 서로들 간의 연결 고리가 없는 독립 서버 3대가 존재하는 형태가 된다. Mongos가 설치되면서 mongos가 사용할 config 서버 3대를 등록시키면, mongos는 config 서버와 연결을 시도한다. Config 서버와의 연결은 3대와 동시에 연결되며, 3대 중 한 대라도 연결이 되지 않을 경우는 mongos는 연결 실패로 MongoDB가 기동되지 않는다.

3대의 config 서버와 연결된 mongos는 연결 초기에 config 서버와 최초로 연결된 것을 확인되면 자신의 샤딩 정책을 포함한 메타 정보를 config 서버 3대에 동시에 보낸다.[1] 이 부분을 유심히; 살펴볼 필요가 있다. 일반 복제 구조에서는 클라이언트는 master에게만 데이터를 보내고 master에 저장된 데이터를 slave 또는 다른 master 들이 동기화 매커니즘을 통해 데이터를 공유한다. 하지만, MongoDB는 자신이 가지고 있는 복제 매커니즘이 있음에도 불구하고 왜 mongos를 통해 config 서버에 데이터를 저장하는 것일까? 여러 가지 이유가 있을 수 있지만, 분명한 것은 config 서버는 복제 구조를 가지지 않는다는 것이며, 성능상의 이슈로 복제를 사용하지 않는 것으로 보인다.

성능상의 문제에 대해 조금 논의해 보자. 복제는 데이터 양이 많아서 응용이 이를 처리해 주기 힘든 경우에 알아서 데이터 동기화를 시키는 구조에 적합하다. 하지만, config 서버에 저장되는 데이터는 아주 극소수이다. 단지 샤드 메타 정보를 저장하기 위해 복제 구조로 config 서버를 만들 필요성을 느끼지 않은 것인가 판단된다. 또한 config 서버는 fail-over에 의한 master 선출도 없다. 복제 구조로 구성된 config 서버가 아니기 때문에 이는 당연하지만, mongos 입장에서는 config 서버의 중요성 때문에, 한 대라도 죽으면 정상적이지 않다고 판단한다.

이와 같이 mongos에서는 config 서버와의 통신을 매우 중요하게 생각한다. 따라서 mongos는 config와의 데이터 연산 중에서 쓰기 연산을 일관성이 강한 연산으로 처리한다. Mongos는 config 서버와 쓰기 연산을 config 서버에 확실하게 저장되어 있는지 응답을 확인하는 SAFE 모드로 동작한다.

그럼 ‘Mongos가 한대만 존재하는가?’라는 질문을 우리는 생각할 수 있다. MongoDB의 샤드 구조는 mongos 개수를 제한하지 않는다. [그림 4-4]에서 mongos #2가 새롭게 첨가된다고 가정하자. 우선, Mongos #2를 기동하기 위해서는 mongos #1과 동일하게 3대의 config 서버 정보를 넘겨주어야 한다. 이때 Mongos #2는 config 서버에 샤딩 메타 정보가 있는지 확인한다. 샤딩 정보를 확인한 mongos #2는 config 서버의 샤딩 정보를 읽어 들여 자신의 메모리에 데이터를 저장하고, mongos #1과 동일한 데이터를 공유한다. 그리고, mongos #1과 #2는 서로 연결하지 않고, config 서버를 통해 데이터를 공유한다.

다음은 config 서버에 저장되는 정보를 요약한 것이다.

  • 샤드 메타 정보
  • 분산 락
  • 복제 집합 정보

첫 번째 샤드 메타 정보는 mongos가 처리하는 청크chunk 단위의 샤딩 정보를 저장하고, 분산 락은 mongos들간의 전체 시스템 락을 의미한다. 이 부분에 대해서는 ‘MongoDB의 분산 락’ 절에서 자세히 다루도록 한다. 그리고 마지막으로 복제 집합 정보를 config 서버가 저장하는데, 이는 [그림 4-4]와 같이 새로운 mongos가 동일한 config 서버에 연결될 때, 자신이 관리하여야 할 또는 접속하여야 할 mongod 샤드 정보를 획득할 때, 해당 정보를 같이 얻을 수 있다.

 

이전글 : MongoDB의 샤딩

다음글 : MongoDB의 라우터

 


[1] 최초 연결인지 확인하는 방법은 config 서버에 샤딩 메타 정보가 존재하지 않을 경우이다.


  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS
  1. 아직 댓글이 없습니다.
  1. 엮인글들이 아직 없습니다.