Replication Internals

데이터의 유실을 방지하고(Durability), 브로커 장애 시에도 서비스 중단 없이 운영될 수 있도록(High Availability) 하는 핵심적인 내부 동작 원리이다.

리더와 팔로워 모델

카프카는 각 토픽 파티션에 대해 리더(Leader)와 팔로워(Follower) 역할을 부여하는 모델을 사용한다.

파티션 복제본(Replica)
- 토픽 생성 시 지정한 replication-factor 만큼 각 파티션의 복제본 생성
- 복제본들은 클러스터 내 여러 브로커에 분산 저장되어 하나의 브로커에 장애가 발생하더라도 데이터 유실 없이 운영 가능
리더(Leader)
- 각 파티션의 여러 복제본 중 단 하나만이 리더 역할 수행
- 프로듀서의 모든 쓰기 요청과 컨슈머의 모든 읽기 요청은 오직 리더를 통해서만 처리
팔로워(Follower)
- 리더를 제외한 나머지 복제본들은 팔로워 역할 수행
- 팔로워는 어떠한 읽기/쓰기 요청에도 관여하지 않으며, 오직 리더로부터 데이터를 순서대로 가져와 자신의 로그에 기록하는 역할만 수행

리더와 팔로워가 데이터 동기화를 유지하는 방식은 카프카 복제 메커니즘의 핵심이다.

로그 끝 오프셋(Log End Offset, LEO)
- 각 복제본(리더, 팔로워)이 가지고 있는 로그의 마지막 오프셋을 의미
- 팔로워는 리더에게 주기적으로 데이터를 요청(Fetch Request)하여 자신의 LEO를 리더의 LEO와 일치시키려 노력
ISR(In-Sync Replicas)
- 동기화 상태를 유지하고 있는 복제본들의 집합을 의미(리더 자신도 포함)
- 팔로워가 ISR에 포함되기 위한 조건
  - 팔로워의 LEO가 리더의 LEO와 거의 동일한 수준이어야 함
  - replica.lag.time.max.ms 설정 시간 내에 리더로부터 새로운 데이터를 fetch해야 함
ISR과 프로듀서 acks=all 설정의 관계
- 프로듀서가 acks=all 옵션으로 메시지를 전송하면, ISR에 포함된 모든 팔로워가 해당 메시지를 복제했음을 확인 후 응답(Ack) 전송
- 이를 통해 ISR 내에서는 데이터 유실 없는 전송 보장 가능

리더 역할을 하던 브로커에 장애가 발생하면, 클러스터는 서비스 중단을 막기 위해 팔로워 중 하나를 새로운 리더로 선출해야 한다.

선출 과정
- 클러스터의 컨트롤러(Controller) 브로커가 특정 파티션 리더의 장애 감지
- 컨트롤러는 해당 파티션의 ISR 목록에서 살아있는 팔로워 중 하나를 새로운 리더로 지정
- 새로운 리더가 지정되면, 클러스터의 다른 브로커와 클라이언트들은 메타데이터를 갱신하여 새로운 리더와 통신 시작
비정상 리더 선출 (Unclean Leader Election)
- 만약 브로커 장애로 인해 ISR에 리더 자신 외에 아무도 없는 상황이 발생하면, 옵션에 따라 두 가지 방식으로 처리
- unclean.leader.election.enable=false: 새로운 리더를 선출하지 않고 파티션을 사용할 수 없게 만들어 데이터 정합성을 우선(Consistency)
- unclean.leader.election.enable=true: ISR에 없던 팔로워라도 리더로 선출하여 서비스를 계속하도록 허용한다. 가용성을 우선(Availability)

복제 과정에서 아직 모든 복제본에 동기화되지 않은 데이터를 컨슈머가 읽어가는 것을 방지하기 위해 High Watermark라는 메커니즘을 사용한다.

High Watermark
- ISR에 포함된 모든 복제본들이 공통적으로 가지고 있는 가장 높은 오프셋을 의미(안전하게 복제되었다'고 보장되는 메시지의 위치)
- HWM은 ISR 내에서 LEO가 가장 낮은 복제본(가장 느린 팔로워)의 위치를 기준으로 결정
HWM의 역할
- 컨슈머는 오직 HWM 이전의 오프셋에 해당하는 메시지만 조회 가능
- 리더에만 기록되고 아직 팔로워들에게 완전히 복제되지 않은 데이터가 외부로 노출되는 것을 막아 데이터 정합성 보장

Last updated 17 days ago

Was this helpful?