CHAPTER6. 카프카 내부 매커니즘

카프카 완벽 가이드 6장 요약: 카프카 내부 매커니즘

---

6.1 클러스터 멤버십

• 카프카는 브로커의 목록을 유지하기 위해 Apache Zookeeper를 사용.
• Zookeeper는 브로커가 클러스터에 속해 있는지 확인하고 리더 선출 등 여러 작업을 수행.

---

6.2 컨트롤러

• 컨트롤러 역할:

  • 파티션 리더 선출 및 메타데이터 관리.
  • 브로커가 추가되거나 제거될 때 파티션의 리더를 선출하고 클라이언트 요청 처리 시작.

• KRaft (Kafka Raft):

  • Zookeeper 의존 제거: 자체적으로 리더 선출 및 메타데이터 관리.
  • 액티브 컨트롤러가 브로커 요청 처리, 팔로워 컨트롤러는 데이터 복제.
  • 메타데이터 동기화 및 성능 병목 해결.

---

6.3 복제 (Replication)

• 리더 레플리카:

  • 파티션의 리더 역할을 수행하며 쓰기 요청 처리.
  • 클라이언트 요청은 기본적으로 리더 레플리카를 통해 처리.

• 팔로워 레플리카:

  • 리더로부터 메시지를 복제해 최신 상태 유지.
  • 리더 장애 시 팔로워가 새로운 리더로 승격.

• 선호 리더 (Preferred Leader):

  • 파티션 생성 시 리더로 설정된 레플리카.
  • auto.leader.rebalance.enable=true 설정으로 부하 균등화를 위해 선호 리더로 복귀 가능.

---

6.4 요청 처리

• 요청 흐름:

  • 클라이언트 요청은 브로커의 Acceptor 스레드로 전달 → Processor 스레드에서 처리.
  • 요청 유형과 상관없이 TCP 기반의 이진 프로토콜로 전달.

• 쓰기 요청:

  • 리더 레플리카에 쓰기 요청 전달 → 유효성 검증 → 파일시스템 캐시에 메시지 기록.
  • acks=all 설정 시, 모든 인-싱크 레플리카에 반영 후 응답.

• 읽기 요청:

  • 클라이언트가 요청한 파티션과 오프셋에 해당하는 메시지를 반환.

---

6.5 물리적 저장소

6.5.1 계층화된 저장소

• 문제:
  • 디스크 크기에 따라 데이터 보존 기한 제한.
  • 저장소 요구 조건이 클러스터 크기와 비용에 영향.
• 해결:
  • 계층화된 저장소: 로컬 디스크와 원격 저장소(S3, HDFS 등) 분리.
  • 무한 저장 공간, 비용 절감, 클러스터 탄력성 강화.

6.5.2 파티션 할당

• 레플리카는 브로커 간 균등하게 분배.
• 파티션 레플리카는 다른 브로커와 다른 랙에 할당하여 장애 복구 대비.

6.5.3 파일 관리

• 데이터 저장:
  • 파티션은 세그먼트 파일로 저장.
  • 오래된 데이터는 log.retention.hours 및 log.retention.bytes 설정에 따라 삭제.

6.5.4 파일 형식

• 메시지: 사용자 페이로드와 시스템 헤더로 구성.
• DumpLogSegment 도구로 세그먼트 파일 내용 확인 가능.

6.5.5 인덱스

• 오프셋 인덱스: 메시지 오프셋으로 메시지 탐색.
• 타임스탬프 인덱스: 타임스탬프 기반 메시지 검색 지원.

6.5.6 압착 (Compaction)

• 압착 보존 정책:
  • 각 키의 최신값만 저장.
  • 키값이 null이면 압착 실패.
• 압착의 작동원리:
  • 백그라운드에서 실행되며, 오래된 메시지 제거 후 최신 상태 유지.

---

6.6 요약

• 카프카는 컨트롤러, 복제 메커니즘, 요청 처리 방식, 물리적 저장소 구조를 통해 고성능과 확장성을 제공.
• KRaft를 통해 Zookeeper 의존도를 제거하며, 더 단순하고 효율적인 아키텍처로 전환 중.
• 효율적인 데이터 관리와 저장을 위해 계층화된 저장소, 압착 정책, 인덱싱 등을 활용.