'mongoDB'에 해당되는 글 11건

이번시간엔 지난시간에 이어 mongodb Replica Set Election에 대해 포스팅 해보려고 한다. 아마 지난시간에 설명한 Arbiter의 내용은 다 이해하고 왔을 거라고 생각한다. 그러면 Election은 또 어떤건지 자세히 알아보도록 하자.

‘그림1’처럼 Primary 하나와 Secondary 둘이 rs를 구성하고 있다고 가정해보자.

[그림1 mongodb rs: Primary1, Secondary2]

​​

‘그림2’와 같이 Primary가 죽고 Secondary 둘만 남은 상황이다.

[그림2 Primary1, Secondary2 rs에서 Primary가 죽은경우]

그럼 저상황에서 Election을 진행하는데 서로 1표씩 받은 상황이다. 그럼 결국엔 1:1 무승부가 되었기때문에 Primary는 선출되지 않는다. 그럼 또 이럴땐 어떻게 해야할까?

[그림3 Election for New Primary: 1 vs 1 무승부]

아래와 같이 mongodb를 실행시켜보면 Replica Set 구성원은 “votes”라는 투표권을 가지고 있다.

[그림4 rs member가 가지는 votes]

그렇다면 투표권 숫자를 변경해 Primary가 선출될 수 있도록 설정하면 될거같지않은가? 투표권이 각각 3, 2, 1로 설정된다면 Primary 선출에 아무런 지장이 없을테니 말이다.

하지만 또하나의 변수는 있다. 아래의 그림을 보자.

[그림5 rs member의 votes 특성]

“must be 0 or 1” 문구를 보면 알 수 있듯이 “votes” 값은 ‘0’ 혹은 ‘1’로 설정해야한다. 그렇다면 Primary 투표권을 ‘1’로 Secondary의 투표권을 각각 ‘0’, ‘1’로 설정하면 되지 않을까?아래 그림과 같이 Primary에 장애가 생겼다.

[그림6 Primary, Secondary2가 각각 1, 0, 1 votes를 가지고 Primary가 죽은 경우]

Secondary 둘이 Election을 진행하게 된다. 서로 가진 투표권은 각각 ‘0’, ‘1’이다. Secondary 둘이 Election을 진행한 결과 아래 그림과 같이 각각 ‘1’, ‘0’표씩 받았다. 그렇다면 1표를 받은 Secondary가 Primary로 선출되지않을까?

[그림7 Secondary 둘이 Election 진행한 결과]

하지만 투표자 들의 투표 숫자(1표)가 전체 투표 숫자(2표)의 과반수(1표)를 넘지 못한다는걸 볼 수 있다. 이로 인해 1표를 받은 Secondary는 Primary로 선출되지 못한다. mongodb는 Election 시에 투표자들의 투표 숫자가 전체 투표 숫자의 과반수를 넘어야 진행이 되도록 하고 있다. 그렇다면 Primary의 투표권이 ‘0’이고 Secondary 투표권이 각각 ‘0’, ‘1’이라면 되지 않을까??

이렇게 설정하려 하면 다음과 같은 문구를 보게 된다.

[그림8 rs member들의 votes 합이 1개인 경우]

위의 문구를 보면 알 수 있듯이 “not enough voting nodes”라고 경고하고 있다. 적어도 2개의 투표권이 있어야 한다. 따라서 투표권을 하나씩 가지고 있는 상황에서 투표를 하는 서버는 3개 이상의 홀수개로 존재하여야 Primary가 정상적으로 선출이 된다. 만약 짝수의 서버가 Election을 진행하면 N:N 무승부로 Primary 선출이 정상적으로 진행되지 않을 수 있기 때문이다.

하지만 Primary 하나와 Secondary 둘, Arbiter 하나가 있는 상황에서 Primary가 죽는다면? ‘그림9’와 같이 된다. Primary와 Secondary, Arbiter가 모두 투표권을 ‘1’개씩 가지고 있는 상황이라면 투표자들의 투표 숫자(3)가 전체 투표 숫자(4)의 과반수를 넘긴다는 것을 알 수 있다.

이번시간엔 지난번에 생긴 궁금증에 대해 이어서 포스팅 해보고자 한다. 친구가 했던 내용을 글로 쓰는거지만 나 나름대로 내용을 알고 있는 상태에서 글을 썼고 모르는 내용이나 어설프게 아는 내용이었다면 포스팅 하지 않았다. 컴퓨터 개발자나 보안전문가들은 항상 겸손하다. 왜나면 아는것 같아도 또 모르는게 계속 있기 때문에 끊임없이 공부해야하기 때문이다. 아무튼 내가 알게 된 지식도 겸비해 글을 쓰겠다.

1. mongodb rs(replica set) 구조에서 Write를 수행하는 DB는 “Primary”라고 하고, Read를 수행하는 DB는 “Secondary”라고 부른다.

