핵심 인사이트 (3줄 요약)
- 본질: Apache Kafka (아파치 카프카)의 파티션(Partition)은 병렬 처리의 단위이자 순서 보장의 경계로, 파티셔닝 전략에 따라 "어느 파티션에 어떤 메시지가 들어가는지"가 결정되며 이는 소비자 그룹의 병렬성과 순서 보장에 직접 영향을 미친다.
- 가치: 키 기반(Key-Based) 파티셔닝은 같은 키의 메시지가 같은 파티션에 들어가 순서를 보장하고, 라운드로빈(Round-Robin)은 파티션 간 부하를 고르게 분산하며, 커스텀 파티셔너(Custom Partitioner)는 지역별·우선순위별 복잡한 라우팅을 가능하게 한다.
- 판단 포인트: 파티션 수 = 소비자 병렬 처리의 상한선이므로, 최대 예상 처리량을 초과 처리하는 파티션 수를 초기에 넉넉히 설계해야 한다. 파티션 수는 늘릴 수 있지만 줄일 수 없으며, 수를 늘리면 기존 키 기반 파티션 배정이 바뀌어 순서 보장이 깨질 수 있다.
Ⅰ. 개요 및 필요성
1. Kafka 파티션의 역할
파티션은 Kafka 토픽(Topic)을 나누는 물리적 단위다.
- 병렬 처리: 파티션 수 = 동시에 처리할 수 있는 최대 Consumer 수
- 순서 보장: 하나의 파티션 내에서는 메시지 순서 보장 (오프셋 순)
- 내구성: 파티션은 여러 브로커에 복제(Replication)되어 장애 내성 확보
토픽 "orders" (파티션 수 = 3):
파티션 0: [msg1] [msg4] [msg7] ... → Consumer 1
파티션 1: [msg2] [msg5] [msg8] ... → Consumer 2
파티션 2: [msg3] [msg6] [msg9] ... → Consumer 3
→ 3개 Consumer가 병렬 처리 가능
→ 4번째 Consumer를 추가해도 파티션이 3개뿐이면 유휴 Consumer 발생
📢 섹션 요약 비유
Kafka 파티션은 "슈퍼마켓 계산대"와 같다. 계산대(파티션) 수만큼 손님(소비자)이 병렬 처리 가능하다. 계산대가 3개인데 손님이 10명이면, 7명은 줄을 서야 한다.
Ⅱ. 아키텍처 및 핵심 원리
1. 세 가지 파티셔닝 전략
[1. 키 기반 파티셔닝 (Key-Based)]
Producer → hash(key) % 파티션수 = 파티션 인덱스
key="user-001" → hash("user-001") % 3 = 파티션 1
key="user-001" → 항상 파티션 1 → 순서 보장 ✓
key="user-002" → 파티션 0 → user-002 메시지 순서 보장 ✓
[2. 라운드로빈 (Round-Robin, 키 없음)]
msg1 → 파티션 0
msg2 → 파티션 1
msg3 → 파티션 2
msg4 → 파티션 0 ...
균등 분산 ✓, 순서 보장 ✗ (다른 파티션에 분산)
[3. 커스텀 파티셔너 (Custom Partitioner)]
if (msg.region == "KR") → 파티션 0
if (msg.region == "US") → 파티션 1
if (msg.priority == "HIGH") → 파티션 2
비즈니스 로직 기반 라우팅
2. 파티션 배정 메커니즘
| 전략 | Java API | 키 유무 | 균등 분산 | 순서 보장 |
|---|---|---|---|---|
| 키 기반 | 기본 (키 지정 시) | 필요 | 키 편중 가능 | 동일 키 내 보장 |
| 라운드로빈 | 기본 (키 null 시) | 불필요 | 균등 | 보장 안 됨 |
| 스티키 파티셔너 | 기본 (Kafka 2.4+) | 불필요 | 균등 | 배치 내 보장 |
| 커스텀 | Partitioner 인터페이스 구현 | 선택 | 설계에 따라 | 설계에 따라 |
3. 파티션 수 설계
파티션 수 설계 공식 (경험칙):
P = max(T_write / T_single_partition, T_read / T_single_consumer)
여기서:
T_write = 초당 프로듀서 처리량 (bytes/s)
T_single_partition = 파티션 1개당 처리량 (~10MB/s)
T_read = 초당 소비자 처리량 (bytes/s)
예시:
T_write = 1GB/s, T_single = 10MB/s
P = 1024MB / 10MB = 102 → 파티션 128개 (2의 거듭제곱)
📢 섹션 요약 비유
파티션 수 설계는 "고속도로 차선 수 설계"와 같다. 차선이 적으면 정체, 차선이 너무 많으면 유지 비용 증가. 예상 최대 차량 수(처리량)를 기준으로 초기에 충분히 설계해야 한다.
Ⅲ. 비교 및 연결
1. 컨슈머 그룹 리밸런싱(Consumer Group Rebalancing)
파티션 재배정이 발생하면 모든 Consumer가 일시 정지(STW: Stop-The-World)한다.
리밸런싱 발생 트리거:
- Consumer 그룹에 새 Consumer 합류
- Consumer 장애로 이탈
- 파티션 수 변경
- 파티션 재배정 타임아웃
Incremental Cooperative Rebalancing (Kafka 2.4+):
- 전체 정지 없이 필요한 파티션만 재배정
- "Cooperative" 알고리즘으로 처리 중단 최소화
2. 스티키 파티셔너 (Sticky Partitioner, Kafka 2.4+)
키 없는 메시지를 배치(Batch) 단위로 같은 파티션에 몰아서 처리 → I/O 효율 향상.
기존 라운드로빈: msg1→P0, msg2→P1, msg3→P2, msg4→P0 (배치 효율 낮음)
스티키: [msg1,msg2,msg3]→P0(배치 완성 후), [msg4,msg5]→P1
→ 배치 크기 증가 → 처리량 향상
📢 섹션 요약 비유
리밸런싱은 "팀 재구성 시 전원 대기"와 같다. 새 팀원이 합류할 때마다 전 직원이 업무를 멈추고 역할 재분배를 해야 한다. Cooperative Rebalancing은 "바뀌는 역할만 이동하고 나머지는 계속 일하는 방식"이다.
Ⅳ. 실무 적용 및 기술사 판단
1. 파티셔닝 전략 선택 가이드
| 요구사항 | 권장 전략 |
|---|---|
| 주문별 처리 순서 보장 | 키 기반 (order_id) |
| 사용자별 이벤트 순서 보장 | 키 기반 (user_id) |
| 단순 처리량 극대화 | 라운드로빈 (키 null) |
| 지역/우선순위별 라우팅 | 커스텀 파티셔너 |
| 키 스큐(Hot Partition) 해결 | 복합 키 또는 솔팅 |
2. 핫 파티션(Hot Partition) 문제 해결
특정 키에 메시지가 집중되면 해당 파티션이 병목이 된다.
# 솔팅으로 핫 파티션 방지
salt = random.randint(0, 9)
composite_key = f"user_001_{salt}" # 10개 파티션에 분산
# → 나중에 집계 시 user_001_* 패턴으로 합산
3. 체크리스트
- 최대 처리량 기반 파티션 수 초기 설계 (부족하면 나중에 늘려야 함)
- 파티션 수 변경 시 키 기반 라우팅 재검토
-
group.instance.id설정으로 Incremental Cooperative Rebalancing 활성화 - 핫 파티션 모니터링: 파티션별 오프셋 격차 확인
- Retention 정책: 보관 기간 × 처리량 = 스토리지 계획
📢 섹션 요약 비유
파티셔닝 전략 설계는 "물류 센터 창고 구획 설계"와 같다. 상품 종류별(키 기반)로 구역을 나눠 순서를 관리하거나, 용량 균등(라운드로빈)으로 배치하거나, 중요 상품 우선(커스텀)으로 전용 구역을 만들 수 있다.
Ⅴ. 기대효과 및 결론
1. 기대효과
| 효과 | 설명 |
|---|---|
| 병렬 처리 확장 | 파티션 수만큼 소비자 병렬화 가능 |
| 순서 보장 | 키 기반으로 도메인 내 이벤트 순서 보장 |
| 처리량 선형 확장 | 파티션 추가 = 처리량 비례 증가 |
2. 결론
Kafka 파티셔닝 전략은 처리량, 순서 보장, 부하 균등의 세 축을 균형 있게 설계하는 핵심 의사결정이다. 기술사 답안에서는 세 가지 전략의 차이, 파티션 수 설계 기준, 리밸런싱의 영향, 그리고 핫 파티션 방지 방법을 함께 서술하면 완성도 높은 답안이 된다.
📢 섹션 요약 비유
Kafka 파티셔닝은 "우체국 편지 분류 시스템"이다. 지역별 분류(키 기반)는 순서를 지키고, 무작위 분류(라운드로빈)는 처리량을 극대화하며, VIP 우선 처리(커스텀)는 비즈니스 규칙을 반영한다.
📌 관련 개념 맵
| 개념 | 관계 | 설명 |
|---|---|---|
| Consumer Group | 파티션의 소비 단위 | 파티션 수 = 최대 병렬 Consumer 수 |
| 리밸런싱 | 파티션 재배정 | Consumer 변동 시 발생하는 재할당 |
| Consumer Lag | 모니터링 지표 | 파티션별 처리 지연 측정 |
| Kafka Streams | 스트리밍 응용 | 파티셔닝 전략이 상태 파티션에 영향 |
| MirrorMaker 2 | 복제 도구 | 클러스터 간 파티션 토폴로지 복제 |
📈 관련 키워드 및 발전 흐름도
[카프카 토픽 (Kafka Topic) — 메시지를 논리적으로 분류하는 단위]
│
▼
[파티션 (Partition) — 토픽을 병렬 처리 단위로 분할, 순서 보장은 파티션 내 한정]
│
▼
[파티션 키 (Partition Key) — 동일 키는 동일 파티션, 연관 메시지 순서 보장]
│
▼
[파티션 복제 (Replication) — 리더·팔로워 복제본으로 내결함성 확보]
│
▼
[파티션 재조정 (Rebalancing) — 컨슈머 그룹 변경 시 파티션 재분배]
이 흐름은 카프카 토픽이 병렬 처리를 위해 파티션으로 분할되고, 파티션 키로 순서가 보장되며, 복제와 재조정을 통해 고가용성 스트리밍 아키텍처가 완성되는 과정을 보여준다.
👶 어린이를 위한 3줄 비유 설명
Kafka 파티션은 마트 계산대예요. 고객들을 어느 계산대로 보내느냐가 파티셔닝 전략이에요. "이름 순서로 줄 세우기(키 기반)"는 같은 이름 고객이 항상 같은 줄에 서서 순서가 지켜지고, "그냥 빈 줄로 보내기(라운드로빈)"는 모든 계산대가 바쁘게 돌아가요. 계산대 수(파티션 수)를 처음부터 충분히 만들어야 나중에 손님이 늘어도 줄이 막히지 않아요!