[MongoDB] Replica Set

Replica Set은 HA(High Availability)를 보장해 주기 때문에 내부적으로 아키텍처가 복잡해지는 트레이드오프가 있음
이로 인해 우리가 꼭 알아야 하는 것들이 생긴다
개발자 입장에서 Replication에 대한 이해가 있어야 Replica Set을 이용한 몽고디비를 잘 활용할 수 있다

Replica Set

• 3대의 MongoDB 멤버 이루어진 구조
  • 1Primary, 2 Secondary
• HA(High Availability)에 대한 해결방안
• 멈춤 없이 지속적 운영이 필요한 서비스에서 필요한 최소 배포 단위
• 각 멤버는 같은 서버에 존재할 수도, 다른 서버에 존재할 수도 있다
  • replica set의 목적이 HA이기 때문에 각각 다른 서버에 설치되어 있어야 목적에 맞는 효과를 볼 수 있다
• 각 멤버는 상태값이 존재

Primary

• Replica Set에서 하나만 존재할 수 있다
• read/write 요청 모두 처리 가능
• write를 처리하는 유일한 멤버

Primary

• Read 요청만 처리 가능
• 복제를 통해 Primary와 동일한 데이터셋을 유지함
• Replica Set에 여러 개가 존재할 수 있다

Replica Set Election (Fail-Over)

• primary 멤버가 죽으면 쓰기에 대한 요청 처리 불가
  → 서비스 요구사항에 따라 장애로 판단할 수 있음
• Replica Set에서 primary가 없음을 인지하면 자동으로 primary를 선출. 자동 Fail-Over 진행
• 내부적으로 각 멤버들은 서로에게 heart beat를 날려 서로 살아있는지를 수시로 체크
• Primary에게 Heart beat를 요청했는데 답변이 없을 경우 선출 알고리즘을 통해 새로운 P를 선출
  • 선출 기준 예 : priority 설정값, 복제지연 없는지, 멤버 상태 등
  • 과반수의 표를 얻은 멤버가 primary가 된다
• 과반수 이상 표를 받으려면 홀수로 멤버 구성하는 것을 권장

투표할 수 있는 상태

• Primary, Secondary, Arbiter

PSS : Primary - Secondary - Secondary

PSA : Primary - Secondary - Arbiter

Arbiter

데이터를 들고 있지 않음

Primary 선출에만 참여하기 위한 멤버

비용 부담될 때 리소스가 적은 서버를 이용해서 Primary가 계속 살아있을 수 있다는 것을 보장하기 위해 사용하는 배포 형태

 

PSA 방식을 권장하지 않는 이유

• PSS에서 S가 하나 죽을 경우 모든 read가 나머지 하나의 S에 부하가 몰린다
• 그래도 P에는 부하가 늘지 않는다
• PSA에서는 S가 죽을 경우 읽기쓰기요청이 모두 P에 몰려 P에 부하 발생함
• → 서비스 장애 확률이 높아짐

⇒ 따라서 가능하면 PSA보다는 PSS를 권장

🔠 arbiter [│ɑːrbɪtə(r)] [명사] 결정권자

 

Replica Set Oplog

• 레플리카셋의 모든 멤버가 동일한 데이터를 유지할 수 있도록 하는 역할
• Primary에 쓰기요청이 들어오면 primary에 적용 후 local database에 있는 Oplog collection에 변경 사항을 기록
• 각 secondary는 비동기적으로 선반영되어있는 멤버의 oplog를 복사해오고 변경을 수행
• 꼭 Pimary에서만 oplog를 복사하는 것이 아니라 Secondary가 자신보다 앞서있는 다른 Secondary에서 oplog를 통해 복사해올 수도 있음

참고 : 패스트캠퍼스 백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리 초격차 패키지 강의