Kafka 기본 구조 – Topic, Partition, Broker, Log Segments

임채령·2025년 11월 23일

위 그림은 Kafka의 가장 단순하고 핵심적인 구조를 보여준다.
Producer들이 데이터를 보내면, Kafka Cluster 내부의 여러 Broker가 이를 받아 저장하고, Consumer들은 저장된 데이터를 가져가는 형태다.
카프카를 깊게 이해하는 첫 단계는 이 단순한 그림 뒤에서 메시지가 실제로 어떻게 저장되고 관리되는지를 정확히 파악하는 것이다. 카프카는 메시지를 일시적으로 전달하는 단순 큐가 아니다.
내부적으로는 분산 로그 저장 시스템이며, 메시지를 디스크에 효율적으로 저장하고 복제하는 구조를 기반으로 높은 처리량, 안정성, 확장성을 제공한다.

이 글에서는 Topic, Partition, Broker 같은 기본 요소부터 Partition 내부의 Segment·Index 파일 구조, 메시지가 저장되는 흐름, Leader–Follower 복제 구조까지 핵심 동작 원리를 체계적으로 정리한다.

1. Topic, Partition, Broker의 기본 개념

Kafka에서 데이터는 Topic 단위로 관리되며, Topic은 단지 이름만 존재하는 논리적 구분이다.
실제 메시지가 저장되는 물리적 단위는 Partition이다.

Topic

메시지 스트림을 구분하는 이름
예: user-login, order-complete, payment-event

Partition

Topic을 나누어 저장하는 최소 물리 단위
각 Partition은 독립적인 로그 파일
순서가 보장되는 범위는 Partition 내부까지만
- Why?
  - Partition은 append-only 로그이기 때문
    - Kafka는 Partition을 뒤에만 붙이는(append) 단일 로그 파일로 관리한다.
    - append-only 구조는 자연스럽게 순서를 형성하므로, Partition 내부 순서는 보장된다.
  - 단일 Writer 모델이기 때문
    - 하나의 Partition에는 단 하나의 직렬화된 쓰기 스트림만 존재한다.
    - 동시에 여러 Writer가 들어오지 않으므로 순서가 섞일 일이 없다.
  - 전역 순서를 유지하려면 병목이 생기기 때문
    - Topic 전체에서 순서를 강제하면 모든 메시지가 단일 큐를 거쳐야 하고,
      이는 처리량을 극단적으로 제한한다. → 수평 확장 불가
  - 분산 환경에서 전역 순서는 사실상 불가능하기 때문
    - 여러 Broker, 여러 Partition이 존재하는 구조에서 전체 순서를 맞추려면
      글로벌 락 또는 글로벌 리더만 존재해야 한다 → 내결함성과 가용성 붕괴
  - Kafka가 선택한 확장성 철학 때문
    - Kafka는 서버를 늘리면 처리량이 선형 증가하도록 설계되었다.
    - Partition을 늘려 병렬 소비가 가능해야 하므로 전체 순서는 포기하고 파티션 단위만 보장
  - 비즈니스적으로 필요한 순서는 대부분 key 단위이기 때문
    - userId/계좌번호/주문번호 같은 동일 key만 순서가 중요하다.
    - Kafka는 이 key를 같은 Partition으로 라우팅함으로써 필요한 부분만 정확히 순서를 유지한다.
  - Partition이 확장성과 순서를 동시에 만족하는 최소 단위이기 때문
    - Partition = 여러 개로 쪼개면 병렬 처리 → 확장성
    - Partition 내부는 순수 로그 → 순서 보장
    - 두 요구사항을 동시에 충족할 수 있는 유일한 단위

Broker

카프카 서버 한 대를 의미
실제 Partition 파일을 디스크에 저장하고 관리

Topic은 Partition을 여러 개 가질 수 있고, Partition은 Broker 여러 대에 분산 저장된다.
이 덕분에 카프카는 메시지 처리량을 물리적으로 확장할 수 있는 구조를 갖는다.

그림으로 다시보자.
브로커는 하나의 Kafka 서버를 의미하며, 그 안에는 Topic이라는 논리적 이름 공간이 구성된다.
Topic은 실제 데이터를 저장하는 단위가 아니며, 내부적으로 여러 개의 Partition으로 나뉘어 있다.
이 Partition이 바로 메시지가 순차적으로 기록되는 물리적 저장 단위이며, 각 파티션은 브로커의 디스크에 실제 파일 형태로 저장되고 관리된다.

2. Partition의 동작 방식 – Append-Only Log

Partition은 내부적으로 append-only 구조의 로그다.
즉, 새로운 메시지가 오면 기존 데이터를 수정하거나 끼워넣지 않고 무조건 파일 끝에 추가된다.

이 방식은 다음과 같은 장점을 제공한다.

