Mongo DB 8강 - 샤딩

샤딩

데이터를 분산하여 저장하는 개념이다. 단 한 대의 서버에 빅데이터를 저장하게 되면 I/O가 한대에서 일어난다. 서버를 여러개를 두고 분산하여 저장한다면 I/O가 여러대에서 일어나기 때문에 효율이 좋아진다.

config server에 indexing하여 목차를 들고있다 → 이를 "메타 데이터" 라 한다.

 

라우터는 바로 데이터를 찾으러 가지 않고 왜 메타데이터를 찾으러 갈까?

→ 메타데이터가 데이터를 찾기 위해 어디로 가야 하는 지 알고 있다.

 

config server가 망가지면 시스템 자체가 돌지 않는다. 따라서 여러 개의 config server를 사용한다.

 

만일, 그림과 같은 구성에서 10을 저장한다고 할 때, 실패할 경우 이 "10"데이터는 사라지게 되며, 프로그램 쪽으로 실패한 응답을 받게 되면 다시 save를 해야한다. → 프로그램이 관리해야 하는가? 꼭 그러진 않다!

 

 

MongoS 와 ConfigS 중 하나라도 망가지면 시스템이 돌지 않는다. 따라서 이러한 서버를 여러개를 복제하여 대비하는 데 이를 "리플리카" 라고 한다.

 

리플리카를 만들 떄는 3개를 한쌍으로 만든다. 이 3개를 묶어 리플리카 셋(SET)이라고 한다. 이러한 과정을 데이터가 RAID된다고 한다.

 

🎇 RAID

 RAID(Redundant Array of Independent Disk : 독립된 디스크의 복수 배열) : 여러개의 디스크를 묶어 하나의 디스크 처럼 사용하는 기술!

10 이라는 정보를 클라이언트로 받았을 때, Primary의 MongoS가 이를 받고 Primary Config Server에게 어디에 작업해야할지 물어본다. Config Server가 A Server(123)으로 응답해야 한다고 알려주면 Primary Sever(123)의 OPlog(Operation log)영역에 10을 저장해야하는 명령이 들어온다. OPlog에는 오류가 발생할 수 없는 명령 자체를 저장한다.

 

그리고 Primary와 Secondary에 각각 연결된 OP 끼리 request해서 동기화 한다. 이과정을 HeartBeat 라 한다.

HeartBeat는 그물처럼 서로 연결되어져 있다.

The replica's synchronization and master election of MongoDB | MongoDB Internals

이 때, request하는 시간을 polling이라 하며, default time이 존재한다. 보통 default time은 2초 단위로 수행한다.

여기서 Primary Server에는 1,2가 저장되었고 Secondary Server에는 1만 저장되어 있는 상태이다. OPlog에는 1,2 모두 저장하라는 명령이 들어와 있고, P와 S Server 데이터를 비교하여 2가 저장되어 있지 않은 것을 확인하고 OPlog에서 명령을 다시 재실행한다. 이 때, 실패하게 되면 S Server와 연동된 OPlog의 내용은 사라지게 되고 P Server와 연동된 OPlog 와 heartbeat하여 동기화 한다. 그리하여 다시 1,2를 다시 저장하라는 명령이 들어오면 명령을 실행한다 이과정을 명령이 성공할 때까지 실행한다. 즉 RDS 서버의 REDO가 되는 것을 볼 수 있다.

 

그림의 오른쪽을 보면 기존에 1,2 데이터가 저장되어있는 Primary Server 와 Secondary Server가 있다.

19.99초에 heartbeat가 수행되었고 20.00초에 Primary OPlog에 2를 5로 수정하라는 명령이 들어왔다고하자. 이 명령이 수행되어 Primary Server의 2가 5로 변경된다. 다음 heartbeat는 21.99초에 수행되어 2를 5로 수정하라는 명령을 받는다.

그러나 21.55초에 Primary Server와 OPlog가 고장났다고 하자. 이렇게 되면 남은 두 개의 Secondary Server 중 하나가 선출되어 Primary Server가 되어 두 개의 Server로 운용된다.

​

이 타이밍에서 다른 클라이언트가 5 데이터를 요청하면 확인할 수 없다. → 지금은 데이터 복구가 안된다.

​

10초 정도 후, 기존의 primary server가 살아나게 되면 자동으로 Secondary Server가 된다. 서로 heartbeat를 통해 동기화를 진행하여 Operand가 기준이 되어 2가 5로 수정되는 명령이 모두 들어온다. ( 복구가 된 이후 )

heartbeat의 polling 시간을 매우 짧게 진행하여 이러한 문제를 방지할 수 있으나 MongoDB에 과부하가 발생한다.

따라서 시간을 줄이는 방법보다, 저널링이라는 시스템을 통해 복구를 진행한다.

​

※ 저널링 파일 시스템 : 변경사항을 반영하기 전에, 변경사항을 추적할 수 있는 어떤 데이터를 보관하는 시스템

타이밍 : OPlog에 2를 5로 수정하라는 명령이 들어와 수행직전에 파일로 명령을 기록한다.

만일 위의 상황처럼 서버가 죽어버린 경우, 저널링부터 찾아가 Operand가 같은지 확인하고 다르다면 동기화시킨다. 이를 저널링 시스템이라고 한다. 또한, 클라이언트의 요청에도 문제가 없다.

​

But, 블록체인의 경우 50% 이상의 값을 따라간다(즉, 하나의 1,5가 1,2로 바뀐다)