메시지를 파일에 계속 덧붙이고(append-only), 소비자가 읽은 위치(오프셋)를 기억하며 읽어 가는 분산 스트리밍 플랫폼. "큐"보다 분산 로그에 가깝다.
구조
토픽 "orders"
├── 파티션 0 : [0][1][2][3][4] ← 계속 뒤에 덧붙임
├── 파티션 1 : [0][1][2]
└── 파티션 2 : [0][1][2][3]
각 파티션 = 순서가 보장되는 하나의 로그 파일
- 토픽 — 메시지의 종류(주제)
- 파티션 — 토픽을 쪼갠 단위. 병렬 처리와 확장의 기본 단위
- 오프셋 — 파티션 안에서 몇 번째인지. 소비자가 "어디까지 읽었다"를 기록
다른 큐와 결정적으로 다른 점 — 읽어도 안 사라진다
일반 큐는 소비하면 메시지가 삭제된다. Kafka는 보존 기간(기본 7일) 동안 남아 있고, 소비자는 오프셋만 옮긴다.
그래서 가능해지는 것들:
- 재처리 — 오프셋을 되돌리면 과거 데이터를 다시 처리한다
- 여러 소비자 그룹 — 같은 데이터를 정산팀·추천팀이 각자 독립적으로 읽는다
- 장애 복구 — 소비자가 죽어도 오프셋부터 다시 읽으면 된다
컨슈머 그룹
토픽(파티션 3개)
├── 파티션 0 ──► 소비자 A ─┐
├── 파티션 1 ──► 소비자 B ├─ 그룹 "정산"
└── 파티션 2 ──► 소비자 C ─┘
같은 데이터를
├── 파티션 0,1,2 ──► 소비자 D ── 그룹 "추천" (독립적으로 전체를 읽음)
한 파티션은 그룹 안에서 한 소비자만 읽는다. 그래서 소비자 수 > 파티션 수 이면 남는 소비자는 놀게 된다 — 병렬성의 상한이 파티션 수다.
왜 빠른가
| 이유 | 내용 |
|---|---|
| 순차 디스크 쓰기 | 랜덤 I/O가 아니라 뒤에 덧붙이기만 함. HDD도 빠르다 |
| 페이지 캐시 활용 | OS 캐시에 의존해 JVM 힙을 안 씀 |
| 제로 카피 | 디스크 → 네트워크로 커널 안에서 바로 전송(sendfile) |
| 배치·압축 | 여러 메시지를 묶어 전송 |
RabbitMQ와 언제 갈리나
| Kafka | RabbitMQ | |
|---|---|---|
| 모델 | 로그 + 오프셋 | 큐 + 소비 후 삭제 |
| 강점 | 대용량·재처리·여러 소비자 | 유연한 라우팅·개별 제어 |
| 순서 | 파티션 내 보장 | 큐 내 보장 |
| 지연 | 배치 때문에 약간 큼 | 더 낮음 |
꼬리질문
"파티션을 늘리면 항상 빨라지나?" → 아니다. ① 소비자 수보다 많아야 병렬이 늘고 ② 파티션이 너무 많으면 리밸런싱·메타데이터 부담이 커지며 ③ 키 단위 순서 보장 범위가 좁아진다. 늘리면 기존 키의 해시 배정도 바뀐다.