LLM WikiAccess-protected knowledge portal
← 스터디 홈
1편 · 약 15분

Kafka 아키텍처와 핵심 개념

왜 이벤트 스트리밍인가

마이크로서비스나 데이터 파이프라인에서 서비스 간 직접 호출은 두 가지 문제를 낳는다. 첫째, 호출하는 쪽이 받는 쪽의 가용성에 묶인다. 둘째, 처리 속도 차이를 흡수할 버퍼가 없다. 이벤트 스트리밍은 이 두 문제를 로그(log) 라는 추상으로 푼다. 생산자(producer)는 이벤트를 로그에 쓰고, 소비자(consumer)는 자기 속도로 로그를 읽는다. 서로 직접 연결하지 않으므로 독립적으로 스케일할 수 있다.

Apache Kafka는 이 아이디어를 수평 확장과 내구성을 갖춰 구현한 분산 이벤트 스트리밍 플랫폼이다. LinkedIn에서 내부 데이터 파이프라인을 위해 만들어 2011년 오픈소스화했으며, 현재는 Apache Software Foundation 프로젝트로 운영된다.

Topic: 이벤트의 논리적 채널

Kafka에서 이벤트를 쓰고 읽는 단위는 Topic이다. RDBMS의 테이블과 유사하지만 결정적인 차이가 있다. Kafka 토픽은 소비해도 메시지가 사라지지 않는다. 메시지는 설정한 보존 기간(retention) 동안 디스크에 남아 있어 여러 컨슈머가 같은 토픽을 독립적으로 읽을 수 있다.

각 메시지는 키(key), 값(value), 타임스탬프, 헤더로 구성된다. 키는 파티셔닝에 쓰이며 생략할 수 있다.

Partition: 스케일과 순서의 단위

토픽은 하나 이상의 Partition으로 나뉜다. 파티션은 Kafka 확장성의 핵심이다.

  • 파티션은 순서가 있는 불변(immutable) 레코드 시퀀스다. 새 메시지는 항상 끝에 추가된다.
  • 파티션 내에서는 순서(offset 순)가 보장된다. 파티션 간 순서는 보장되지 않는다.
  • 파티션 수만큼 병렬로 생산하고 소비할 수 있다. 파티션이 많을수록 처리량이 높아지지만 리더 선출, 파일 핸들, 메모리 오버헤드도 늘어난다.

각 레코드는 파티션 내 위치를 나타내는 Offset을 갖는다. Offset은 0부터 시작하는 단조 증가 정수이며, 컨슈머는 오프셋을 기록해 재시작 후에도 읽던 지점부터 다시 시작할 수 있다.

Broker, Cluster, Replica

Broker는 Kafka 클러스터를 구성하는 개별 서버 프로세스다. 각 브로커는 고유한 정수 ID를 갖는다. 프로듀서와 컨슈머는 브로커를 통해 데이터를 쓰고 읽는다.

내구성을 위해 파티션은 복제(replication) 된다. replication.factor=3이면 파티션 하나의 사본이 세 브로커에 분산된다.

역할설명
Leader해당 파티션의 모든 읽기·쓰기를 처리하는 사본
FollowerLeader에서 데이터를 복제하는 사본
ISRIn-Sync Replicas. Leader와 충분히 동기화된 팔로워 집합

프로듀서가 메시지를 보내면 리더가 받아 로컬에 쓴 뒤, ISR 팔로워들이 복제한다. 리더가 장애를 일으키면 ISR 중 하나가 새 리더로 선출된다. min.insync.replicas 설정은 acks=all 쓰기가 성공으로 간주되기 위한 최소 ISR 수를 정한다.

Consumer Group

Consumer Group은 토픽을 함께 소비하는 컨슈머 집합이다. Kafka의 메시지 소비는 두 가지 모델을 동시에 지원한다.

  • 큐(queue) 모델: 컨슈머 그룹 내에서 각 파티션은 정확히 한 컨슈머에만 할당된다. 메시지는 그룹 내 한 인스턴스만 처리한다.
  • Pub/Sub 모델: 서로 다른 컨슈머 그룹은 같은 토픽의 메시지를 독립적으로 소비한다.

파티션 수가 컨슈머 수보다 많으면 일부 컨슈머가 여러 파티션을 담당한다. 컨슈머 수가 파티션 수보다 많으면 초과 컨슈머는 유휴(idle) 상태가 된다. 병렬도의 상한은 파티션 수다.

전체 아키텍처 조감

Producers 서비스 A 서비스 B
→
Kafka Cluster (Topic: orders, partitions=3, RF=2)
Broker 0
P0-Leader P1-Follower Broker 1
P1-Leader P2-Follower Broker 2
P2-Leader P0-Follower
→
Consumer Group A Consumer 0
P0 Consumer 1
P1 Consumer 2
P2
__consumer_offsets
오프셋 커밋 내부 토픽 __cluster_metadata
KRaft 메타데이터 로그
KRaft Controller Quorum Controller 0 Controller 1 Controller 2
Kafka 클러스터 아키텍처 — 프로듀서, 브로커, 컨슈머, KRaft 컨트롤러

KRaft: ZooKeeper 없는 Kafka

초기 Kafka는 클러스터 메타데이터(토픽, 파티션 위치, 리더 정보 등)를 Apache ZooKeeper에 의존해 관리했다. 이 이중 시스템은 운영 복잡도를 높이고 파티션 수 한계(약 20만 개)를 만들었다.

KRaft(Kafka Raft)는 이 문제를 해결하기 위한 설계다. KIP-500으로 제안되어 Kafka 3.3.1에서 프로덕션 준비 완료로 선언됐고, Kafka 4.0(2024년 10월)에서 ZooKeeper 지원이 완전히 제거됐다. Kafka 4.0부터는 KRaft만 지원된다.

KRaft의 핵심은 메타데이터를 __cluster_metadata 내부 토픽에 Raft 합의 알고리즘으로 저장한다는 것이다. 몇 개의 컨트롤러 노드가 Raft 쿼럼을 구성해 리더를 선출하고, 메타데이터 변경을 커밋한다. 브로커 노드는 컨트롤러 리더에서 메타데이터를 패치 방식으로 받는다.

항목ZooKeeper 모드KRaft 모드
메타데이터 저장ZooKeeper 앙상블__cluster_metadata Raft 로그
최대 파티션 수약 20만약 190만
운영 구성 요소Kafka + ZooKeeperKafka만
Kafka 4.0 지원제거됨유일한 모드

오프셋과 재생(Replay)

컨슈머가 메시지를 읽은 뒤 오프셋을 커밋하면, 그 위치가 __consumer_offsets 내부 토픽에 저장된다. 이 덕분에 컨슈머가 재시작되거나 리밸런싱이 일어나도 이전에 처리한 오프셋 이후부터 다시 읽을 수 있다.

오프셋 커밋을 이해하는 것이 Kafka 신뢰성 설계의 출발점이다. 다음 장에서 이 주제를 프로듀서·컨슈머 설계와 함께 깊이 다룬다.

References

  • https://kafka.apache.org/documentation/
  • https://kafka.apache.org/40/getting-started/upgrade/
  • https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum
  • https://www.redpanda.com/guides/kafka-architecture-kafka-consumer-group
  • https://www.redpanda.com/guides/kafka-architecture-kafka-offset
  • https://andrewbaker.ninja/2026/02/17/apache-kafka-4-x-what-kraft-and-zookeeper-removal-mean/