디스크 순차 쓰기 기반 → 고속 처리 가능
파일 변경(중간 수정)이 없으므로 락 경합 최소화
구조가 단순해 장애 복구가 쉬움

카프카의 성능은 결국 처음 설계된 저장 방식에서 나온다.

그림으로 다시 보자.
Producer가 보낸 메시지가 Kafka Broker 내부의 Partition에 offset 순서대로 차곡차곡 append되는 과정을 보여준다.
새로운 메시지는 항상 Partition의 가장 끝(offset 4) 에 추가되며, Consumer는 이 로그 스트림을 offset 순서대로 읽어 간다. 즉, Kafka Partition이 append-only 로그로 동작하며 순서를 강하게 보장하는 구조임을 설명한다.

3. Partition 내부는 Segment 파일로 구성된다

Partition을 하나의 큰 파일로 운영하면 관리가 어렵다.
그래서 카프카는 Partition을 여러 Segment 파일로 나누어 저장한다.

하나의 Segment 구성 요소

.log 파일 : 실제 메시지 기록
- 메시지 key / value (JSON, Avro 등)
- timestamp (이벤트 시간)
- 메시지 크기
- CRC (무결성 체크)
- 기타 header 필드
.index 파일 : 메시지 offset → 파일 위치 매핑
.timeindex 파일 : timestamp → offset 매핑

예를 들어 segment size가 1GB라면,
Partition이 커질 때마다 다음과 같은 파일이 생성된다:

00000000000000000000.log
00000000000000000000.index
00000000000000000000.timeindex

00000000000001000000.log
00000000000001000000.index
...

Segment를 나누는 이유는 크게 두 가지다:

대용량 파일이 너무 커지는 것 방지
오래된 Segment를 삭제(또는 compact)하기 쉬움

그림으로 다시보자.
Kafka는 .timeindex → .index → .log 순서로 매핑된 구조를 이용해 timestamp 기반 탐색을 내부적으로 수행한다.
즉, 특정 시각 이후의 메시지를 찾을 때는 timeindex에서 offset을 찾고, index에서 해당 offset의 byte 위치를 확인한 뒤, log 파일의 해당 위치로 바로 jump하는 방식이다.
하지만 일반적인 메시지 소비는 timestamp가 아니라 offset을 기준으로 이루어진다.
예를 들어 offset=100까지 읽었다면, 파일 포인터는 이미 그 위치에 있으며,
그 다음 메시지는 자연스럽게 바로 뒤에 있는 offset=101을 순차적으로 읽는 구조다.

4. 메시지가 Broker에 저장되는 실제 흐름

Producer가 메시지를 전송하면 Broker는 다음 순서로 저장한다.

1단계: TCP로 메시지 수신

Producer는 Leader broker로 요청을 보낸다.

2단계: 메시지를 메모리(페이지 캐시)에 적재

Broker는 메시지를 직접 파일에 바로 쓰지 않고 OS 파일 시스템 캐시를 활용한다.
이 덕분에 디스크 I/O를 최소화하면서도 높은 처리량을 유지할 수 있다.

3단계: Partition 로그 파일 끝에 append

Append-only 구조이므로 파일 끝에 바로 추가하면 된다.

4단계: OS가 flush 정책에 따라 디스크에 기록

Broker 자체가 디스크를 직접 “sync write” 하는 것이 아니다.
대부분 OS의 write-back 캐시 메커니즘을 활용한다.

5단계: Follower가 Leader의 데이터를 복제

Follower는 다음과 같은 흐름으로 Leader의 메시지를 동기화한다:

Leader 오프셋 확인 → 미싱 데이터 요청 → append → 증분 반복
Leader와 Follower가 완전히 동기화된 경우를 ISR(In-Sync Replica)라고 부른다.

이 구조는 카프카가 높은 성능과 안정성을 동시에 유지하는 핵심이다.

그림으로 다시보자.
Replication Factor = 3
환경에서 하나의 파티션이 3개의 브로커(Leader 1개, Follower 2개)에 복제되는 구조를 보여준다.
Producer는 오직 Leader 브로커에만 메시지를 쓰고, Followers는 Leader에서 새로운 데이터를 읽어와 동일한 파티션 내용을 복제한다.
Consumer는 Leader(또는 설정에 따라 Follower)에서 메시지를 읽어가며, 세 브로커는 항상 동일한 offset의 동일한 데이터를 유지한다.

그림으로 다시보자.
사용자가 파일을 읽으려고 하면 커널이 먼저 PageCache에 해당 데이터가 있는지 확인하는 구조를 보여준다.
PageCache에 없으면(Miss) 커널은 디스크에서 데이터를 읽어 PageCache에 저장하고, 그 데이터를 사용자에게 반환한다.
즉, 이 그림은 디스크 읽기 요청이 PageCache를 통해 최적화되는 OS의 기본 동작 방식을 설명한다.