replication에 관한 책 내용을 정리한 후, 느낀 점을 적는다.
복제를 함으로써 다음 세 가지 장점을 얻을 수 있다.
- 디비 중 하나가 사용 불가 상태가 되어도 서비스 지속성을 유지할 수 있다.(high availability)
- read 처리량을 높일 수 있다.(high throughput)
- 유저의 위치에 따라 가까운 지역의 디비가 유저의 요청을 받을 수 있게 하여, 거리에 따른 네트워크 지연을 줄일 수 있다. (latency 감소)
위 세 가지는 분산시스템을 구성함으로써 얻을 수 있는 이점과 같다. 복제는 분산시스템의 한 형태이기에, 분산시스템의 장점을 가진다.
복제하는 방법은 리더와 follower를 어떻게 구성하느냐에 따라 달라진다. 리더는 유저에게서 write 요청을 가장 처음 받아서 처리하는 노드다. follower는 유저에게서 직접적으로 write 요청을 받지 않고, 리더가 write 요청을 처리한 후 리더에게서 간접적으로 write 요청을 받는다.
리더와 follower를 구성하는 방법은 다음과 같다.
- 리더를 하나로 구성 (single leader replication)
- 리더를 여러 개로 구성 (multi leader replication)
- 모두가 리더인 구성 (leaderless replication)
리더를 하나로 구성하는 경우, 리더가 하나이고 나머지 노드들이 follower다. 리더가 여러 개거나, 모두가 리더인 구성의 경우, conflict resolution 과정이 필요하다. 동시에 다른 내용의 write가 들어오고 각각 다른 리더에서 처리될 수 있기 때문이다. 각각 다른 리더에서 처리된 다른 내용의 write는 후에 conflict resolution이 필요할 것이다.
복제 과정에서, leader와 follower 간의 데이터는 불일치할 수 있다. leader와 follower간에 어떤 데이터가 복제되기 까지는 시간이 걸리며, 이 시간을 replication lag라고 한다. 보통 리더는 replication lag를 기다리지 않고 다음 요청을 처리한다.(비동기 처리) leader가 비동기 처리를 할 때 leader와 follower간 데이터 불일치가 발생한다. 이 불일치는 사용자에게 좋지 않은 서비스 경험을 준다. 예로 다음과 같은 문제가 있을 수 있다.
- 사용자가 자신의 프로필을 업데이트했다. 업데이트 직후에 프로필을 보니, 업데이트 이전 프로필이 나온다. (follower에게 업데이트 내용 복제가 완료되기 이전에 조회할 때 생길 수 있는 문제다.)
- 사용자가 데이터를 첫 조회할 때는 최신 데이터가 나왔는데, 두번째 조회할 때는 옛 버전의 데이터가 나왔다. (follower들간에 복제 속도가 다르기 때문에 생기는 문제다. 첫번째 조회 때는 복제가 완료된 follower를 조회했지만, 두번째 조회에는 복제가 미완료된 follower를 조회했다)
1과 같은 문제를 해결하기 위해, 업데이트 직후의 유저 요청은 leader가 처리하게 하는 방법을 사용할 수 있다. 또한 한 유저의 요청은 항상 하나의 follower만 처리할 수 있도록 하여 2와 같은 문제를 해결할 수 있다.
복제는 실무 데이터베이스 어디에나 있다. aws aurora mysql도 복제를 사용한다.(leader, writer db 설정 가능) 또한 elasticsearch도 복제를 사용한다.(샤드 복제 대수 설정 가능)
복제 과정에서 생길 수 있는 inconsistency는 실무에서 경험한 적 없는 것 같다.
복제 문제와 별개로, 동시성 이슈로 인해 write conflict가 생긴 경험은 있다. 책에서도 나와 있지만, 동시성 문제는 '동시'에 일어났기 때문에 벌어지는 문제가 아니다. 유저가 최신의 상태가 무엇인지 '모르는 채' 업데이트하기 때문에 발생하는 문제다. 책에서 동시성이라는 개념을 풀어주는 부분이 좋았다.
복제는 높은 처리량, 서비스 지속성, 지역 위치에 따른 지연 감소를 위해 사용한다.