Kafka 마스터 — Cluster·고가용성·Best Practices

2026-05-03•확률과 통계 마스터 노트

카프카 마스터 노트 시리즈 6편. Kafka 클러스터의 리더/팔로워 구조, ISR(In-Sync Replicas)이 데이터 신뢰성을 보장하는 메커니즘, 복제·장애 복구 흐름, min.insync.replicas로 쓰기 거부 방어, Unclean Leader Election의 위험, 운영 환경 Best Practices(파티션·복제·acks·압축·배치·모니터링)까지 — 운영 환경의 핵심 결정.

이 글은 카프카 마스터 노트 시리즈의 여섯 번째 편입니다. 1~5편이 단일 노드 관점이었다면, 이번엔 여러 브로커가 협력하는 클러스터 — 고가용성과 운영 모범 사례.

ISR을 모르면 Kafka 신뢰성을 이해 못 합니다. min.insync.replicas 한 줄이 데이터 무결성을 보장. 운영 환경 결정 한두 개가 사고를 가르는 자리예요.

처음 클러스터·HA가 어렵게 느껴지는 이유

처음 이 단원이 어렵게 느껴지는 이유는 두 가지예요. 첫째, Leader·Follower·ISR·Replicas가 한 번에 등장합니다. 누가 누구의 부분집합인지 안 보입니다. 둘째, 장애 복구 흐름이 막연합니다. 한 브로커 다운 시 누가 결정하고 누가 새 리더가 되나?

해결법은 한 가지예요. "공장 라인 리더와 보조원" 비유로 묶는 것. Leader = 라인 리더(주 작업자), Follower = 보조원, ISR = 라인 리더 페이스 따라잡는 보조원들, Replicas = 라인 전체 인원. 리더가 다치면 ISR 안에서 새 리더 선출.

Kafka Cluster 큰 그림

[Broker 1]   [Broker 2]   [Broker 3]
   ├───────────┼───────────┤
   └─── 같은 클러스터 ────┘

각 토픽의 각 파티션 → 여러 브로커에 복제

목적:

고가용성 — 브로커 다운에도 서비스 유지
수평 확장 — 브로커 추가로 처리량 ↑
데이터 안전 — 복제로 손실 방어

Leader / Follower / Replicas

각 파티션은:

파티션 0 (replication.factor=3):
  Leader   (Broker 1) ← 클라이언트가 읽고 쓰는 곳
  Follower (Broker 2) ← Leader 데이터 복제
  Follower (Broker 3) ← Leader 데이터 복제

Replicas = [Broker 1, 2, 3]   (모든 복제본)

특성:

Leader가 모든 읽기·쓰기 처리
Follower는 백업 (실시간 복제만)
Leader 다운 시 Follower 중 하나가 새 Leader

여기서 정말 중요한 시험 함정 — Kafka는 Read도 Leader에서만. 다른 일부 분산 시스템(Cassandra)은 read 분산이지만, Kafka는 Leader 집중. 이래서 Read Replica 개념이 다른 시스템과 다름.

ISR — In-Sync Replicas

Leader 페이스를 따라잡는 Follower들.

Replicas = {1, 2, 3}
ISR = {1, 2}    (3은 뒤처짐)

ISR 조건:

Leader가 수신한 메시지를 일정 시간 안에 복제
replica.lag.time.max.ms (기본 30초) 안에 따라잡기

뒤처지면 ISR에서 제거. 다시 따라잡으면 복귀.

여기서 정말 중요한 시험 함정 — ISR이 데이터 신뢰성의 단위. acks=all은 "모든 ISR 응답"이지 "모든 Replicas 응답" 아님. ISR이 1로 줄면 안전성 떨어짐.

min.insync.replicas — 쓰기 안전선

acks=all
min.insync.replicas=2
replication.factor=3

ISR이 2 미만이면 쓰기 거부 (NotEnoughReplicasException). 데이터 무결성 보장.

정상: ISR={1,2,3}, 쓰기 OK
1대 다운: ISR={2,3}, 쓰기 OK
2대 다운: ISR={3}, 쓰기 거부 → 클라이언트가 에러 받음

여기서 시험 함정이 하나 있어요. min.insync.replicas는 토픽 단위로도 설정. 중요 토픽은 2, 일반은 1로 차등화.

장애 복구 흐름

Leader 다운

1. Leader 1번 다운
2. Controller가 감지
3. ISR 중 새 Leader 선출 (보통 첫 ISR)
4. 클라이언트들 메타데이터 갱신
5. 새 Leader에 read/write

수 초 내 자동 복구. 클라이언트는 잠시 재시도 후 성공.

Follower 다운

Leader 영향 X. 다만 ISR에서 제거 → min.insync.replicas 위협.

여기서 정말 중요한 시험 함정 — Follower 다운도 모니터링 필수. ISR 줄어들면 다음 Leader 다운 시 위험. 알람 설정.

Unclean Leader Election — 위험한 옵션

ISR이 모두 다운되면?

unclean.leader.election.enable=false  (기본, 권장)
  → 새 Leader 선출 X, 쓰기 멈춤 (안전)

