리플리케이션

카프카 기초에서 설명한 리플리케이션에 대해서 조금 더 상세히 설명하겠습니다.

카프카는 리플리케이션 기능을 통해 파티션을 복제해서 브로커에 분산하여 저장합니다. 리플리케이션을 통해 브로커에 장애가 발생해도 복제된 데이터를 통해 끊기지않고 안정적으로 서비스가 운영됩니다. replication-factor를 통해 리플리케이션 할 갯수를 지정하고, 일반적으로 3이면 안정적으로 동작합니다.

리더와 팔로워

카프카는 replication-factor의 수대로 리플리케이션을 설정하는데 만약 3이면 하나의 리더와 두 개의 팔로워가 생성됩니다. 카프카는 내부적으로 동일한 리플리케이션을 리더와 팔로워로 구분해서 역할을 분담시킵니다.

리더는 메시지의 수신과 전송을 담당합니다. 프로듀서는 오로지 리더에게만 메시지를 전송할 수 있고, 컨슈머는 리더를 통해서만 메시지를 읽을 수 있습니다.
팔로워는 평소에 지속적으로 리더의 상태를 확인하고 리더가 수신한 메시지를 복제합니다.

리더와 팔로워는 다시 ISR(InSyncReplica)이라는 그룹으로 크게 구분되며 동일한 ISR 그룹 내에 있는 팔로워만 해당 그룹 내의 리더를 대체할 수 있습니다. 다른 ISR 그룹에 속한 팔로워는 장애가 발생한 리더의 역할을 대체할 수 없습니다.

커밋

ISR 내의 팔로워는 리더의 데이터를 지속적으로 복제합니다.
ISR 내의 리더는 팔로워가 메시지를 복제할때까지 기다리고 메시지의 복제가 완료되면 커밋 되었다는 표시를 하며 리플리케이션 오프셋을 증가시킵니다. 마지막으로 커밋된 오프셋 위치를 하이워터마크(high water mark)라고 합니다.

리더는 팔로워의 리플리케이션 동작을 검사하는 역할을 수행합니다. 만약 팔로워가 특정 주기의 시간만큼 복제 요청을 하지 않으면 해당 팔로워가 문제가 있다고 판단해서 ISR 내에서 제외해버립니다.

컨슈머는 오직 커밋된 메시지만 읽어갈 수 있습니다. 커밋되지 않은 메시지를 가져가면 중간에 브로커에 장애가 발생할경우 장애 이전의 컨슈머는 커밋되지 않은 데이터를 읽어가고 장애 이후의 새로운 컨슈머는 커밋된 데이터만 읽어가게 되어 데이터에 불일치가 발생합니다. 따라서 카프카는 컨슈머가 오로지 커밋된 메시지만 가져갈 수 있게 제한하여 데이터의 일관성을 보장합니다.

리더와 팔로워의 리플리케이션 통신 동작

리더는 프로듀서, 컨슈머와 통신하고 팔로워들의 리플리케이션 동작도 감시해야 합니다. 팔로워의 리플리케이션 동작이 자주 발생하면 정작 중요한 메시지 송수신에 문제가 발생할 수 있어 카프카는 리더와 팔로워의 통신을 최소화하게 설계하여 리더의 부하를 줄였습니다.

리더와 팔로워는 아래의 예시 과정을 통해 리플리케이션이 성공했는지 실패했는지 통신하게 됩니다.

1. 리더는 오프셋 0번에 새로운 메시지를 받습니다
   

2. 팔로워는 리더에 오프셋 0번에 대한 fetch 요청을 보내고 메시지를 리플리케이션합니다.
   이 때까지 리더는 커밋 표시를 하지 않고 하이워터마크를 증가시키지 않습니다.
   

3. 리더는 오프셋 1번에 새로운 메시지를 받습니다
   

4. 팔로워는 리더에게 오프셋 1번에 대한 fetch 요청을 보냅니다. 모든 팔로워가 1번 오프셋에 대한 리플리케이션 요청을 전송하면 리더는 리플리케이션이 성공했다고 인지하고 오프셋 0에 대해 커밋 표시를 한 후 하이워터마크를 증가시킵니다.
   

5. 리더는 팔로워에게 1번 오프셋 메시지와 함께 0번 오프셋 메시지가 커밋되었다는 내용도 같이 전달합니다

6. 팔로워는 1번 메시지를 리플리케이션하고, 0번 오프셋에도 커밋을 표시합니다.
   

리더가 중간에 새롭게 메시지를 받지 않았는데 fetch 요청을 받을경우 커밋 표시를 진행하고 팔로워도 전달받은 메시지를 토대로 커밋 표시만 진행합니다.

카프카는 이렇게 리플리케이션 검증을 팔로워의 요청을 통해서 검증하므로 다른 메시지 큐 시스템과 달리 리더와 팔로워 사이의 ACK 인증을 제거하여 검증 속도를 향상시켰습니다. 또한 리더의 푸시 방식이 아닌 팔로워의 풀 방식을 채택하여서 리더의 부하를 추가적으로 줄였습니다.

리더 에포크

리더 에포크(Leader epoch)는 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 사용되는 숫자입니다. 브로커의 복구 동작 시 하이워터마크를 대체하는 수단으로도 활용됩니다.

만약 리플리케이션 동작 중 리더는 하이워터마크를 올렸는데 팔로워가 아직 하이워터마크를 올리라는 내용을 전달받지 못하는 상태에서 팔로워에 장애가 났을경우 팔로워는 가장 최신의 데이터를 제외하고 커밋이 최종적으로 수행된 상태로 다운됩니다.
이후에 팔로워의 장애 처리가 끝나 복구되었을 때, 팔로워는 자신의 하이워터마크보다 높은 메시지가 있을경우 리더에게 리더에포크 요청을 보내고, 응답을 확인 후 자신의 하이워터마크를 상향 조절하게 됩니다.

리더 에포크 번호는 리더가 변할때마다 하나씩 증가하고, 리더가 새로 선출될 때 파일의 가장 마지막에 리더에포크 번호와 최종 커밋 오프셋 번호를 저장합니다.

예) leader-epoch-checkpoint 파일에 저장된 리더 에포크 데이터

0
2    <- 현재 리더 에포크 번호. 3번째 리더 선출상황
0 0  <- 처음 카프카 로드되었을 때 상황. 의미없음
1 1  <- 1번 리더 에포크의 최종 커밋 후 새로운 메시지를 전송받게 될 오프셋 번호. 장애가 발생한 브로커가 복구되었을 때 0번 오프셋까지는 커밋되었다는 뜻.

카프카는 이렇게 리더 에포크를 활용해 장애 상황시의 리더와 팔로워 간의 메시지 불일치를 해결합니다.

실전 카프카 개발부터 운영까지 4장