Kafka 전체 구조 (Architecture)

데이터 모델 · 물리 저장 · 조율 3층을 한 장으로

데이터 모델 (논리) 물리 저장 / 브로커 조율 (coordination)

① 큰 그림

생산자 → 클러스터(브로커들) → 소비자 그룹. 그리고 그 위를 조율하는 Controller / 합의.

   PRODUCERS                    ┌──────────────── Kafka Cluster ────────────────┐                 CONSUMER GROUPS
   (partitioner)                │                                                │                 (Group Coordinator가 할당)
                                │   Broker 1        Broker 2        Broker 3     │
  key=seatId ──┐               │  ┌─────────┐    ┌─────────┐    ┌─────────┐     │            ┌── group "db-writer" ──┐
               ├─ PRODUCE ────▶│  │ p0 LEAD │    │ p1 LEAD │    │ p2 LEAD │     │── FETCH ──▶│  c1→p0  c2→p1  c3→p2   │
  key 없음 ────┘  (해시/RR)     │  │ p1 foll │    │ p2 foll │    │ p0 foll │     │            └───────────────────────┘
                                │  └─────────┘    └─────────┘    └─────────┘     │            ┌── group "search" ────┐
                                │   복제(ISR): leader 1 + follower N             │── FETCH ──▶│  x1→p0,p1   y1→p2      │
                                │                                                │            └───────────────────────┘
                                │   [ Controller ]  파티션 leader 선출·ISR·메타  │              (다른 그룹 = 각자 다 받음)
                                │        ↕  합의: ZooKeeper(옛)  →  KRaft(지금)   │
                                │   __consumer_offsets 토픽 = 모든 그룹의 책갈피  │◀── commit ──(각 그룹의 offset)
                                └────────────────────────────────────────────────┘

② 세 계층으로 분해

같은 시스템을 세 관점으로 보면 구조가 또렷해진다.

A. 데이터 모델 (무엇을 담나 — 논리)
Cluster
└─ Topic # 논리 카테고리 (성격 다르면 토픽 분리)
   └─ Partition # 병렬성 + 순서의 단위, append-only log
      └─ Record # offset · key · value · timestamp · CRC
B. 물리 저장 (디스크에 어떻게)
Broker (서버 1대)
└─ Partition replica # leader 1 + follower N = ISR (복제)
   └─ Segment # .log + .index, 파일명 = baseOffset
      ├─ Record bytes # 순차 append (빠름)
      └─ Sparse mmap index # offset → 파일 위치 (4KB 간격)

→ 파티션은 여러 브로커에 흩어져 저장되고, 각 파티션은 leader/follower로 복제됨.

C. 조율 (누가 관리하나) — 다음 섹션에서 상세
Producer → partitioner # key→partition 결정
Consumer Group → Group Coordinator # 멤버십·할당·offset
Broker/Cluster → Controller # 파티션 leader·ISR·메타
합의 기반 → ZooKeeper → KRaft # controller 선출·메타 합의

③ 조율의 3층 (이번 세션의 핵심)

"누가 무엇을 조율하나" — 아래로 갈수록 더 근본적인 계층.

1
컨슈머 레벨
Group Coordinator (브로커 역할) — 같은 group.id 인스턴스들의 멤버십·파티션 할당(rebalance)·heartbeat 관리. 오프셋은 __consumer_offsets 토픽에 중앙 저장(인스턴스끼리 직접 공유 X). 1 파티션 = 1 인스턴스라 충돌 없음.
2
브로커/클러스터 레벨
Controller (브로커 중 하나) — 각 파티션의 leader 선출, ISR 관리, 토픽/파티션 메타데이터 관리. leader 죽으면 ISR에서 새 leader 뽑아 무손실 페일오버.
3
합의(consensus) 기반
ZooKeeper → KRaft — Controller 선출과 메타데이터 합의의 토대. 옛날엔 외부 ZooKeeper, 지금은 KRaft(Raft를 Kafka 내부에 구현, 메타데이터도 내부 로그). Kafka 4.0부터 ZooKeeper 완전 제거.
헷갈리지 말 것 — 1층(Group Coordinator)은 컨슈머 조율, 2·3층(Controller·KRaft)은 브로커 조율. 컨슈머 오프셋은 현대 Kafka에선 ZooKeeper가 아니라 __consumer_offsets 토픽에 있다.

