MongoDB의 데이터 유실 가능성
글 : 이승용
앞 장에서도 이 문제에 대해서도 언급하였지만, 샤딩 구조에서의 데이터 유실 가능성에 대해서도 논의할 필요가 있다. 샤딩 구조가 아닌 복제 구조에서는 master가 fail되고 난 뒤 선출하게 되는 약 10초 동안의 데이터가 유실될 수 있다고 하였다. 이러한 문제는 샤딩 구조에서도 동일하게 발견된다. 샤딩 구조가 아닌 시스템에서는 mongos와 같은 라우터가 존재하지 않기 때문에 응용은 항상 master만을 바라보게 된다. 따라서, master의 fail을 바로 알게 되고, 프로그래머는 master fail에 대한 대처를 직접 작성하여야 한다.
[그림 4-12]
문제는 샤딩 구조에서 여러 가지 문제점들을 보일 수 있다. [그림 4-12]와 같이 3개의 mongod와 1개의 mongos가 연결되었다고 가정하자. 그림과 같이 mongod #1이 master로 설정되어 있다. 정상적으로 잘 동작하고 있던 MongoDB에 부하가 발생하고 있고, 원인을 알 수 없는 문제로 인해 master 서버가 fail 되었다. [그림 4-13]과 같이 mongos는 쓰레드 ReplicaSetMonitorWatcher가 수행되기 전까지 아직도 mongod #1을 master로 간주한다. 이 때 응용으로부터 전달된 질의를 수행하면 master와의 연결이 끊어진 경우이기 때문에 mongos는 에러를 발생한다.
[그림 4-13]
일정 시간이 지나, 쓰레드 ReplicaSetMonitorWatcher이 mongod #1이 fail된 것을 인식하고, 복제 정보를 갱신한다. [그림 4-14]과 같이 MongoDB는 투표를 통해 mongod #2를 master로 선출하였고, mongos 역시 mongod #2를 master로 인식하여 정상적인 작업을 수행하게 된다.
[그림 4-14]
이 시점을 가만히 고려해 보자. [그림 4-9]에서 정상적으로 입력된 데이터가 아직 복제를 성공하지 못하고, master가 fail이 되었다면, 새롭게 선출된 master에 있는 oplog 데이터로 새로운 복제를 수행하게 될 것이다. 이와 같을 경우 mongos는 mongod #1에 삽입하였던 데이터가 사라졌다는 것을 인식할 수 없게 된다. 앞 장에서 살펴보았던 10초의 룰[1]이 적용되었기 때문에, master 선출에서 최악의 경우 10초의 데이터가 사라질 수 있다.
또한, mongos는 master 선출에 관여할 수 없기 때문에 master가 없다면, slave가 읽기 연산 모드를 지원해 주지 않는다면, MongoDB 자체는 전체 다운이 되어 버린다. 예를 들어, [그림 4-9]의 환경에서 mongod #1이 먼저 fail되지 않는다면, mongod #1이 master 자격을 유지하고 있기 때문에 나머지 두 대의 slave가 fail이 되어도 1대의 master로 시스템은 유지된다. 하지만, [그림 4-11]과 같이 새로운 master가 선출되고 난 다음에, 새롭게 선출된 master인 mongod #2가 fail된다면, salve인 mongod #3는 투표를 수행할 수 없게 된다. 따라서, slave만 존재하는 상태가 되어, 정상적인 MongoDB 수행이 어려워진다.
지금까지 MongoDB의 샤딩 구조에 대해서 알아보았다. 최근에 이슈가 되었던 Don’t Use MongoDB 저자가 언급한 샤딩 구조에서의 부하 사항을 언급하기 전에, 샤딩 구조에서의 데이터 유실 가능성에 대해서 살펴보면, MongoDB가 샤딩 구조에서 데이터 일관성을 완벽하게 잘 처리하고 있는 것은 아니지만, 이러한 문제가 MongoDB만의 문제라고 치부하기에는 이른 감이 있다. 분산시스템에서 고려되고 있는 fail-over 처리에서는 완벽한 일관성이 유지되면서, 에러 대처를 수행하여야 한다는 것은 보장하지 못한다. 천하의 IT의 하늘이라고 자부하는 구글도 99.99%라는 SLA(Service Level Agreement)를 보장하고 있는 것을 보아도, 오차는 있다는 가정을 두어야 한다.
다만, 그 오차의 범위를 어느 정도까지 줄일 수 있는가가 현재 분산시스템의 가장 큰 이슈사항으로 자리잡을 것이다. 일관성이 강조되면, 시스템 성능이 떨어지는 것은 당연하다. 따라서, 일관성에 대해서 프로그래머들이 선택할 수 있는 약한 일관성을 대부분의 분산데이터베이스 시스템에서 제공한다.[2] MongoDB 역시 [표 1]과 같은 일관성을 선택하여, 일관성 강조되어야 할 데이터에 대해서는 SAFE 또는 REPLICA를 선택하고, 그 이상을 원할 경우는 MAJORITY와 강도를 더 조정하는 방법도 있다. 또한 데이터를 복구할 수 있는 저널링을 이용하면 소실되는 데이터의 양을 최소화 할 수 있을 것이다.[3]
다시 문제를 언급한 샤딩 시스템의 부하사항을 살펴보자. 본 문제를 제시한 사람은 여러 부분에서 MongoDB에 대한 자료를 충분히 살펴보지 않은 것 같다. MongoDB는 샤딩될 때의 부하를 고려하여 청크의 크기를 조정할 수 있도록 옵션으로 조정하고 있고, 또한, 분할 시기를 시스템 부하가 없는 새벽 시간에 조정할 수 있도록 Balancer window를 사용할 수 있다. 단순히 청크가 분리되는 동안 부하가 발생하는 사항을 문제로 삼기에는 문제 제기자의 분산시스템에 대한 이해력이 부족하다는 느낌이다. 차라리 구체적인 예제를 통해 다른 시스템에 비해 부하가 크다는 식으로 논하였다면, 많은 사람들이 공감할 수 있었을 것이다.
그렇다고, MongoDB가 우수한 방법으로 샤딩을 부하 없이 수행한다는 것은 아니다. 샤딩을 하는 동안 락이 걸리는 문제는 쓰기 락이 전역적으로 사용되는 문제점과 일치된다. 버전 2.2에서 전역 락이 아니라 데이터베이스 락으로 변경되었지만, 어차피 데이터베이스의 컬랙션 단위로 샤딩이 이루어지기 때문에 근본적인 문제 해결은 될 수 없다. 이러한 사항은 MongoDB가 해결하여야 할 문제로 보인다.
우리나라 속담에 ‘소 잃고 외양간 고친다.’가 있다. 소를 잃어버리기 전에, 튼튼한 외양간을 만들고, 그리고 외양간이 문제가 없는지 수시로 관찰하는 것만이 중요한 데이터를 소실되지 않게 만드는 방법이다.
이전글 : MongoDB의 샤딩 한계