unclean.leader.election.enable=true
  → ISR 아닌 Replica를 Leader로 (데이터 손실 가능!)

여기서 정말 중요한 시험 함정 — 운영 표준 = false. true 시 ISR이 아닌 (뒤처진) Replica가 Leader 되어 앞선 데이터 손실. 가용성 vs 일관성 트레이드오프.

Replication Factor 결정

RF = 1   → 복제 X (테스트만, 운영 절대 X)
RF = 2   → 1대 다운까지 (위태)
RF = 3   → 2대 다운까지 (운영 표준)
RF = 5+  → 더 안전, 비용 ↑

min.insync.replicas 가이드:

RF = 3 → min.insync.replicas = 2 (운영 표준)
RF = 5 → min.insync.replicas = 3

Controller — KRaft 클러스터 관리자

KRaft 모드에서 Controller 노드들이 클러스터 관리:

브로커 5대 중 3대가 Controller (정족수 합의)

역할:

메타데이터 관리 (토픽·파티션·ISR)
Leader 선출
브로커 상태 추적

정족수 = 과반 합의. 3 Controller면 2대까지 살아 있어야 결정 가능.

Best Practices — 운영 환경 체크리스트

Producer

acks=all
enable.idempotence=true   # Kafka 3.0+ 기본
compression.type=lz4
batch.size=16384
linger.ms=10
max.in.flight.requests.per.connection=5

Consumer

auto.offset.reset=earliest  # 환경에 따라
enable.auto.commit=false    # 수동 commit
isolation.level=read_committed  # 트랜잭션 사용 시
session.timeout.ms=45000
max.poll.records=500
partition.assignment.strategy=CooperativeStickyAssignor

Broker / Topic

replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false
log.retention.hours=168     # 7일
default.replication.factor=3
auto.create.topics.enable=false   # 명시적 토픽 생성 권장

모니터링 핵심 메트릭

메트릭	의미
Consumer Lag	처리 지연
ISR shrink	ISR 축소 = 위험 신호
Under-replicated partitions	복제 미완료
Request rate / latency	처리량·지연
Disk usage	디스크 공간
Network I/O	네트워크 부하

도구 — Prometheus + Grafana + Kafka Exporter, Confluent Control Center, Datadog.

파티션 수 결정 가이드

파티션 수 = 처리량 목표 / 컨슈머 1개 처리량

예시:
  처리량 목표 = 100MB/s
  컨슈머 1개 = 10MB/s
  → 파티션 10+ 필요

추가 고려:

미래 확장 여유
Disk I/O 능력
너무 많으면 (수만+) 메타데이터 부담

권장 시작 — 6~~12, 중규모 30~~50.

디스크·네트워크 권장

디스크

SSD 권장 (특히 active 세그먼트)
토픽별로 별도 디스크 가능 (log.dirs)
WAL과 데이터 같은 디스크 X — 분리

네트워크

1Gbps 이상
클러스터 내부 네트워크 분리 (replication 트래픽)

버전 호환성

Producer/Consumer ↔ Broker
Kafka 클라이언트 0.10+ ↔ 브로커 0.10+
하위 호환 유지 (대부분)

권장 — 클라이언트와 브로커 버전 맞추기

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 6편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

클러스터 = 여러 브로커 협력
목적 — HA·수평 확장·데이터 안전
Leader / Follower / Replicas
Leader가 모든 읽기·쓰기
Follower는 백업 (실시간 복제)
Kafka는 Read도 Leader에서만 (다른 분산 DB와 차이)
ISR (In-Sync Replicas) = Leader 페이스 따라잡는 Follower
replica.lag.time.max.ms (30초) 안에 따라잡기
acks=all은 모든 ISR 응답 (모든 Replicas X)
min.insync.replicas = 쓰기 안전선
ISR < min.insync.replicas → NotEnoughReplicas 예외
운영 — RF=3 + min.insync=2
토픽별 차등 가능
Leader 다운 → Controller가 새 Leader 선출 (수 초)
Unclean Leader Election — 운영 = false
true는 ISR 아닌 Replica를 Leader = 데이터 손실 가능
RF=3 = 운영 표준
RF=1 절대 X
Controller = KRaft 클러스터 관리자
정족수 (과반) 합의로 결정
Producer 운영 — acks=all·idempotence·lz4·batch·linger
Consumer 운영 — auto.commit=false·earliest 신중·CooperativeSticky
Broker 운영 — RF=3·min.insync=2·unclean=false·auto.create=false
모니터링 핵심 — Consumer Lag·ISR shrink·Under-replicated
파티션 수 = 처리량 / 컨슈머 처리량
시작 6~~12, 중규모 30~~50
SSD 권장 + WAL 데이터 분리
클라이언트·브로커 버전 맞추기

시리즈 다른 편

공식 문서: Kafka Operations 에서 더 깊이.

다음 글(7편)에서는 배치·병렬·에러 핸들링·트랜잭션 — 운영의 고급 패턴과 정확히 한 번(exactly-once)까지 풀어 갑니다.

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.