티스토리 뷰
개요
이번에는 카프카 내부 동작 원리로 브로커의 파티션들이 장애 복구를 하는 과정에 대해 정리해보겠다.
리더 에포크(Leader Epoch)
리더 에포크는 Kafka에서 파티션 리더가 변경될 때마다 증가하는 번호로, 리더 변경 히스토리를 기록하며 데이터 동기화와 복구 동작에 활용된다. 이는 팔로워가 부족한 데이터를 동기화할 범위를 결정하고, 메시지의 순서와 일관성을 유지하기 위해 사용된다.
리더 에포크가 없는 장애 복구 과정의 문제점
브로커가 복구 동작을 하는데 왜 리더 에포크가 필요한지 알기 위해서는 먼저 리더 에포크가 없을 때 발생하는 문제점에 대해서 알아봐야한다.
peter-test01 토픽의 파티션 수는 1, 리플리케이션 팩터 수는 2, min.insync.replicas는 1인 상황이다. 리더 에포크가 없다는 가정하에 장애로부터 복구되는 과정을 보자.
1. 리더는 프로듀서로 부터 message1 메시지를 받고, 0번 오프셋에 저장, 팔로워는 리더에게 0번 오프셋에 대한 가져오기(fetch)요청을 보낸다.
2. 가져오기 요청을 통해 팔로워는 message1을 리더로 부터 리플리케이션 해온다.
3. 리더는 하이워터마크를 1올린다.
4. 리더는 프로듀서로부터 다음 메시지인 message2를 받은 뒤, 오프셋 1에 저장한다.
5. 팔로워는 다음 메시지인 message2에 대해 리더에게 가져오기 요청을 보내고, 응답으로 리더의 하이워터마크가 1로 변했다는 것을 응답 받아 자신의 하이워터마크도 1 올린다.
6. 팔로워는 1번 오프셋의 message2 메시지를 리더로부터 리플리케이션 한다.
7. 팔로워는 2번 오프셋에 대한 요청을 리더에게 보내고, 요청을 받은 리더는 하이워터마크를 2로 올린다.
8. 팔로워는 1번 오프셋인 message2까지 리플리케이션을 완료했지만, 아직 리더로부터 하이워터마크를 2로 올리라는 내용은 전달 받지 못한 상태이다.
9. 예상치 못한 장애로 팔로워가 다운된다.
팔로워가 다운된 이후, 다시 재개되면서 내부에서 메시지 복구 작업을 수행한다.
1. 팔로워는 자신이 갖고 있는 메시지들 중에 자신의 하이워터마크보다 높은 메시지는 신뢰할 수 없다고 판단하여 삭제한다.
(1번 오프셋의 message2는 삭제됨.)
2. 팔로워는 리더에게 1번 오프셋의 새로운 메시지에 대한 가져오기 요청을 보낸다.
3. 이 순간 리더 브로커가 장애로 다운되면서, 해당 파티션의 유일한 팔로워가 새로운 리더로 승격된다.
팔로워가 새로운 리더로 된 후의 상태를 나태낸 것이다. 리더 에포크를 적용하지 않은 경우 팔로워가 message2 메시지를 갖고 있음에도 불구하고, 복구 과정에서 하이워터마크 보다 높은 메시지를 삭제했기 때문에 메시지 손실이 발생하였다.
하지만 리더 에포크를 적용하면 리더 에포크 요청과 응답과정을 통해 팔로워가 하이워터 마크를 올릴 수 있고 메시지 손실은 발생하지 않게 된다.
리더 에포크 사용한 장애 복구 과정
팔로워가 장애로 종료된 후 막 복구된 상태 이후의 과정부터 다시보자. 리더 에포크를 사용하지 않을 때는 복구 동작을 통해 자신의 하이워터마크 이후 메시지를 즉시 삭제했다.
리더 에포크를 사용하면 하이워터마크 이후 메시지를 무조건 삭제 하지않고 리더 에포크 요청을 보낸다.
1. 팔로워는 복구 동작을 하면서 리더에게 리더 에포크 요청을 보낸다.
2. 요청을 받은 리더는 리더 에포크 응답으로 '1번 오프셋의 message2까지'라고 팔로워에게 보낸다.
3. 팔로워는 자신의 하이워터마크보다 이후인 message2를 삭제하지 않고, 리더의 응답을 확인하고 message2까지 자신의 하이워터마크를 상향 조정하게된다.
그럼 이제 동일하게 리더가 예상치 못한 장애로 다운되어서 팔로워가 뉴리더로 승격되어도 메시지 손실은 발생하지 않게된다.
리더 에포크 실습
이제 리더 에포크를 사용한 장애 복구 과정의 이점을 이해했으니, 실제 Kafka에서 리더 에포크 요청과 응답이 어떤 데이터를 활용하는지 실습을 통해 살펴보겠다.
실습에 사용한 환경 구축은 해당 포스팅을 참고 해주세요.
카프카 잘 알고 사용하기 - 카프카 클러스터 구축하기(Feat. Docker, docker-compose)
개요과거 프로젝트 진행했을 때 카프카를 단일 브로커를 사용해서 구축하였다. 이는 카프카가 제공하는 고가용성의 장점을 충분히 활용하지 못한 사례로, 단일 브로커에 장애가 발생할 경우 전
ego2-1.tistory.com
실습 초기 세팅
실습을 위해 peter-test01토픽을 생성한다. 파티션 수는 1, 리플리케이션 팩터 수는 2이다.
[peter-test01 토픽 생성]
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic peter-test01 --partitions 1 --replication-factor 2
[토픽 상세보기 명령어]
kafka-topics.sh --bootstrap-server localhost:9092 --topic peter-test01 --describe
현재 peter-test01토픽의 파티션0의 리더는 3번 브로커, 팔로워는 1번 브로커임을 확인할 수 있다.
리더는 3번 브로커이므로 리더 에포크 상태를 확인하기 위해서 3번 브로커에 ssh접속을 하여 다음 명령어를 실행한다.
[리더 브로커 도커 터미널 진입 명령어]
➜ docker exec -it kafka3 /bin/bash[리더 에포크 상태 확인]
[appuser@ce599a5995fe /]$ cat /var/lib/kafka/data/peter-test01-0/leader-epoch-checkpoint
출력 결과는 숫자만 있을 뿐 무엇을 의미하는지 정확하게 이해하기 어려울 것이다. 각 숫자가 의미하는 바는 다음과 같다.
- 현재 리더 에포크 번호는 1이다.(처음 시작할 때 기본 1부터 시작), 리더 변경 시 +1씩 늘어난다.
- 그다음 0은 리더 에포크 0에서 다음으로 받을 오프셋은 0이라는 의미이다.
처음에 리더 에포크 번호가 1로 시작하는 이유?
토픽 생성시 처음 리더가 결정될 때도 리더 변경으로 간주하여 1로 설정한다. 리더 에포크 번호 0은 사실상 존재하지 않는다.
메시지 전송 후 리더 에포크 확인
메시지를 전송해서 토픽의 파티션의 상태를 변화를 준뒤 리더 에포크 내용을 다시 확인해보자.
리더 에포크 내용을 다시 확인한 결과 메시지 전송 전과 달라진 것이 없다.
왜 리더 에포크 내용이 변동 없을까?
리더 에포크는 새로운 리더 선출이 발생하면, 변경된 정보가 업데이트 된다. 즉, 리더가 변경되어야 리더 에포크 값이 +1 늘어나고, 이전 리더 에포크일 때 다음 받을 오프셋 번호를 표시할 것이다.
리더 변경 시 리더 에포크 값을 예측해보면 다음과 같이 될 것이다. 1 1은 리더 에포크가 1일 때, 다음 받을 오프셋은 1이므로 오프셋 0까지는 커밋된 상태라는 것을 의미할 것이다. 한번 확인해보자.
리더 변경 후 리더 에포크 확인
현재 리더가 브로커 3이므로 브로커 3을 임의로 중단시켜 리더를 변경하고 리더 에포크 내용을 확인해보자.
이전 리더였던 브로커3이 다운되고, 새로운 리더로 ISR그룹 내의 브로커 1이 리더로 승격되었음을 확인할 수 있다. 그리고 예측한 결과대로 리더 변경으로 리더 에포크값은 2로 변경, 리더 에포크가 1일 때, 다음 받을 오프셋은 1이므로 오프셋 0까지는 커밋된 상태를 의미하는 '1 1'값이 추가된 것을 확인할 수 있다.
'Infra' 카테고리의 다른 글
| 카프카 잘 알고 사용하기 - 카프카 클러스터 구축하기(with Docker, docker-compose) (0) | 2025.01.19 |
|---|---|
| 카프카 잘 알고 사용하기 - 카프카 내부 동작 원리(리플리케이션) (0) | 2025.01.18 |
| 카프카 잘 알고 사용하기 - 카프카 기본 개념과 구조 (0) | 2025.01.16 |