LEO와 HW의 역할과 원리

Kafka는 분산 메시징 시스템으로서 데이터의 일관성과 내결함성을 보장하기 위해 LEO(Log End Offset)와 HW(High Watermark)라는 두 가지 핵심 오프셋 개념을 사용한다. 이들은 리더-팔로워 아키텍처 하에서 메시지의 영속성, 복제 상태, 그리고 소비자 접근 가능 여부를 결정하는 기준이 된다.

1. LEO: 다음 메시지가 저장될 위치

LEO는 각 브로커의 파티션 복제본이 현재까지 기록한 마지막 메시지의 다음 오프셋을 의미한다. 즉, 새로운 메시지가 쓰여질 위치를 가리킨다.

• 모든 복제본(리더 및 팔로워)은 자신만의 LEO 값을 유지한다.
• 리더에 새 메시지가 도착하면 그 즉시 리더의 LEO가 증가한다.
• 팔로워는 주기적으로 리더로부터 데이터를 풀(pull) 방식으로 가져와 자신의 로그에 추가하고, 성공 시 자신의 LEO를 업데이트한다.

2. HW: 안전하게 복제된 메시지의 경계

HW는 해당 파티션에서 모든 ISR(In-Sync Replicas)에 성공적으로 복제된 메시지까지의 오프셋을 나타낸다. 이 값은 파티션 수준에서 관리되며, 모든 복제본이 동일한 HW를 공유한다.

• 소비자는 HW보다 작은 오프셋에 있는 메시지만 읽을 수 있다.
• HW 이후의 메시지는 아직 일부 복제본에만 존재할 수 있으므로, 장애 발생 시 유실될 가능성이 있어 비가시적이다.
• HW는 리더가 ISR 내 모든 팔로워의 LEO를 모니터링하면서 결정된다.

3. LEO와 HW의 상대적 위치

파티션 로그 내에서 두 값의 관계는 다음과 같이 표현할 수 있다:

[안전 영역]     [위험 영역]
|------HW------|-----LEO-----|

• HW 이전: 모든 ISR에 복제 완료된 메시지. 소비 가능.
• HW ~ LEO 사이: 리더에는 있지만 일부 팔로워에는 없는 미복제 메시지. 소비 불가.

4. 오프셋 갱신 프로세스

1. 프로듀서가 메시지를 리더에 전송.
2. 리더는 메시지를 로컬 디스크에 기록하고, 자신의 LEO를 1 증가시킴.
3. 팔로워는 FETCH 요청을 통해 리더로부터 최신 데이터를 수신.
4. 팔로워가 메시지를 로그에 기록하면 자신의 LEO를 갱신.
5. 리더는 각 팔로워로부터 수신된 LEO 정보를 바탕으로, ISR 중 최소 LEO 값을 새로운 HW로 설정.

5. acks 설정이 HW에 미치는 영향

프로듀서의 acks 설정은 HW가 언제 증가하는지를 직접적으로 제어한다:

6. 리더 장애 복구 과정

리더 장애 시 카프카는 아래 절차를 통해 데이터 일관성을 유지한다:

1. ZooKeeper 또는 KRaft를 통해 새로운 리더 선출.
2. 새 리더는 자신의 로그를 기존 HW 위치까지만 유지하고, 그 이후 내용은 삭제(truncate).
3. 이 조치는 "커밋되지 않은 메시지"가 리더 변경 후에도 노출되는 것을 방지한다.
4. 기존 팔로워들은 새 리더의 HW 이후부터 데이터를 재동기화한다.

7. 복제 지연과 ISR 관리

팔로워가 네트워크 지연이나 리소스 부족으로 인해 LEO 갱신이 지체되면 다음과 같은 문제가 발생할 수 있다:

• HW가 정체되어 새로운 메시지가 커밋되지 않음.
• ISR에서 해당 팔로워가 제외됨 (시간 초과 시).
• min.insync.replicas 설정값보다 활성 복제본 수가 적어지면, acks=all인 경우 프로듀서 요청 실패.

8. 운영 및 모니터링 실무 팁

• LEO - HW 차이 모니터링: 이 값이 크면 복제 지연이 존재함을 의미하며, 장애 시 데이터 유실 창이 커진다.
• 메트릭 활용:
  • kafka.server:type=ReplicaManager,name=IsrShrinksPerSec: ISR 축소 빈도
  • UnderReplicatedPartitions: 복제 지연 파티션 수
• 명령어 예시:

# 파티션 오프셋 정보 조회
kafka-run-class.sh kafka.tools.GetOffsetShell \
  --bootstrap-server localhost:9092 \
  --topic my-topic \
  --time -1

# 파티션 구성 및 ISR 상태 확인
kafka-topics.sh --describe \
  --bootstrap-server localhost:9092 \
  --topic my-topic

9. 설계 시 고려사항

• 고신뢰성 요구 시: acks=all, min.insync.replicas=2 권장.
• 고스루풋 요구 시: acks=1 사용, 하지만 네트워크 분할 시 유실 가능성 감안 필요.
• 복제본은 반드시 다른 물리 서버나 랙(rack)에 배치하여 단일 장애점 방지.