4장 카프카의 내부 동작 원리와 구현

4.4 정리

• 카프카에서 메세지의 신뢰성을 보장하는데 중요한 리플리케이션의 개념
• 리플리케이션 동작을 위한 리더와 팔로워의 구분 및 역할 그리고 장애 복구를 위한 동작들
• 카프카 클러스터 내에서 리더 선출 작업을 책임지고 있는 컨트롤러

 

4.1 카프카 리플리케이션

카프카는 초기 설계 단계에서부터 일시적인 하드웨어 이슈 등으로 브로커 한두 대에서 장애가 발생하더라도 중앙 데이터 허브로서 안정적인 서비스가 운영될 수 있도록 구상됐습니다. 이때 안정성을 확보하기 위해 카프카 내부에서는 리플리케이션이라는 동작을 하게 됩니다.

 

4.1.1 리플리케이션 동작 개요

• 카프카의 리플리케이션 동작을 위해 토픽 생성시, 필수값으로 replication factor라는 옵션을 설정해야 합니다.

kafka-topics.sh
--bootstrap-server peter-kafka01.foo.bar:9092
--create --topic peter-test01
--partitions 1
--replication-factor 3

 # 2장에서 설치한 브로커 서버 中 한 대로 접근

   → peter-kafka01에 접속
   → kafka-topics.sh : 토픽생성 명령어(카프카 기본도구)

   → 파티션 1개 / 리플랙션팩터 3개

• 파티션0의 리더 = 브로커1
• 동기화되고 있는 리플리케이션들 = 브로커 1,2,3 → peter-kafka01,02,03
• 프로듀서 통해서 메시지를 리더(peter-kafka01)통하여 보내고 나면,
  나머지 브로커(peter-kafka02,03)에서 확인시 동일 메시지 갖고 있음.
• 리플리케이션되는 것은 토픽이 아니라 토픽을 구성하는 각각의 파티션들

파티션 2개 / 리플랙션팩터 3개

---

참고 :

• https://towardsdatascience.com/the-thing-about-apache-kafka-internals-5ae69c17985f
• https://velog.io/@jwpark06/Kafka-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%A1%B0-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

4) Replication Factor

• 파티션의 복제 계수(replication factor)가 1인 경우 (= 복제 없음)
  복제 계수가 0이므로
  브로커 A의 파티션의 데이터를 복제해서 가지고 있을 브로커 B의 파티션이 없습니다.
  즉, 브로커 A에 리더 파티션만 존재하게 됩니다.
  브로커 A의 해당 토픽의 파티션이 총 3개였다면, 3개 모두 리더 파티션이 되는 것입니다
• 파티션의 복제 계수(replication factor)가 3인 경우 (= 복제 2개)
  복제 계수가 3이므로브로커 A의 파티션의 데이터를 복제해서 가지고 있을 브로커 B, C의 파티션이 존재합니다.이때, 브로커 A의 파티션이 3개였다면 A와 B, C는 각각 하나씩의 리더 파티션과 두개씩의 팔로워 파티션을 가지고 있게 됩니다.

---

4.1.2 리더와 팔로워

• 리더 : 리플리케이션 중 하나가 선정되며, 모든 읽기와 쓰기는 그 리더를 통해서만 가능함
• 프로듀서 : 리더에게만 메시지를 전송 / 컨슈머: 오직 리더로부터 메시지를 가져옴
• 팔로워 : 리더에 문제가 발생하거나 이슈가 있을 경우를 대비해 언제든지 새로운 리더가 될 준비를 함
• 팔로워의 역할 : 파티션의 리더가 새로운 메시지를 받았는지 확인 & 새로운 메시지가 있다면 해당 메시지를 리더로부터 복제

 

4.1.3 복제 유지와 커밋

• ISR그룹에 속하지 못한 팔로워는 새로운 리더의 자격을 가질 수 없음
• ISP내의 팔로워들은 리더와의 데이터 일치를 유지하기 위해 지속적으로 리더의 데이터를 따라가게 되고
• 리더는 ISR 내 모든 팔로워가 메시지를 받을 때까지 기다림 / 팔로워들이 뒤처지지 않고 리플리케이션 동작을 잘하고 있는지 감시
• 리더에 뒤처지지 않고 잘 따라잡고 있는 팔로워들만이 ISR 그룹에 속함
• 판단방법? 팔로워가 특정 주기의 시간만큼 복제 요청을 하지 않는다면, 리더는 해당 팔로워가 리플리케이션 동작에 문제가 발생했다고 판단해 ISR 그룹에서 추방 및 리더가 될 자격 박탈
• 커밋 : ISR내의 모든 팔로워의 복제가 완료되면 리더가 내부적으로 커밋 = 리플리케이션 팩터 수의 모든 리플리케이션이 전부 메시지를 저장했음을 의미
• 하이워터마크 : 마지막 커밋 오프셋 위치
• 커밋되지 않은 메시지는 컨슈머가 읽을 수 없음 = 메시지의 일관성 유지
• 커밋된 메시지를 유지하기 위해 로컬 디스크의 replication-offset-checkpoint 파일에 마지막 커밋 오프셋 위치 저장
• 참고 : https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-topic-replication/

 

