실전 카프카 개발부터 운영까지 (4) - 카프카의 내부 동작 원리와 구현

4.1.1 리플리케이션 동작 개요

• 토픽 생성시 replication factor 옵션으로 리플리케이션 수를 조정
• 토픽을 구성하고 있는 파티션이 리플리케이션 된다.

 

4.1.2 리더와 팔로워

• 리더: 모든 읽기와 쓰기는 리더를 통해서만 가능
• 팔로워: 새로운 리더가 될 준비를 하고 있으며 리더로 부터 새로운 메시지를 복제함

 

4.1.3 복제 유지와 커밋

• 리더와 팔로워는 ISR(InSyncReplica)라는 논리적 그룹으로 묶여 있음
  • 리더는 ISR내 팔로워가 메시지를 모두 받을 때까지 대기
  • 팔로워가 메시지를 수신하면서 장애가 났는지 지속적으로 감시
  • 리더가 팔로워 리플리케이션 동작에 문제가 있다고 판단하면 추방함
• 커밋 오프셋은 replication-offset-checkpoint라는 파일에 저장

 

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

1. 리더가 메시지를 저장함
2. 팔로워들이 리더에게 오프셋 메시지 가져오기(fetch) 요청을 통해 새로운 메시지가 있는지 파악
3. 다음 메시지를 리더가 받고 저장함
4. 팔로워들이 다음 오프셋 메시지 가져오기 요청을 수행
5. 리더는 기존 메시지 레플리케이션 동작이 성공했음을 인지하고 기존 오프셋에 대해 커밋 표시를 수행함
6. 반복

⇒ ACK 동작을 제거함으로써 리플리케이션 동작의 성능을 확보

 

4.1.5 리더에포크와 복구

• 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 이용
• 리더 에포크를 사용하면 장애로 인해 브로커가 다운되어 팔로워가 브로커로 승격될 때, 하이워터마크를 올릴 수 있기 때문에 메시지가 유실되지 않음

 

4.2 컨트롤러

• 브로커 중 하나가 담당하게 되며 리더를 선출하고 관련 ISR 내용을 주키퍼에 기록함
• 제어된 종료 설정을 적용하여 장애시 브로커 복구를 빠르게 할 수 있음
  • controlled.shutdown.enable = true

 

4.3 로그(로그 세그먼트)

• 카프카의 메시지는 세그먼트라는 파일에 저장
• 로그 세그먼트의 최대 크기는 1GB가 기본값으로 설정

 

4.3.1 로그 세그먼트 삭제

• log.cleanup.policy가 delete로 명시되어 있다면 세그먼트를 삭제함
• 기본값은 5분 주기로 세그먼트 파일을 삭제

 

4.3.2 로그 세그먼트 컴팩션

• 로그를 삭제하지 않고 보관하는 옵션
• 메시지의 키값을 기준으로 마지막의 데이터만 보관
• 장애시 최신 키를 기준으로 복구하기 때문에 빠른 장애복구가 가능
  • 최종값만 필요한 워크로드에 적용하면 좋다.