Kafka 리더 에포크 개념 및 분석 방법
메시지 브로커 시스템 중 가장 많이 사용되는 카프카에 대해 공부 중인데 이번 게시글에서는 리더 에포크(Leader Epoch)에 대한 기본 개념과 함께, 리더 에포크 정보를 확인하고 분석하는 방법을 다루고자 한다.
[01] 먼저 리더에포크와 하이워터마크에 대해 알아보자.
리더 에포크란?
리더 에포크는 카프카에서 파티션 리더의 리더십 기간을 나타내는 중요한 개념이다. 파티션에 새로운 리더가 선출될 때마다 리더 에포크가 증가한다.
파티션 리더가 다운되었을 때 팔로우 파티션들은 리더십의 타임라인을 추적하여, 파티션을 효율적으로 복구하고 동기화할 수 있다.
리더에포크를 간단한 비유로 설명하기
리더 에포크를 학교의 반장 선거로 생각해보자. 반장이 새로 뽑힐 때마다 그 반장은 새로운 임기를 시작하게 된다. 이 임기를 리더 에포크라고 할 수 있는데 만약 반장이 문제가 생겨 교체되면,새로운 반장이 그동안 일어난 일들을 정리하고 반 친구들과 정보를 공유하면서 일을 이어가게 된다. 이 과정이 리더 에포크를 이용한 복구라고 생각하면 쉽다.
하이워터마크란?
하이워터마크는 카프카에서 파티션의 모든 복제본이 동기화된 오프셋을 나타내는 지표이다.
하이 워터마크는 소비자가 모든 복제본에 동기화된 커밋된 메시지만 읽을 수 있도록 보장하며 이 개념은 카프카 클러스터 내에서 데이터 무결성과 일관성을 유지하는 데 매우 중요한 역할을 한다.
하이워터마크를 간단한 비유로 설명하기
하이 워터마크를 책갈피로 생각해보자. 책을 여러 사람이 동시에 읽고 있다고 가정했을 때, 모든 사람이 같은 페이지까지 읽고 있어야 이야기가 혼란스럽지 않는데 이 책갈피가 하이 워터마크라고 생각하면 쉽다. 책갈피가 있는 페이지까지는 모두 읽었고, 그 페이지 이후부터는 함께 읽어야 한다는 것을 의미한다. 이렇게 하면 모든 사람이 같은 내용을 이해하고 같은 지점까지 이야기를 따라가게 된다.
[02] 리더에포크가 필요한 이유
1. 상황 구성
- 리더 파티션은 message2를 받고 오프셋을 1로 변경한 후 하이 워터마크를 2까지 올린 상황
- 팔로워는 오프셋 2인 message2를 리플리케이션했지만, 아직 리더에게 하이 워터마크를 2로 올리라는 지시는 받지 못함
2. 리더 팔로워의 다운타임 (리더 에포크가 없는 경우)
- 팔로워가 새로운 리더(뉴 리더)로 승격된 상태이다.
- 뉴리더가 된 팔로워는 자신보다 높은 하이 워터마크를 삭제하면서 message2를 삭제하게 되어 message2가 손실된다.
3. 리더 팔로워의 다운타임 (리더에포크가 있는 경우)
- 리더 에포크를 사용하면 자신의 하이 워터마크보다 높은 메시지를 무조건 삭제하는 대신, 리더에게 리더 에포크 요청을 보낸다.
리더의 응답을 확인한 후 message2까지 자신의 하이 워터마크를 상향 조정합니다.
- 리더 에포크를 활용하면 데이터 손실을 방지하고, 모든 복제본이 일관된 상태를 유지할 수 있으며. 클러스터의 안정성과 신뢰성을 크게 향상시킨다.
[03] 리더에포크 로그 확인 및 분석
1. 토픽 생성 (파티션 1개 , 리플리케이션 팩터 2개)
/usr/local/kafka/bin/kafka-topics.sh --bootstrap-server '카프카서버정보' --create --topic '토픽이름' --partitions 1 --replication-factor 2
2. 토픽 설명 보기
/usr/local/kafka/bin/kafka-topics.sh --bootstrap-server '카프카서버정보' --topic '토픽이름' --describe
Topic: '토픽이름' PartitionCount: 1 ReplicationFactor: 2 Configs: segment.bytes=1073741824
Topic: '토픽이름' Partition: 0 ① Leader: 2 ② Replicas: 2,1 ③ Isr: 2,1
① 리더는 2번 브로커이다.
② 리플리케이션 된 팔로워는 1번 브로커이다.
③ ISR (In Sync Replica) ISR에 속해 있는 구성원만이 리더가 될 자격을 가질 수 있다.
3. 메시지 전송
/usr/local/kafka/bin/kafka-console-producer.sh --bootstrap-server '카프카서버정보' --topic '토픽이름'
>test message1 # 메시지 발송
- ‘test message1’이라는 테스트 메시지를 발송하였다.
4. 리더에포크 정보 조회
cat /data/kafka-logs/'토픽이름'/leader-epoch-checkpoint
# 결과
0
1 # 리더에포크 번호
0 0 # 첫번째 0은 리더에포크 번호, 두번째 0은 최종 커밋 후 새로운 메시지를 전송 받게 될 오프셋 번호
- 리더에포크는 처음 생겼기 때문에 1회 생성이고, 0 0은 첫번째 리더에포크가 가지고 있는 오프셋 0이라고 생각하면 된다.
- 1번째 리더에포크가 가지고 있는 오프셋은 0(첫번째 메시지)이다.
4. 리더 파티션 종료 후 리더에포크 정보 조회
# 리더 파티션 종료
sudo systemctl stop kafka-server
# 리더에포크 조회
cat /data/kafka-logs/토픽이름/leader-epoch-checkpoint
# 결과
0
2 # 리더에포크 번호가 +1 증가
0 0
1 0 # 현재 리더에포크 번호는 1이고, 세로운 메시지를 전송받게 될 오프셋은
- 2번째 리더에포크가 가지고 있는 오프셋은 0(첫번째 메시지)이다.
5. 메시지 재발송 및 리더 파티션 종료 후 리더에포크 정보 조회
// 종료했던 카프카 서버는 다시 실행
sudo systemctl start kafka-server
// 두번째 메시지 전송
/usr/local/kafka/bin/kafka-console-producer.sh --bootstrap-server '카프카서버정보' --topic '토픽이름'
>test message2 <---- 메시지 발송
// 리더 파티션 종료
sudo systemctl stop kafka-server
// 리더에포크 정보 조회
cat /data/kafka-logs/토픽이름/leader-epoch-checkpoint
0
3 ① 리더에포크 번호가 +1 증가
0 0
1 0
2 1
- 3번째 리더에포크가 가지고 있는 오프셋은 1(두번째 메시지)이다
[04] 정리
리더 에포크의 개념과 로그 확인 방법을 알아두면 각 리더 파티션이 어떤 시점에 어떤 오프셋을 가지고 있는지 확인할 수 있어 에러 상황 대처에 매우 유용할 것으로 생각된다. ISR에 대한 설명이 부족하였는데 다음 게시글은 ISR에 대한 개념과 새로운 리더를 선출할 경우 리밸런싱이 어떻게 진행되는지 정리해보겠다.