복제 동작
통신 방식
- 다른 메세지 큐와 다르게 리더가 push해서 복제하는 것이 아닌 팔로워가 pull 해서 메세지를 복제하는 방식
- 팔로워는 리더에게서 가져간 message를 다 복제하면 리더에게 해당 사항을 공지
- 이러한 방식을 사용했기 때문에 리더와 팔로워 간의 복제 동작이 매우 빠르면서 신뢰할 수 있는 장점이 존재
- read/write로 바쁜 리더의 복제를 위한 통신에 대한 역할을 줄여주기 때문에 리더의 부하를 줄일 수 있음
- 위와 같은 방식을 통해 리더가 ISR 목록을 구성할 수 있게됨
High Watermark (하이 워터마크)
- ISR 그룹 내에서 팔로워들이 리더의 특정 지점까지 복제가 완료되면 리더는 내부적으로 해당 메세지(오프셋)까지 commit 처리를 진행
- 마지막으로 commit을 완료한 오프셋의 위치를 하이 워터마크라고 지정
- 컨슈머는 하이 워터마크 이후의 데이터를 가져갈 수 없음 -> 그 이후의 데이터는 복제에 대한 검증이 되어있지 않기 때문
복제 동작 과정
- jade-test01 이라는 토픽 내 파티션 1개, 리플리케이션 팩터 2로 지정된 환경
- 리더는 프로듀서로부터 message1(오프셋)를 받아 자신의 파티션에 저장
- 팔로워가 리더에게 fetch 진행, message1(오프셋0)의 존재를 확인하고 복제 진행
- 리더는 모든 팔로워가 message1(오프셋0)에 대해 요청을 보낸것을 확인하고 하이 워터마크를 1로 올림
- 리더는 프로듀서로부터 message2(오프셋1)를 받아 자신의 파티션에 저장
- 팔로워가 리더에게 fetch 진행, 리더의 하이 워터마크의 변화를 확인하고 팔로워 자신의 하이 워터마크를 1로 올림
- 팔로워는 message2(오프셋1)에 대해 복제 진행
- 팔로워는 오프셋2(message X)에 대한 요청을 보내고, 요청을 받은 리더는 하이 워터마크를 2로 올림
- 팔로워는 1번 오프셋인 message2까지 복제를 완료했지만 아직 리더로부터 하이 워터마크를 2로 올리는 내용을 전달받지 못한 상태
장애 복구
Leader Epoch (리더 에포크)
- 카프카의 파티션들이 복구 동작을 할 때 메세지의 일관성을 유지하기 위한 용도로 사용
- 컨트롤러에 의해 관리되는 32비트의 숫자로 표현
- 복구 동작 시 하이 워터마크를 대체하는 수단
- 리더 에포크가 없을 시 팔로워는 자신의 하이 워터마크 보다 높은 message를 전부 삭제 처리 진행
장애 복구 동작 과정
- 위의 복제 동작 과정을 이어서 진행
- 팔로워는 1번 오프셋인 message2까지 복제를 완료했지만 아직 리더로부터 하이 워터마크를 2로 올리는 내용을 전달받지 못한 상태에서 예기치 못한 장애로 인해 팔로워 다운
- 장애 후 다시 동작하기 시작한 팔로워는 복구 동작을 하며 리더에게 리더 에포크 요청을 보냄
- 리더는 리더 에포크 응답으로 자신의 하이 워터마크 정보(message2-오프셋1)를 팔로워에게 보냄
- 팔로워는 자신의 하이 워터마크보다 높은 message2(오프셋1)을 삭제하지 않고 리더의 응답을 확인한 후 자신의 하이 워터마크를 2로 조정
- 위의 과정을 통해 리더와 팔로워의 하이 워터마크가 동기화되었기 때문에 리더 파티션에 장애가 발생해도 메세지 손실이 발생하지 않음
