zookeeper의 필요성

이번시간엔 zookeeper의 필요성에 대해 포스팅 해보려고 한다. 이 포스팅 내용자체가 mongodb Replica Set의 개념이 있어야 이해가 가능한 내용이기때문에 꼭 mongodb 내용부터 확실하게 이해를 하고 봐야 이해가능한 내용이다.

1. Mongodb Replica Set의 여전히 해결되지 않는 문제점

‘Mongodb Replica Set 만들기’에서 살펴본 바 같이 rs가 Primary1, Secondary2, Arbiter1 으로 구성돼 있다면 Primary가 죽었다고 하더라도 2개의 Secondary 중 하나가 Arbiter의 존재로 인해 Primary로 선출된다.

하지만 여전히 문제점은 존재하게 된다. 

[그림1 Election for New Primary: Secondary2, Arbiter1]

죽었던 Primary는 어떻게 살려내야할까? 만약 Arbiter가 죽으면 이건 또 어떻게 해결할 수 있을까?

아래의 그림은 아비터가 죽었다고 가정한 가상의 모식도이다.

 

[그림2 rs(Primary1, Secondary2, Arbiter1) 멤버 중 Arbiter가 죽은 경우]

그리고 이 상태에서 Primary가 죽게된다면 어떻게 될까? Election을 통해 Primary가 선출되지 않을 것이다. 그렇게 된다면 선출할 수 있는 권한을 가진 Arbiter가 없기때문에 큰 문제가 발생한다. 이건 Arbiter를 다시 꼭 살려야한다.

하지만 다행히도 Arbiter는 죽을 일이 거의 없긴하다. 투표권을 행사하지만 Replication 되지도 않으며 Client에게 Read를 수행하는 경우도 없기 때문이다.

현 상황은 ‘그림1’ 과정을 거쳐 Primary 하나와 Secondary 하나, Arbiter 하나가 살아있는 상태라고 가정한 그림이다.

[그림3 ‘그림1’과정을 거친 후 rs 멤버의 모습]

이 상황에서 Primary가 죽는다면 남은 Secondary는 Primary로 선출되지 않는 것이다. 이렇게 되면 죽은 rs 멤버는 다시 살려낼 필요가 있다.

 

[그림4 ‘그림3’에서 Primary가 죽은 경우]

2. User입장에서의 rs서버?

이 뿐만 아니라 몽고를 사용하는 User 입장에서 누가 Primary인지 누가 Secondary인지 어떻게 알아낼 수 있을까?

[그림5 rs를 바라보는 User 입장]

각 rs 서버의 상태에 대한 정보들을 관리할 무엇인가가 필요하다.

[그림6 rs를 바라보는 User 입장2]

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

이것을 해결해 줄 수 있는 것은 zookeeper이다. 여기서 zookeeper의 필요성을 다시 한 번 느낄 수 있을 것이다. zookeeper를 쉽게 설명하면 전체적인 서버를 관리할때 주로 쓰는 도구라고 알려져있다. zookeeper의 용도도 다양하게 쓰이기 때문에 뭐라고 딱 단정지어서 정의내리긴 어렵지만 서버관리용도로도 많이 사용되고 있다. 그럼 다음시간에는 zookeeper에 대해 더 자세히 알아보도록 하겠습니다!