image1

MongoDB ReplicaSet?

MongoDB의 레플리카 셋 구성 기능은 데이터베이스의 고가용성 환경을 위해 필요한 기술입니다.

DB 노드의 장애가 발생하거나, DB에 문제가 발생하는 경우에도 빠르게 장애에 대응하여 복구(failover) 하는 시간을 줄일 수 있는 장점을 갖게 합니다.

MongoDB는 자체적인 기능으로 복제 기능을 지원합니다.

레플리카 셋의 가장 큰 목적은 서비스 중인 MongoDB 인스턴스에 문제가 생겼을 때, 레플리카 셋의 구성원 중의 하나인 복제 노드가 장애 노드를 즉시 대체하는 것입니다.

어떠한 상황에서도 클라이언트와 DB와의 통신은 지속적으로 동작할 수 있도록 구성하는 가장 기본적인 물리적인 DB 설계 방식입니다.

MongoDB의 복제를 수행하기 위해서는 여러 mongodb 인스턴스가 모인 레플리카 셋이 필요합니다.

레플리카 셋의 구성원이 되면 서로의 정보를 동기화합니다.

구성

  • Primary: 클라이언트에서 DB로 읽기 및 쓰기 작업을 합니다.
  • Secondary: Primary로부터 데이터를 동기화합니다.
  • Arbiter: 데이터를 동기화하지는 않으며 레플리카 셋의 복구를 돕는 역할을 합니다.

레플리카 셋 안에서 구성원들 사이에는 주기적으로 10초에 한번씩 ping을 보내 서로의 노드를 확인하는 작업을 합니다.

이러한 작업은 MongoDB에서도 Heartbeat라고 부르며, 이 기능을 통해 노드 및 DB의 장애를 파악합니다.

장애가 발견되면 Secondary 노드 중 하나를 Primary로 올리게 되는데 이때 투표권을 가진 노드들이 Primary로 올리게 될 노드를 결정하여 Primary로 승급시키게 됩니다.


MongoDB의 레플리카 셋은 최소 3대 이상 의 구성원을 가지는 것을 권장하며, 홀수로 노드의 수를 늘리는 것을 권장하고 있습니다.

레플리카 셋이 Primary와 Secondary 둘 만으로 구성되어 있는 경우, Primary에서 장애가 발생한다면 Secondary 노드만 남게 됩니다.

레플리카 셋의 다수의 멤버 투표를 할 수 없는 상황이 만들어지는 것입니다.

그에 따라 Secondary는 고립된 노드로 남기 때문에 레플리카 셋이 정상적으로 동작하지 않게 됩니다.
따라서 레플리카 셋은 최소 3개의 세트로 구성을 해야 합니다.

만약 상황이 여의치 않을 때 DB로 사용할 수 있는 노드가 2개로 제한되어 있으면, 기타 다른 용도의 노드에 arbiter를 구성해 선거권만 주면 2대의 DB노드로도 레플리카 셋을 구성하는 것은 가능합니다.

PostgreSQL의 fork인 EDB에서도 비슷한 기능이 있는데, 실제 데이터를 가지고 있지 않아도, 한 개 노드가 장애가 발생 했을 시 과반수 이상의 투표권을 가지는 노드가 존재하게 되서 Secondary 노드를 Primary로 올리는 선거인단 역할을 하게 됩니다.

데이터가 쌓이지 않기 때문에 어플리케이션 노드 또는 다른 용도의 노드에 arbiter만 올려서 적은 리소스로도 사용이 가능합니다.

Primary

레플리카 셋에서 Primary 노드는 단 하나만 존재할 수 있습니다.

Primary만이 직접적으로 클라이언트와 정보를 주고 받기 때문에 Primary가 장애가 발생하거나 네트워크에 문제가 발생하면 실제 레플리카 셋이 구성되어 있더라도 Secondary가 Primary로 올라오는 동안 실제 데이터를 읽고 쓰는 것이 일시적으로 중단될 수 있습니다.

Secondary

Secondary의 가장 중요한 역할은 Primary 노드로부터 데이터를 동기화하고, 장애 시 Primary로의 역할 전환에 있으며,
Primary의 장애 상황에서 어떤 Secondary 노드를 Primary로 올릴 것인지 투표권을 가지고 있습니다.


그리고 Primary의 읽기 작업을 분담할 수 있습니다.

이것은 여타 다른 오픈소스 DBMS들 역시 가지고 있는 기능인데, DB의 작업들이 대부분 읽기에서 많이 발생하기 때문에 읽기 작업을 복제 노드로 분산시켜 DB의 읽기 부하를 줄이는 역할을 합니다.

하지만 Primary와 Secondary의 동기화 시간이 즉각적이지 않기 때문에 실시간 반영이 필요한 부분에서는 적용하기가 다소 어려운 부분이 있고, 실시간 반영이 필요하지 않은 부분에서는 읽기 작업에 대한 역할을 Secondary에 분산시켜 부하를 줄일 수 있습니다.


마지막으로 지연된 읽기 복제 기능을 수행합니다.

실제 Primary에 쓰기 작업이 발생하여 데이터가 생성되어도 일정 시간 간격을 두고 복제를 진행하기 때문에 사람의 실수를 방지하고, 패치나 배치 작업 이후 DB를 되돌려야 하는 기능이 발생 했을 때 지연된 시간만큼 원래 데이터로 복구가 가능해 집니다.

또 지연된 복제 기능으로 구성된 Secondary 노드는 투표권이 없고, 장애 발생 시 Secondary 노드가 가지는 기능인 예비 Primary 노드의 역할을 하지 않습니다.

오로지 수동으로만 Primary로 승격이 가능합니다.

Arbiter

arbiter 노드의 역할은 위에서 설명했듯이, 레플리카 셋을 3대 이상의 홀수로 구성할 수 없을 시, 투표권만을 가지고 레플리카 셋을 모니터링하는 역할을 합니다.

레플리카 셋은 하나의 구역에 구성하는 것보다는 되도록이면 서로의 환경에서 독립하여 여러 지역으로 분산하는 것이 좋습니다

Read/Write Traffic 분산

Read Preference (읽기 선호도)

primary

  • 기본 설정, 유일하게 일관성이 보장 됨
  • 모든 Read 작업을 Primary에서 실행
  • Read 작업을 포함하는 multi-document 트랜잭션의 경우 반드시 Primary 설정으로 해야 합니다.
    그래서 모든 작업이 동일한 노드의 데이터로 작업할 수 있습니다

primaryPreferred

대부분의 경우에는 Primary에서 Read 작업을 진행하고, 이용이 불가능한 경우에만 Secondary에서 진행합니다.


secondary

모든 Read 작업을 Secondary에서 실행


secondaryPreferred

대부분의 경우에는 Secondary에서 Read 작업을 진행하고, 이용이 불가능한 경우에는 Primary에서 진행합니다.


nearest

Primary, Secondary 상관 없이 지정한 latency threshold에 부합한 곳에서 Read 작업을 실행


이것으로 MongoDB의 ReplicaSet에 대해서 알아보았습니다.