[그림1 rs: Primary, Secondary]

’그림2’와 같이 Primary에 장애가 생겨 서비스 장애가 발생했다. 그렇다면 이상황에 대해서는 어떻게 해야할까? 이래서 Primary쪽은 관리를 잘해야 하는 것 같다.

[그림2 rs: Primary에 장애가 생긴 경우]

그림3’처럼 Primary가 죽은 것을 빠르게 catch한 후 Secondary 중 하나가 Primary로 선출된다면 다시 정상적인 서비스가 가능해질 것이다.

​

[그림3 rs: Primary를 새롭게 선출]

이번시간에는 몽고DB mongodb Replica Set의 필요성에 대해 포스팅 해보려고 한다. 말그대로 저걸 그냥 해석하면 mongodb 복제 셋이다. 데이터베이스를 복제한다? 왜 복제하는지 그 필요성에 대해 이야기해보고자 한다. 이건 친구가 소프트웨어마에스트로 과정을 할때 연구했던 것이며, 세계적인 일간지에도 실린만큼 성과가 컸었다. 그땐 잘 몰랐지만 지금 이렇게 다시 내가 이해하고 보니 일간지에 올라갈만한 이유는 있었던 것 같다. 친구가 연구했었던 내용이 너무나 좋아서 허락을 받고 내 블로그에 포스팅을 한다. 

한 서버에 DB가 하나만 연결되어 있는 상태이다.

 [그림1 한 서버에 DB가 하나만 연결된 경우]

만약 연결돼 있던 DB가 죽는다면? 원하는 data를 가져올 수 없다. 서비스를 정상적으로 수행하기 위해선 어떻게든 죽은 데이터베이스를 살려 내야만 한다.

[그림2 한 서버에 DB가 하나만 연결된 상태에서 DB가 죽은 경우]

그리고 또하나 가정을 해본다. Request가 너무 많아서 서버가 죽는 경우도 생긴다. 이럴 경우는 또 어떻게 해야하는지 살펴보자.

해결법은 Scale-up과 Scale-out 이렇게 2가지 이다.

​ 

[그림3 Scale-up, Scale-out]

Scale-up을 통해 DB의 성능(cpu, memory, 저장공간 등)을 높이면 Request가 많이 발생하더라도 처리가 가능해 진다. 하지만, 만약 DB가 죽는 경우가 발생한다면? 정상적인 서비스를 제공할 수 없게 된다. 그렇게 된다면 또 어떻게 해결을 할까? 데이터베이스를 너무 한곳에다가 몰아서 해놓을 경우 그 데이터베이스가 죽었을시엔 또 감당이 안되는 상황이 벌어진다.

[그림4 Scale-up: DB가 죽은 경우]

그랬을 시엔 해결법은 한가지다. 복제된 DB가 필요하다. 이로써 많은 Request를 처리할 수 있으며 특정 DB가 죽는 경우가 생기더라도 정상 서비스를 제공할 수 있다.

[그림5 Scale-out: DB를 늘리는 경우]

그런데 ‘그림5’와 같은 형태로 DB를 복제한다면 문제점이 있다. 아까전처럼 하나의 데이터베이스에 묶어놓는거보단 여러개로 분산시켜놔서 돌리는 것까진 좋았는데 어떤 유저가 Write를 시도하면 서버가 DB에게 전달하는 Write 명령이 3번이나 반복되어야한다. 또한 원하는 data를 얻어오려면 어느 DB에게 Read 요청을 하는게 좋은지 살펴보자.

[그림6 Scale-out(복제): Write연산]

그림 6에서와 같이 Write 연산 중에 Read 요청이 온다면 어떻게 될까? Wrtie가 끝난 후에 Read 연산을 진행해야 하기 때문에 지연이 생기게 된다.

​

따라서 ‘그림7’처럼 Write, Read 명령을 수행하는 DB를 각각 분리하고 Write 명령을 수행하는 DB는 각 DB에게 Replication해 주도록 구성해야 한다.

[그림7 Scale-out: Write, Read 분리]

하지만, 이 때문에 문제점이 발생한다. ‘그림8’처럼 Write를 수행하는 DB가 죽는 경우 전체적인 서비스에 장애가 발생하기 때문이다. 

[그림8 Scale-out: Write DB가 죽은 경우]

<출저: https://unagi44.wordpress.com/Developer Lee>

​

어떻게해도 참 난감한 문제가 발생한다. 한꺼번에 처리하자니 처리속도가 너무 느려지고 나눠서 처리하자니 write DB가 다운되는 상황이 벌어지면 Read DB에까지 영향을 주니 말이다. 그럼 진짜로 해결방안은 없는걸까? 그 다음 포스팅으로 넘어가도록 하겠다.