데이터베이스의 복제 그리고 몽고디비는 어떤 방식인가?

들어가기 전

 

 이전에 Node.js를 사용하여 채팅 애플리케이션을 만들어본 적이 있습니다. 그때는 프로그래밍을 처음 배우기 시작했을 터라 성능보다는 기능을 만들어보는데 집중하여 제작했었습니다. 그래서 이번에는 기능보다는 성능, 보안 쪽으로 포커스를 두고 채팅 애플리케이션을 제작하고 있는 중입니다.

 

 제작 중인 채팅 애플리케이 션은 채팅이라는 특성상 응답 속도가 매우 중요하기 때문에 Redis(민메모리 캐시 서버)와 MongoDB 복제 서버를 구성해 읽기 속도를 개선시켜 보자 합니다. 그래서 오늘 준비한 토픽은 데이터베이스의 복제에 관련돼서 간략하게 설명하고 몽고디비는 어떤 복제 방식을 사용하는지 알아보겠습니다.

 

데이터 베이스의 복제

 

1. 복제가 왜 필요한가?

 1.1 가용성 증가

 어느 시스템이든 장애는 발생합니다. 만약 백앤드를 구성하고 있는 데이터베이스가 한 개라면 해당 데이터베이스에 장애가 발생할 시 지속적으로 서버를 운영하기 힘들 것입니다. 하지만 데이터를 복제해 여러 장비에 동일한 데이터를 담아둔다면 일부 장비에 장애가 발생하더라도 복제한 데이터가 존재하기에 지속적인 운영이 가능합니다. 

 

 1.2 지연시간 감소

 데이터는 지리적으로 한 지역뿐만 아니라 여러 지역으로도 설치된 장비만 있다면 복제가 가능합니다. 지리적으로 사용자와 데이터가 가까울수록 지연시간은 감소되며 또한 복제한 장비가 많을수록 읽기 처리를 담당하는 장비수가 많기에 읽기 처리량이 증가합니다. 그로 인해  사용자는 원하는 응답을 보다 빠르게 받을 수 있습니다.

 

읽기, 쓰기는 리더 서버, 팔로워서버는 오로지 읽기만 담당하는 그림(마스터- 슬레이브 복제)

 

2. 동기, 비동기

 2.1 동기식 복제 

 동기식으로 작동하는 팔로워는 리더의 응답을 기다렸다 그 즉시 처리합니다. 그렇기에 최신 데이터 값을 리더와 일관성 있게 보유하는 것을 보장할 수 있습니다. 하지만 팔로워의 장애에는 취약합니다. 팔로워의 장애로 인해 리더에게 응답하지 못한다면 리더는 응답만을 기다리고 있습니다. 그렇기에 모든 팔로워를 동기식으로 구현하는 것은 옳지 않습니다.

 

 2.2 비동기식 복제 

 비동기식으로 작동하는 팔로워는 동기식과 반대입니다. 비동기적으로 데이터를 처리하기 때문에 동기식보다 지연될 수도 있습니다. 하지만 동기식의 문제인 팔로워 장애로 인한 문제는 발생하지 않습니다. 다만, 리더에 문제가 생긴다면 아직 복제되지 않은 데이터들이 유실됩니다.

 

 2.3 반동기식 복제의 사용

 위와 같은 문제점들로 인해 동기식과 비동기식을 같이 사용하며, 동기식 팔로워에 장애가 발생할 경우 비동기식 팔로워 중 하나를 동기식으로 변경해 주는 방법인 반동기식 복제를 사용합니다. 해당 방식은 적어도 두 노드에 최신의 복사본이 있는 것을 보장합니다.

 

 

 

MongoDB의 복제는 어떤 방식인가?

 

1. 마스터-슬레이브 복제

 Mongo는 3.2 버전 이전에는 마스터-슬레이브 복제 방식을 사용했습니다.(해당 포스트 첫 번째 그림이 마스터-슬레이브 동작 방식입니다), 

 

 1.1 동작 방식 : 쓰기 동작

  1) 복제 서버 중 하나를 리더(마스터)로 지정

 

  2) 쓰기 요청이 들어오면, 리더(마스터)는 로컬에 데이터 저장 후, 복제 로그 또는 변경 스트림의 일부를 팔로워(슬레이브)에게 전송

 

  3) 각 팔로워(슬레이브)는 리더(마스터)가 처리한 것과 동일한 순서로 복사본 갱신

 1.2 동작 방식 : 읽기 동작

  1) 클라이언트가 읽기 접근

 

  2) 팔로워(슬레이브)에서 데이터를 읽어옴

 

* 리더(마스터)는 읽기, 쓰기 둘 다 지원하지만 팔로워(슬레이브)는 읽기 전용입니다. 

 

2. Replica set 복제

 Replica set 복제는 마스터-슬레이브 복제와 큰 차이는 없습니다. 마스터-슬레이브의 명칭이 Primary, Secondary로 변했으며 기존의 마스터-슬레이브 방식의 단점을 보완한 방식입니다. 

 

  2.1 마스터-슬레이브 복제의 단점 

 마스터-슬레이브 복제 방식의 단점은 모든 쓰기를 리더(마스터)가 처리한다는 것입니다. 어떠한 장애로 인해 리더가 동작을 하지 않으면 더 이상 데이터베이스에 쓰기 작업을 할 수 없습니다. 

 

  2.2 Replica set 복제는 어떻게 장애복구를 하였나?

 해당 포스트를 처음부터 읽어오신 분들은 어느 정도 짐작하셨을 거라 생각합니다. 반동기식으로 운영을 하여 primary(리더) 노드에 문제가 생겼을 경우 secondary(팔로워) 노드들끼리 투표를 하여 새로운 primary(리더) 노드를 선정하여 장애를 복구합니다.