[Kafka] 파티션키·샤딩키로 순서가 보장되는 원리 — 유저 단위로 쪼개는 이유

1. 문서 제목

• 파티션키·샤딩키로 순서가 보장되는 원리 — 유저 단위로 쪼개는 이유

2. 기술 개요 요약

메시지 큐나 샤딩된 DB에서 "특정 키를 기준으로 파티션/샤드를 나누면 그 키 단위로 순서가 보장된다"는 설계는 자주 쓰이지만 왜 되는지는 종종 뭉뚱그려 이해된다. 원리는 두 가지 사실의 결합이다 — ① 같은 키는 항상 같은 목적지로 라우팅된다(결정적 해싱), ② 그 목적지 하나는 내부적으로 순서가 있는 자료구조다. 이 문서는 이 두 축을 Kafka 파티션과 DB 샤딩 두 사례로 정리한다.

3. 핵심 개념 정리

개념	설명	실무 포인트
결정적 라우팅	partition = hash(key) % 파티션수 — 키가 같으면 파티션 수가 바뀌지 않는 한 항상 같은 목적지가 나옴	유저 42의 이벤트는 항상 같은 파티션(혹은 샤드)에만 쌓임
파티션 내부의 순서	Kafka 파티션은 append-only 로그. 프로듀서가 쓴 순서대로 오프셋이 매겨지고 컨슈머는 오프셋 순으로 읽음	Kafka가 보장하는 순서 범위는 파티션 내부까지이지 토픽 전체가 아님
유저 단위로 쪼개는 이유	토픽 전체를 파티션 1개로 두면 전역 순서는 보장되지만 병렬 처리 불가. 완전 랜덤 분산은 병렬성은 최대지만 순서 보장이 전혀 없음	파티션 키를 "순서가 의미 있는 단위"(유저 ID, 주문 ID)로 잡으면 그 단위 안에서는 순서를 지키고 단위 간에는 병렬 처리 가능
DB 샤딩키도 동일 원리	userId % 샤드수로 샤드 결정 시 유저 42의 모든 row는 항상 같은 물리 DB에 있고, 그 DB는 단일 트랜잭션 타임라인을 가짐	"같은 키 → 항상 같은 물리적 목적지"라는 라우팅의 결정성 자체가 순서 보장의 근본 원리
리매핑 함정	hash(key) % N에서 N(파티션·샤드 수)이 바뀌면 같은 키라도 다른 목적지로 매핑될 수 있음	순서 보장이 중요한 토픽·샤드는 초기 설계 시 수를 넉넉히 잡아야 함. Consistent Hashing을 쓰면 리매핑 범위를 최소화 가능

4. 사용 예시 및 코드 스니펫

순서 보장 조건을 코드로 표현하면:

partition(key) = hash(key) % N   // N이 고정이면 같은 key는 항상 같은 partition

// 유저 42의 이벤트 스트림
produce(key="user-42", event="order.created")   -> partition 3
produce(key="user-42", event="order.paid")      -> partition 3  (같은 파티션, 순서 유지)
produce(key="user-7",  event="order.created")   -> partition 1  (다른 파티션, 유저42와 순서 무관)

5. 실제 사용 시 주의점 / Best Practice

• 순서 보장 범위를 "토픽 전체"로 착각하지 말 것. Kafka가 보장하는 건 파티션 내부까지다.
• 컨슈머 그룹 리밸런싱은 파티션 소유권(어떤 컨슈머가 담당하는지)의 이동일 뿐 파티션 내부 메시지 순서 자체를 바꾸지 않는다. 다만 리밸런싱 도중 커밋되지 않은 오프셋으로 인한 재처리(at-least-once)는 발생할 수 있어 컨슈머 로직은 멱등하게 설계해야 한다.
• 파티션·샤드 수를 나중에 늘리면 기존 키의 매핑이 깨질 수 있다. 순서 보장이 필요한 시스템은 트래픽 증가를 예측해 초기에 여유 있게 설계하는 편이 안전하다.
• DB 샤딩에서도 "같은 엔티티의 쓰기가 항상 같은 샤드로 가는가"를 먼저 확인해야 순서·트랜잭션 정합성을 논할 수 있다. 샤딩키 선택이 곧 순서 보장 범위를 결정한다.

6. 참고자료 / 공식 문서 출처

• Apache Kafka 공식 문서, Introduction — Kafka Guarantees: "Kafka only provides a total order over records within a partition, not between different partitions in a topic." https://kafka.apache.org/documentation/#introduction
• Apache Kafka 공식 문서, Design — The Producer(파티셔닝 전략): https://kafka.apache.org/documentation/#design_producer