[카프카 핵심 가이드] ch 01, 02

Ch 01. 카프카 시작하기

 

p. 7

주어진 파티션의 각 메시지는 고유한 오프셋을 가지며, 뒤에 오는 메시지가 앞의 메시지보다 더 큰 오프셋을 가진다(반드시 단조증가할 필요는 없다).

 

Q. 카프카의 오프셋은 각 파티션 내에서 반드시 단조 증가해야 하지 않나?

 

A. 카프카에서 각 파티션에 기록되는 메시지는 순차적인 오프셋을 가진다.

즉, offset n 다음엔 반드시 offset n+1 이 온다

 

그리고 브로커는 메시지 손실 여부를 오프셋의 단절로 인식한다.

따라서 컨슈머 입장에서 만약 오프셋이 100, 101, 102, 104 순으로 온다면 103은 유실 혹은 아직 도착하지 않은 상태로 간주될 수 있다

단조 증가가 깨지면 손실 또는 중복 발생으로 판단할 수 밖에 없다

 

Q. 그렇다면 왜 책에는 저렇게 쓰여 있을까?

 

A. 다음과 같은 케이스이지 않을까 추측해볼 수 있다.

Log Compaction이 활성화된 토픽에서는 동일 키의 오래된 레코드가 삭제될 수 있다.
다만 여기에 대해서도 오프셋 자체는 사라지지 않으며, 빈 슬롯으로 존재하거나 skip 된다

 

 

p. 8

하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있으며, 그중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게 된다(컨트롤러는 클러스터 안의 현재 작동 중인 브로커 중 하나가 자동으로 선정된다).

 

Q. 컨트롤러의 역할을 하는 브로커는 파티션 리더/팔로워로서의 역할을 수행하는가?

 

A. 컨트롤러가 된 브로커도 여전히 파티션 리더/팔로워로서 메시지 저장 및 전달 역할을 정상적으로 수행한다.

 

컨트롤러의 역할 요약

• 파티션 리더 선출 : Leader election 수행
• 메타데이터 관리 : 토픽 파티션, 브로커 상태를 Zookeeper (또는 KRaft)에 반영
• 브로커 장애 감지 : 다른 브로커의 heartbeat 감시
• 토픽/파티션 변경 관리 : 새 토픽 생성, 파티션 수 변경 등의 요청 처리
• ISR(복제 대기열) 관리 : in-sync replica 리스트 유지/관리

 

Q. 그렇다면 실무적으로 컨트롤러는 부하 이슈가 없을까?

 

A. 컨트롤러는 메타데이터 관리를 담당하기 때문에 다음과 같은 단점이 있을 수 있다

• 리더 선출 등 중요한 이벤트가 몰릴 경우 CPU 사용률이 높아질 수 있다
• 많은 토픽/파티션 수를 가진 대형 클러스터에서는 컨트롤러 역할이 병목 포인트가 될 수 있다

따라서 Kafka 2.8 이후에는 컨트롤러를 별도 클러스터(KRaft mode)로 분리 운영하는 것도 지원한다

 

 

p. 9

아파치 카프카의 핵심 기능 중에 일정 기간 동안 메시지를 지속성 있게 보관하는 보존 기능이 있다.

 

Q. 하둡으로 영구 보관할 필요성이 있을까?

 

A. Kafka만으로는 "영구 보관"과 "감사 목적의 이력 관리"에 한계가 있기 때문에, 실무에서는 Hadoop(HDFS), S3, 혹은 Data Warehouse 등으로 Kafka 메시지를 이관하여 저장하는 패턴이 흔히 사용된다

 

 

 

Ch 02. 카프카 설치하기

 

p. 23

peerPort : 앙상블 안의 서버들이 서로 통신할 때 사용하는 TCP 포트 번호
leaderPort : 리더를 선출하는 데 사용되는 TCP 포트 번호

 

Q. 포트를 구분하는 이유는 무엇인가?

 

A. 이유는 아래와 같다

1. 책임이 다른 두 종류의 통신을 분리하기 위해
   Zookeeper는 리더 선출을 비동기적으로, 주기적으로 반복할 수 있으며, 이와 동시에 리더-팔로워 간 데이터 sync도 진행되므로 명확한 포트 분리가 필요하다
2. 통신 안정성과 보안을 위해
   서로 다른 포트를 사용하면:
   
   • 방화벽, ACL, NAT, 보안 정책 적용이 더 유연
   • Election 관련 트래픽과 데이터 트래픽을 독립적으로 모니터링 가능
   • 포트 충돌, 병목 등을 줄일 수 있다
3. 확장성을 고려한 설계
   Zookeeper는 기본적으로 분산 시스템에서 최소 3노드 이상 구성되며, 서버 수가 많아질수록 내부 통신 복잡도도 증가한다

 

p. 28

auto.leader.rebalance.enable
이 설정을 활성화해주면 가능한 한 리더 역할이 균등하게 분산되도록 함으로써 이러한 사태가 발생하는 것을 방지할 수 있다.

 

Q. 리더의 역할을 어떤 단위로 분산하는가?

 

A. 이 설정은 Kafka 브로커 간 리더 파티션의 부하를 자동으로 분산시켜, 특정 브로커에 리더 파티션이 과도하게 몰리는 현상을 방지하는 역할을 한다.

단순히 리더를 골고루 나누는 것처럼 들릴 수 있지만, 실제로는 정책 기반 리더 재할당 작업이 주기적으로 수행된다.

 

이 설정을 true로 하면, Kafka Controller가 주기적으로 리더 분포 상태를 점검하고, 특정 브로커에 리더가 과도하게 몰렸으면 일부 파티션의 리더를 다른 브로커로 이동시킨다.

 

Q. 실무에서의 영향도는?

 

A. 리더-팔로워 간 리더 리밸런싱은 일반적으로 문제가 거의 없다

(partition reassignment 와 consumer rebalance에 비해 영향 범위가 현저히 낮다)

 

Kafka의 컨트롤러가 ISR 내에서 리더를 교체하는 것이고, 클러스터 안정성과 부하 분산에 오히려 긍정적이다

• 파티션 이동 없음
• 리플리카 재배치 없음
• 토픽 재설정 없음

 

다만, 리더 전환 중에는 short-lived consumer rebalance 발생 가능하며, 네트워크 영역 간 리더가 바뀌면 latency가 급증할 수 있다.