나는 왜 다중 클러스터의 구조를 다중 리더의 구조라고 착각했는가?
이는 대충 알고 있기 때문일 것이다.
우리가 일반적으로 사용하는 레디스, 몽고에서의 다중 클러스터의 구조는 실제로 단일 리더로 작동하는 것은 맞다.
다만 다중 클러스터 구조의 의의는 장애 전파 차단과 확장성 의 측면일 뿐이다.
다중 리더랑 분명히 구별지어서 생각해야하는데, 다중리더는 말 그래도 한가지 요청에 대해 N개 이상의 노드에다 write을 하는 것이다.
이렇게 되버리면 어떻게될지 생각해보자.
데이터 충돌이 분명히 발생한다.
한국에 사는 내가 보낸 요청이 한국region의 노드에도 쓰이고, 미국 region의 노드에도 쓰이고 (by 복제),
미국에 사는 A가 보낸 요청은 미국 region에 먼저쓰이고, 한국region에도 쓰일것이다.
그러면 각 region의 노드들은 데이터 충돌을 어떻게 감지해야할 것인가? 이것에 대한 전략자체는 DB에게 위임한다.
그렇기에 더욱 쓰임이 애매한 DB 아키텍쳐일 것이다. 책에서 나온 예시로는 google docs 동시편집 기능을 예시로 들더라.
두가지 측면이다.
다중 클러스터는 DR을 위함이다.
만일 A, B클러스터 두가지를 운영하고 있는데,
A가 죽을경우, B가 대신 Active하게 전환되는 것. 그것이 Failover이다.
하지만, 데이터 유실을 어떻게할것인가?
이를 위해서 데이터 유실을 최소화 하기위한 전략을 수립하고,
비동기복제를하든, 동기복제를하든, 로그기반 복제를하든 할것이다.
리더없는거 진짜 왜씀?
데이터 정합성도 꼬이고, 모든 노드에 다 write하게되는게 무슨 의미가있는가? 라고 생각했지만..
괜히 쓰이는게 아니더라.
fan-out-write가 급증하는 상황을 보자
예를들어 한명의 인플루언서가 하나의 게시글을 올리고 천만명의 팔로워가 해당 게시글을 읽어들여야할때.... 이상황을 어떻게할것인가?
사용자가 팔로우한 사람의 게시글을 읽어야하므로, 사용자가 보는 데이터에는 인플루언서가 올린 게시글이 포함되게끔 write이 필요할 것이다.
그럼 총 1000만개의 row나 document대상으로 write이 발생해야되는데.... 이걸 실제 DB가 감당할 수 있을까?
그렇기에 write노드를 여러개 동시에두고, N개의 노드중 W개의 노드에 쓰는 개념인거다.
어떤 노드들인지 간에 write에 참여하게 하고, 팔로워들을 특정 키값으로 데이터를 샤딩하게 된다면...?
근데 여기서 또 생기는 궁금증은 그럼 이게 multi-leader랑 뭐가다른데?
하지만 근본적으로 다르다. multi-leader는 데이터 여러개가 '중복'되어 각 leader에게 요청을 보낼 수 있는 것이겠지만, leaderless는 샤딩의 개념이 들어간다고 보면 된다. 즉 데이터 키값기반으로 데이터를 저장하고 write하는 노드 set은 키값기반으로 정해져있다
그러면 데이터정합성이 깨질 수 있는 상황이 발생할수도? (네트워크지연으로 key값 기반으로 a,b,c 노드 정해서 읽었는데, a노드가 장애상황이어서 outdated한 데이터값가지고 있으면 어떻게판별?)
그렇기에 데이터정합성이 중요하지 않은 비즈니스로직에서 leaderless 아키를 사용하기도 하고, 결국엔 (eventual)하게는 나중에는 outdated가 해결될 문제일 것으로 보인다. (그 전략을 vector로하든 LWW으로 하든..)
-> 데이터를 chunk단위로 잘라서 db write을 하는 프로세스를 배치로 돌리든 개별 프로세스로 띄우든... 큐잉을 하든... (근데 지연은 생기겠지)
RDB에는 몽고디비처럼 특정 클러스터의 secondary 노드대상으로 읽는 기능이 없고, 직접 인스턴스를 지정해줘야함.. 신기하더라