3. 클러스터

복제는 “몇 부를 두는가”가 아니라 “몇 부가 따라와야 성공으로 치는가”까지 정해야 완성된다

이 장에서 처음 나오는 말5개

복제 계수Replication Factor (RF)

파티션 하나를 몇 부 두는가. RF=3이면 같은 파티션이 브로커 세 대에 있다.

리더 / 팔로워Leader / Follower

파티션 복제본 중 읽기·쓰기를 받는 한 부가 리더, 리더를 따라 복사하는 나머지가 팔로워다.

ISRIn-Sync Replicas

리더를 "충분히 따라잡고 있는" 복제본의 명단. 유실 없는 장애 극복(failover)의 근거가 되는 집합이다.

컨트롤러Controller

"어느 브로커가 어느 파티션의 리더인가" 같은 클러스터 메타데이터를 관리하고 리더 선출을 하는 역할.

KRaftKafka Raft

컨트롤러들이 Raft 합의로 메타데이터를 관리하는 방식. 별도 ZooKeeper 클러스터를 없앤 현재의 표준 구조다.

브로커 — 파티션이 흩어지는 곳

브로커는 Kafka 서버 프로세스 하나다. 토픽의 파티션들은 여러 브로커에 흩어져, 토픽 하나의 용량과 처리량이 브로커 한 대에 묶이지 않는다.

문제는 브로커가 죽을 때다 — 그 브로커에만 있던 파티션은 통째로 사라진다. 그래서 복제가 필요하다.

복제 — 리더와 팔로워

파티션마다 복제본을 RF부 둔다. 그중 리더 한 부만 프로듀서·컨슈머를 상대하고, 팔로워들은 리더에서 데이터를 당겨 와 복사한다.

• 리더가 죽으면 팔로워 중 하나가 새 리더로 선출된다 — 클라이언트는 잠깐의 재시도 후 새 리더로 붙는다. 이 짧은 전환이 Kafka의 고가용성이다
• 리더 역할은 파티션 단위라, 브로커들이 서로 다른 파티션의 리더를 나눠 맡는다 — 부하가 자연히 분산된다
• 프로덕션 기본값은 RF=3이다. RF=2는 한 대 장애 중 남은 한 대가 단일 장애점이 되고, RF=1은 브로커 장애 = 데이터 유실이다

ISR — “따라온 복제본”의 명단

복제가 있어도 질문이 남는다 — 팔로워가 미처 복사하기 전에 리더가 죽으면? 그 답을 주는 장치가 ISR이다.

• 리더는 “충분히 따라잡고 있는” 복제본 명단(ISR)을 유지한다. 뒤처진 팔로워는 명단에서 빠지고, 따라잡으면 다시 들어온다
• 리더 선출은 ISR 안에서만 한다 — 명단에 있는 복제본은 커밋된 데이터를 다 갖고 있으므로, 유실 없이 리더를 넘길 수 있다
• ISR 밖 복제본을 리더로 뽑는 것(unclean leader election)은 유실을 감수하는 선택이라 기본값으로 꺼져 있다

여기에 나사가 둘 더 있다. 셋이 한 세트다 —

나사	누가 조이나	의미
replication.factor=3	토픽 설정	세 부를 둔다
min.insync.replicas=2	토픽/브로커 설정	최소 두 부가 살아 있어야 쓰기를 받는다
acks=all	프로듀서 설정	ISR 전원이 받았을 때만 성공으로 친다 (4장)

핵심 — 표준 조합

RF=3 + min.insync.replicas=2 + acks=all — “브로커 한 대가 죽어도 유실 없이, 두 대가 죽으면 유실 대신 쓰기 거부”라는 태도의 설정이다. 유실이 아까운 토픽은 이 조합을 기본값으로 두고 시작한다. 어느 하나만 빠져도 구멍이 난다 — acks=all이어도 min.insync.replicas=1이면 리더 혼자 받고 성공을 돌려줄 수 있다.

함정

min.insync.replicas=2에서 브로커가 죽어 ISR이 1로 줄면, 그 파티션은 쓰기를 거부한다 (NotEnoughReplicas 오류). 유실을 막으려고 가용성을 내준 것 — 의도된 동작이지만, 처음 겪으면 장애로 보인다. 11장에서 다시 만난다.

컨트롤러와 KRaft — 클러스터의 머리

“파티션 0의 리더는 브로커 1”이라는 메타데이터 자체는 누가 관리하는가 — 컨트롤러다. 브로커 생사를 감시하고, 죽으면 새 리더를 선출해 전파한다.

• 예전 (~3.x): 이 일을 별도 시스템 ZooKeeper에 맡겼다 — Kafka를 쓰려면 ZooKeeper 클러스터를 하나 더 운영해야 했다
• 지금 (4.0~): 컨트롤러 노드들이 Raft 합의로 메타데이터를 직접 관리한다(KRaft). ZooKeeper는 코드에서 제거됐다. 운영 대상이 하나로 줄었고, 파티션이 아주 많은 클러스터의 장애 복구도 빨라졌다

노드는 역할을 갖는다 —

역할	하는 일	언제
broker	데이터 저장·서빙	프로덕션 기본
controller	메타데이터·리더 선출 (보통 3대)	프로덕션 기본 — broker와 분리
combined (겸임)	둘 다	개발·소규모. 데이터 부하가 합의 지연을 만들 수 있어 프로덕션 비권장

Strimzi에서는 이 역할 배치를 KafkaNodePool로 선언한다 (9장).

3장 요약

• 파티션은 브로커들에 흩어지고, 복제(RF=3)로 브로커 장애를 견딘다 — 읽기·쓰기는 리더로만
• ISR은 “따라온 복제본” 명단 — 명단 안에서만 리더를 뽑기에 장애 극복이 유실 없이 된다
• 표준 조합: RF=3 + min.insync.replicas=2 + acks=all. 하나만 빠져도 구멍
• 메타데이터는 KRaft 컨트롤러(보통 3대)가 관리 — ZooKeeper는 이제 없다

4. 프로듀서쓰는 쪽의 선택 — acks · 멱등성 · 키, 그리고 배치.