4.1.4 리더와 팔로워의 단계별 리플리케이션 동작

참고: https://hoing.io/archives/57262

1. 프로듀서가 리더에게 message1이라는 메시지 전송
2. 팔로워들은 리더에게 0번 오프셋 메시지 가져오기(fetch)요청을 보낸 후
   새로운 메시지 message1이 있다는 사실을 인지하고
   message1메시지를 리플리케이션 함
   → 현 상황에서는
   리더는 모든 팔로워가 0번 오프셋 미시지를 리플리케이션하기 위한 요청을 보냈다는 사실을 알고 있지만,
   리더는 팔오워들이 0번 오프셋에 대한 리플리케이션 동작을 성공했는지 실패했는지 여부를 알지 못함
   ※래빗MQ의 트랜잭션모드에서는 모든 미러(팔로워)가 메시지를 받았는지에 대한 ack를 리더에게 리턴하므로, 리더는 미러들이 메시지를 받았는지 알 수 있음
   BUT, 카프카는 ACK 통신이 없음
3. 리더는 1번 오프셋의 위치에 두번째 새로운 메시지인 message2를 프로듀서로부터 받은 뒤 저장함
   
   1. 0번 오프셋에 대한 리플리케이션 동작을 성공한 팔로워들은
      리더에게 1번 오프셋에 대한 리플리케이션을 요청함
      리더는 1번 오프셋에 대한 리플리케이션 요청을 받았으므로, 팔로워들의 0번 오프셋에 대한 리플리케이션 동작이 성공했음을 인지→ 오프셋0에 대한 커밋 표시→ 하이워터마크 증가
   2. 0번 오프셋에 대한 리플리케이션을 성공하지 못한 팔로워는
      리더에게 0번 오프셋을 요청하므로 리더가 팔로워들이 어느 위치까지 리플리케이션을 성공헀는지 인기 가능
4. 리더는 1번 로프셋 메시지에 대한 리플리케이션 요청에 0번 오프셋 message1메시지가 커밋되었다는 내용도 함께 전달
   → 팔로워는 0번 오프셋 메시지가 커밋되었다는 사실 인지하고 동일하게 커밋표시 및 1번 오프셋 메시지 message2 리플리케이션
5. ~~반복~~

리더가 PUSH하는 방식이 아니라 팔로워들이 PULL하는 방식으로 동작
→ 리더의 부하를 줄여줌

 

4.1.5 리더에포크와 복구

• 리더에포크는 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 이용
• 리더에포크는 컨트롤러에 의해 관리되는 32비트의 숫자로 표현
• 리더에포크 정보는 리플리케이션 프로토콜에 의해 전파되고, 새로운 리더가 변경된 후 변경된 리더에 대한 정보는 팔로워에 전달
• 리더에포크는 복구 동작 시 하이워터마크를 대체하는 수단
• 리더에포크 번호는 리더가 변경될 때마다 하나씩 숫자가 증가함
• 팔로워는 자신의 하이워터마크보다 높은 오프셋의 메시지를 무조건 삭제하지 않고,
  리더에게 리더에포크 요청을 보내 응답을 받아서  최종 커밋 후 새로운 메시지를 전송받게 될 오프셋 번호를 확인
• 리더에포크 사용 전/후 : https://hoing.io/archives/57262

 

4.2 컨트롤러

• 리더 선출 과정은 컨트롤러에 의해 이루어짐
• 카프카 클러스터 中 하나의 브로커가 컨트롤러 역할을 함
• 리더를 선출하기 위한 ISR 리스트 정보는 안전한 저장소에 보관되어 있어야 하는데, 가용성 보장을 위해 주키퍼에 저장되어 있음
• 컨트롤러는 브로커가 실패하는 것을 예의주시하고 있음
• 만약 브로커의 실패가 감지되면 즉시 ISR 리스트 中 하나를 새로운 파티션 리더로 선출
• 새로운 리더의 정보는 주키퍼에 기록하고 변경된 정보를 모든 브로커에 전달함
• 리더 선출 작업 파티션당 약 0.2초 → 1만개의 파티션애 대한 리더 선출은 30분으로 1.1.0부터는 리더 선출 작업 속도 개선
• 제어된 브로커 종료란? 예기치 않은 브로커의 실패나 장애가 아니라 관리자에 의해 이뤄지는 자연스러운 종료 또는 안전한 종료

4.3 로그(로그 세그먼트)

• 카프카의 토픽으로 들어오는 메시지는 세그먼트라는 파일에 저장됨
• 내용뿐아니라 메시지의 키, 밸류, 오프셋, 메시지 크기 저장
• 브로커의 로컬 디스크에 보관
• 1GB보다 커지는 경우에 기본적으로 롤링전략 적용