[kafka] 토픽을 파티션으로 나누는 이유

1. 병렬 처리로 성능 향상

• 토픽을 여러 파티션으로 나누면, 여러 Producer가 동시에 다른 파티션에 기록할 수 있고,
  여러 Consumer가 동시에 다른 파티션에서 읽을 수 있음.
• 즉, 1개의 큰 로그 파일로 처리하는 것보다, 분산된 여러 파티션에 나눠 쓰고 읽는 게 훨씬 빠름.
• 예) 토픽에 1초당 10만 건이 들어와도, 파티션 5개로 나누면 각 파티션당 2만 건씩 처리 가능.

---

2. Consumer Group 기반 병렬 처리

• 카프카는 Consumer Group 단위로 메시지를 읽는데,
  → 1개의 파티션은 동시에 1개의 컨슈머만 읽을 수 있음.
• 따라서 파티션 수를 늘리면 Consumer를 더 많이 붙여 병렬 처리 가능.
• 예) 파티션 6개 → 컨슈머 그룹에 6개 컨슈머 붙이면 병렬 처리 x6.

---

3. 확장성과 유연성

• 클러스터 확장 시 브로커에 파티션을 재분배할 수 있어서,
  → 토픽 처리량이 늘어나면 브로커를 추가하고 파티션을 더 나눠 스케일 아웃 가능.
• 파티션 단위로 리더/팔로워(replica)가 관리되므로, 장애가 나도 특정 파티션만 영향 받고 나머지는 정상 동작.

---

4. 메시지 순서 보장 (단위 제어)

• 파티션 내부에서는 순서 보장이 됨.
• 전체 토픽 단위가 아니라 **“Key별 파티션”**으로 순서를 제어할 수 있어,
  → 같은 키(예: 주문 ID)의 메시지는 같은 파티션에 들어가 순서 보장.
  → 다른 키(예: 사용자 A와 B)는 병렬로 다른 파티션에 들어가 더 빠르게 처리.

---

그림으로 요약

 

Topic: Orders
 ├─ Partition 0 → [Msg1, Msg4, Msg7] (Consumer A 읽음)
 ├─ Partition 1 → [Msg2, Msg5, Msg8] (Consumer B 읽음)
 └─ Partition 2 → [Msg3, Msg6, Msg9] (Consumer C 읽음)

 

• 쓰기/읽기를 분산시켜 성능↑
• 컨슈머 그룹 병렬 처리 가능
• 파티션 내부 순서 보장

---

✅ 정리
토픽을 파티션으로 나누는 이유는:

1. 처리량 확장 (병렬 쓰기/읽기)
2. 컨슈머 그룹 병렬 처리
3. 브로커 간 분산 및 확장성
4. 파티션 단위 순서 보장

즉, 고성능·고가용성·확장성 있는 메시징을 만들기 위한 핵심 설계예요.