고가용성을 위한 mongoDB Replication (1) : P, S, A와 선거

Replication — MongoDB Manual

A replica set in MongoDB is a group of mongod processes that maintain the same data set.

 

고가용성의 개념은 AWS RDS를 사용하면서 들었겠지만, 해당 인스턴스(여기서는 DB)에 문제가 생겨도 정상적인 운영이 가능하다는 개념이다.

 

이를 위해 mongoDB에서는 복제를 이용할 수 있다. 복제를 이용하면 고가용성 뿐만 아니라 복제된 인스턴스를 이용해 읽기 작업의 부하를 분산시킬 수도 있다. (변경사항이 즉시 반영되지 않는 단점이 있지만)

공식 문서에도 replication은 Redundancy and Data Availability을 위한 것이라 명시하고 있다.

 

복제를 하기 위해서는 mongo 서버 인스턴스 여러 개가 필요하다. (너무 당연한가?)

여러 개의 서버 인스턴스의 묶음을 'replica set'라고 부른다.

 

👨‍🏫 replica set

 

replica set은 클라이언트와 직접적으로 접촉하여 읽기/쓰기를 담당하는 Primary 노드가 있고, 이 Primary의 정보를 동기화하는 Secondary 노드가 있다. 그 외에 정보와 상관없이 replica set의 복구를 담당하는 Arbiter 노드도 있다.

Primary / Secondary / Arbiter 이렇게 세 종류의 노드가 replica set을 이루는 구성이다.

 

 

 

 

기본적으로 각 노드들은 서로 문제가 없는지 10초마다 핑을 보내 확인한다.

이러한 작업을 heartbeat라 부른다. aws에서는 health check라 부르고. 이름만 다르고 개념은 같다.

 

만약 Primary에 문제가 생긴 것을 감지하면, Primary를 대체할 구성원을 선출하는 선거를 진행한다. 

Secondary 구성원은 피선거권, 선거권을 가지고 Arbiter는 선거권만 가진다.

 

 

 

- Primary

 

클라이언트와 직접적으로 소통하는 노드이다. 당연히 replica set에서 단 하나만 존재할 수 있다.

 

 

- Secondary

 

Primary와 연결되어 정보를 복제한다. Primary가 문제가 생기면 Secondary 중 하나가 Primary가 된다. 

고가용성을 위한 복제 외에도 Secondary는 읽기 요청을 분담할 수 있다.

 

Read Preference (읽기 선호) 설정을 변경하면 클라이언트가 요청하는 정보를 Secondary에서 불러와 읽어오게 만들 수 있다. 그러나 Secondary 노드는 Primary에 쓰인 내용을 곧바로 반영하지는 않으므로 쓰자마자 곧바로 읽어야 하는 경우에는 Seconday 에서 읽어오지 않는 것이 좋다.

 

 

 

 

그런데 고의적으로 특정 Secondary 노드에는 Primary 노드의 정보를 일정 시간 늦게 복제하도록 만들 수 있다. 이러한 Secondary 노드는 롤백에 유용하다. 대규모 업데이트를 한 후에 되돌리고 싶을 때 늦게 복제하게 만들어진 노드를 Primary로 지정하면 된다.

 

 

-  Arbiter 

 

아비터는 정보 복제와는 상관 없는 구성원이다. 단순히 failover 때 투표를 하는 역할을 한다.

왜 투표만 하는 역할인 Abiter가 존재해야 하는지는, mongoDB failover 시 선거 과정 때문이다.

 

Pimary와 Secondary 각각 1개만 존재한다고 가정하다. 그런데 Primary와 Secondary 사이의 네트워크에 이상이 발생했다. 그렇다면 교체하기 위한 선거가 열려야 하는데 선거는 하트비트를 통해 Primary의 이상을 감지한 구성원이 과반이어야만 열린다. 문제는 Primary와 Secondary의 연결이 끊어졌기 때문에 과반의 인원이 동의할 수 없는 상태가 되어 버렸고, 선거 없이 Primary는 Secondary로 전환되고 Primary는 공석이 된다. 유저는 쓰거나 불러오는 작업을 할 수 없게 된다.

 

따라서, failover에 대처하기 위한 최소한의 replica set 구성원의 숫자는 3개이다.

P, S, S로 구성을 하게 되면 failover를 구성할 수는 있겠으나 아무래도 DB를 하나 더 만드는 일이기 때문에 비용이 들어가는 일이다. 최소한의 비용으로 replica set을 구성하기 위해서는 투표만 하는 Abiter가 필요하다. 이것이 Arbiter의 존재 의의다. 

 

좋은 성능의 서버에 P, S를 저장해두고, 낮은 성능의 서버에 A를 저장해두면 저렴한 비용으로 failover에 대처할 수 있게 된다.

 

물론 이 구성도 Primary가 선출되지 못하는 상황이 발생할 수도 있다. 세 구성원 중 두 구성원이 죽는 상황이다. 이런 일은 보통 하나의 서버에 두 구성원을 넣었을 때 발생한다. P와 A를 같은 서버에 돌아가고 있는 도중에 서버가 죽으면...

 

따라서, P, S, A는 최대한 각각 독립적인 환경으로 구성하는 것이 좋다.