토스 카프카 IDC 이중화 솔루션을 보고

 

토스에서 발표한 카프카 IDC 이중화 전략 발표영상을 보았습니다.

 

토스증권은 각종 주식데이터, 사용자데이터, 로그 등등 대부분의 곳에 카프카를 쓴다고 합니다.

그러므로 카프카의 가용성과 내고장성이 매우 중요한 상태고

단순한 브로커 이중화뿐만 아니라

DR의 일환으로, IDC 단위로 장애가 났을 때를 대비하여 IDC또한 이중화를 한다고 합니다.

 

다만 보통 IDC단위의 이중화를 할 때는 active-standby 모드로 구성합니다.

active를 사용하고 있다가 active에서 문제가 발생하면 standby가 active를 해주는 것이죠. 

 

하지만 active-standby 모델은 유지보수 관점에서 운영에 이슈가 있다고 합니다.

standby로 유지되던 것이 실제 장애가 발생하여 active역할을 수행하려고 할 때 여러 시스템, 호환, 관리의 부재 이슈로 active역할을 제대로 수행하지 못한다는 것이죠.

그래서 토스는 active-active 모델을 꾸렸습니다. 

 

active-active 모델을 사용했다고 했을 때, 다중리더인가? 그럼 서로간 복제시 쓰기충돌은 어떻게 해결하지? 싶었지만 그게 아니었습니다.

active 하나에 50%씩 데이터를 갖고, 2개의 active가 모여서 100%인 전체의 데이터를 갖는 것이죠.

그래서 active간 50%의 데이터 복제가 필요합니다. 

 

그럼 또 하나의 의문이 듭니다. 서로 복제한다면 결과적으로 consumer는 두번씩 소비하는 거고, 중복소비 아니야? 모든 메세지 소비가 멱등한가? 

답은 consumer는 하나의 IDC의 브로커에만 붙어있었습니다. active-active이긴 하지만, 한쪽의 IDC의 브로커에 컨슈머가 붙어서 main역할을 하고, 다른쪽은 메시지를 받고 main이 되는 브로커에 메시지를 복제하는 구조였습니다. 

 

결과적으로는 다음과 같습니다. 

 

IDC-A, IDC-B가 있을 때

애플리케이션은 IDC-A로 50%의 메시지를 발행하고, IDC-B로 50%의 메세지를 발행합니다.

그리고 IDC-A, IDC-B간 메세지 복제 & offset sync를 수행합니다.

컨슈머는 IDC-A에만 붙어서 메세지 소비를 합니다.

IDC-A에서 장애가 났을 때, 컨슈머는 IDC-B로 이동하여 메세지 소비를 합니다.

지금까지 메세지가 모두 복제 되었고, 컨슈머그룹의 offset 또한 동기화되었기 때문에 컨슈머들은 이어서 계속 메세지 소비를 할 수 있습니다.

 

영상은 이정도였고, 의문이 하나 생겼습니다. 

IDC의 브로커간 50%의 메세지를 받고, 합쳐서 100%를 만든다면

메세지의 순서가 보장되어야만 가능한 시스템인데, 이건 어느 레이어에서 어떻게 처리하는 것일까요? 

 

저의 의문을 시나리오로 표현하면 다음과 같습니다.

IDC-A, IDC-B 두개의 IDC에 구성된 카프카 클러스터가 있습니다. 컨슈머는 IDC-A에 붙어서 메세지를 소비중입니다. 

IDC-A 클러스터 토픽에 1,2가 발행되었고, IDC-B 클러스터 토픽에 3,4가 발행되었습니다.

IDC-A는 1,2를 IDC-B에 복제합니다. IDC-B는 3,4를 IDC-A에 복제합니다.

IDC-A의 토픽 파티션의 모습이 "1,2,3,4" 이고 컨슈머는 "3"까지 읽어서 offset을 50이라고 가정합니다. 

IDC-B의 토픽 파티션의 모습이 "3,4,1,2" 이고 offset sync에 의해 "3"을 찾고 이 offset은 100으로 동기화되었다고 가정합니다. 

이 때 IDC-A에 장애가 났고, 컨슈머는 IDC-B의 클러스터에 붙어서 소비를 계속합니다. 

그럼 1,2는 IDC-A에서 이미 소비되었는데 B에서도 소비되고 곧 중복소비가 되게 됩니다. 

이런식으로 중복소비 뿐만 아니라 소비를 건너뛰는 상황이 될 수도 있습니다.

 

그래서 IDC가 분리된 클러스터간 합쳐졌을 때 메세지의 순서가 보장되어야 할 것 같습니다.

그럼 어떤 레이어에서 어떻게 하고 있는 것일까? 궁금합니다.

 

 

+) kafka mirror maker2에 대해 한번 봐봐야겠습니다.

레코드 복제, offset sync를 모두 지원해주고 있는 것 같아요.

흠.. 어렵네요 미러메이커가 순서보장도 지원해주려나요?

아니라면 메세지에 유니크키와, 타임스탬프를 넣고 컨슘하는 곳에서 재조정해서 쓴다기엔, 누락 문제가 발생할 수 있어서 이쪽 레이어는 아닌 것 같구요.

그리고 생각해보면 kafka는 append only 구조이기 때문에 발행시점에 오더링이 되어야 할 것 같은데 말이죠. 

그럼 어플리케이션 레이어에서 오더링을 하는 것인가? 그렇다면 오더링을 한다고 하더라도 결국 각 클러스터에 50%씩 나눠갖게되고 복제하는 시점에 해줘야하는데.. 흠 흠흠 어렵네요