④ 구조를 떠받치는 핵심 원리 5

1. append-only log
랜덤이 아닌 순차 쓰기 → 디스크에서도 빠름. 모든 저장의 기본 형태.
2. offset = 책갈피
순서가 아니라 "어디까지 읽었나"(위치). (group, partition) 단위라 인스턴스가 죽어도 진도 유지.
3. partition = 병렬성·순서의 단위
파티션 수 = 컨슈머 병렬도 상한. 같은 파티션 안에서만 순서 보장.
4. consume ≠ 삭제
읽어도 안 사라짐. offset만 전진 → 다른 그룹 재소비·replay 가능.
5. 모든 게 로그
사용자 데이터도, 컨슈머 offset도, KRaft 메타데이터도 전부 append-only 로그.
+ key의 두 역할
① 같은 key→같은 파티션(순서) ② log compaction(같은 key 최신만).

⑤ 순서 · 소비 규칙 요약

질문답
순서는 어디까지 보장?한 파티션 안에서만. 토픽 전체(글로벌) 순서는 없음.
특정 단위 순서를 원하면?key로 묶기 (seatId, orderId…). 같은 key→같은 파티션.
전체 순서가 꼭 필요하면?파티션 1개 (병렬성 포기 — 트레이드오프).
같은 그룹 컨슈머들은?파티션을 나눠 가짐 (1 파티션 = 1 컨슈머). 한 파티션을 쪼개 읽지 않음.
다른 그룹은?같은 데이터를 각자 다 받음 (fan-out), 각자의 offset으로.
컨슈머 7개, 파티션 6개면?6개가 1개씩, 1개는 idle. (병렬도 상한 = 파티션 수)
여러 서버의 같은 그룹은?Group Coordinator가 할당, offset은 브로커에 중앙 저장. 죽으면 rebalance로 이어받음.

⑥ MyKafka는 이 구조 중 어디까지?

✅ 구현한 것 (단일 노드 본질)
  • Topic / Partition / Record / offset
  • Segment(.log+.index) · sparse mmap index
  • append-only log · 꼬리 자르기 recovery
  • Partitioner (key 해시 / round-robin)
  • __consumer_offsets 중앙 offset 저장
  • batch write (61× speedup)
❌ 없는 것 (= 분산·조율 계층)
  • Replication / ISR (단일 노드)
  • Controller (파티션 leader 선출)
  • ZooKeeper / KRaft (합의)
  • Group Coordinator (rebalance·heartbeat)
  • Zero-copy (sendfile) — 재직렬화 중
  • Exactly-once / 클라이언트 SDK

→ MyKafka는 "한 브로커 안의 로그 엔진"까지. 분산 시스템으로 만드는 ③의 조율 3층이 빠져 있다 (의도적, 학습 로드맵 §7).

한 문장 구조 요약 — Kafka = 여러 브로커에 분산된 append-only 로그(Topic>Partition>Segment>Record)를, Controller+KRaft가 브로커를 조율하고 Group Coordinator가 컨슈머를 조율하며, offset(책갈피)으로 각 그룹이 자기 진도를 추적하는 시스템. 순서는 파티션 단위로 지키고, 데이터는 읽어도 안 지운다.

출처: 이번 세션 Q&A 정리 + msa/kafka.md · 2026-05-26
함께 보기: kafka-lifecycle-steps.html(단계별), kafka-summary.html(CRC·차이), kafka-lifecycle.html(흐름도)