아래 영상을 보고 정리한 내용
복제(Replication)
토픽의 파티션은 같은 데이터를 가진 복제(replication)를 만든다. 고가용성 그리고 내구성을 위함이다. N개의 복제본이 있다면, (보통) N-1의 장애를 견딜 수 있다. replication factor를 통해 파티션의 복제 개수를 지정한다.
복제본은 리더와 팔로워로 구성된다. 리더는 하나이고, 프로듀서는 리더에 데이터를 생성한다. 팔로워는 리더에서 데이터를 복제한다(자세한 과정은 후술). 컨슈머도 보통 리더의 데이터를 가져가지만 팔로워를 읽도록 구성할 수 있다.
리더는 하나이고, 프로듀서는 리더에 데이터를 생성한다. 팔로워는 리더에서 데이터를 복제한다(자세한 과정은 후술). 컨슈머도 보통 리더의 데이터를 가져가지만 팔로워를 읽도록 구성할 수 있다.ISR(In-Sync Replica)
In-Sync란 가장 최신 오프셋이 있는, 리더의 데이터 상태를 뜻한다. 반대로 팔로워가 데이터를 복제하는데 시간이 걸리기 때문에 필요한 개념이다.
ISR의 팔로워는 리더로 선출될 자격이 있다. 리더 파티션이 장애이고 ISR에서 리더를 선출할 수 없다면, 리더의 재시작을 기다린다. unclean.leader.election.enable 을 통해 ISR이 아닌 팔로워가 리더로 선출되게 할 수도 있다(default false). 만약 이 옵션을 켰다면, 이전 리더에 있던 데이터는 유실될 수 있지만, 서비스가 중단되진 않는다.
예시를 통해, 복제 그리고 장애 극복 사례를 알아보자.
리더 에포크(Epoch)
리더 에포크(epoch)는 새 리더 선출 시 순증하는 번호이다. 즉 몇 번째 리더였는지 기록하고 이는 로그 reconciliation 과정에서 사용된다(broker-101이 초대 호카게 이승만이다).
팔로워 데이터 가져오기
팔로워는 리더에게 복제할 데이터를 요청하기 위해 시작 오프셋, 즉 자신의 오프셋을 전달한다. 리더는 복제할 데이터의 오프셋과 함께 리더 에포크를 보낸다.
파티션 오프셋 커밋
위에서 리더로부터 응답 받은 오프셋만큼 데이터를 팔로워에 저장한다면, 정상적인 데이터 복제, In-Sync 과정이다. 그와 동시에 팔로워는 새 오프셋(저장한 마지막 오프셋)을 시작으로하는 복제 요청을 보낸다. 이 복제 요청은 해당 오프셋까지 팔로워에 잘 저장됐음을 의미한다. ISR 수만큼의 팔로워 복제가 끝났을 때(=새 복제 요청을 받았을 때), 파티션은 해당 오프셋에 커밋한다. 커밋의 의미는 파티션을 보는 컨슈머들이 해당 오프셋까지 데이터를 읽어갈 수 있다는 뜻이다.
그와 동시에 팔로워는 새 오프셋(저장한 마지막 오프셋)을 시작으로하는 복제 요청을 보낸다. 이 복제 요청은 해당 오프셋까지 팔로워에 잘 저장됐음을 의미한다. ISR 수만큼의 팔로워 복제가 끝났을 때(=새 복제 요청을 받았을 때), 파티션은 해당 오프셋에 커밋한다. 커밋의 의미는 파티션을 보는 컨슈머들이 해당 오프셋까지 데이터를 읽어갈 수 있다는 뜻이다.
리더 장애
리더 장애 시, 새 리더가 될 수 있는 ISR에서 리더를 선출한다. 선출된 리더는 컨트롤 플레인이 나머지 팔로워에게 알린다. 여기서 2대 호카게새 리더는 broker-103이 됐다.
새 리더, broker-103은:
•
ISR이다. 파티션이 커밋한 오프셋 3까지의 데이터가 있다.
•
다른 ISR 팔로워(broker-102)보다 최신 오프셋이 더 낮다(5 > 3). 이는 리더 선출에 영향을 주지 않는다.
새 리더에 데이터가 쌓이고 에포크 번호는 증가한 2로 기록된다.
이런 상황에선 새 리더의 하이 워터마크가 “실제” 것보다 작다(0 < 3). 컨슈머가 이 사이(0 ~ 3) 데이터를 읽으려하면 OFFSET_NOT_AVAILABLE 오류가 발생한다. 이는 하이 워터마크를 갱신하는 동안 재시도 가능하다(retriable).
복제본 복구(reconcil)
복제본을 복구하기 위해 팔로워는 새 리더에게 데이터를 요청을 한다. 요청할 때 자신의 오프셋과 마지막으로 가져간 에포크 번호(1)을 보낸다.
이처럼 하이 워터마크보다 더 큰 오프셋으로 요청이오면, 하이 워터마크와 유효한(=남겨두어도 되는) 데이터의 정보(divergingEpoch)를 응답한다. 팔로워는 나머지 데이터를 삭제한다.
복제할 준비가 된 broker-102는 다시 복제 요청을 보낸다.
broker-101(1대 리더였던 것)이 복구된다면, 팔로워로서, broker-102과 같은 과정으로 복구(reconcil)될 수 있다
replica.lag.time.max.ms
리더에 비해 구성 값을 초과하여 랙이 있는 팔로워는 ISR에서 제외된다. 이는 하이 워터마크를 증가시켜 컨슈머가 계속 처리할 수 있게 한다.
파티션 리더 분배
리더는 팔로워에 비해 하는 일이 많고 중요하기 때문에 카프카는 클러스터에서 리더를 브로커에 고르게 분배하려고 한다. 이를 위한 “선호(preferred)” 복제본이라는 개념이 있다:
•
첫번째 복제본(-0)을 리더로서 선호한다.
•
리더를 브로커마다 고르게 분배한다.
•
(앞서 살펴본 장애 등의 이유로) 리더 분배가 고르지 않다면, 카프카는 선호 복제본이 ISR에 있을 때 다시 시 리더로 선출하여 고르게 분배되도록 한다.
습득 교훈
•
파티션 데이터는 고가용성, 내구성을 위해 복제된다.
•
ISR
◦
리더를 포함해 같은 데이터 상태를 저장하고 있는 팔로워 목록
◦
리더 장애 시 이 중에서 새 리더가 선출된다
•
리더 에포크(epoch)는 리더가 바뀔 때마다 순증하는 기록 번호이다.
•
하이 워터마크는 파티션이 커밋한 오프셋이다.
◦
컨슈머가 읽어서 사용할 수 있는 지점이다.
◦
이를 활용해 리더 장애 시 팔로워 조정(reconcil) 작업을 한다.
•
카프카는 첫번째 복제본을 리더로 선호하여 브로커 전체에 고르게 분배되도록 한다.