메시지를 어느 파티션에 넣을지 결정하는 값. Kafka에서 순서 보장의 단위를 정한다.
어떻게 배정되나
partition = hash(key) % 파티션_수
키가 없으면(null) 라운드로빈 또는 sticky 방식으로 골고루 분산된다.
왜 중요한가 — 순서는 파티션 안에서만 보장된다
파티션 0 : [주문A생성] [주문A결제] [주문A취소] ← 이 안에서는 순서 보장 파티션 1 : [주문B생성] [주문B결제]
주문 이벤트를 order_id를 키로 보내면 한 주문의 이벤트가 항상 같은 파티션에 들어가
생성 → 결제 → 취소 순서가 지켜진다.
키 없이 보내면 흩어져서 취소가 생성보다 먼저 처리될 수 있다.
전역 순서는 보장되지 않는다
파티션이 여러 개면 파티션 간 순서는 없다. 전체 순서가 꼭 필요하면 파티션을 1개로 해야 하는데, 그러면 병렬 처리를 포기하는 것이다.
실무에서는 "전역 순서가 정말 필요한가"를 먼저 따진다. 대개는 엔티티 단위 순서(주문별·회원별)면 충분하고, 그것은 키로 해결된다.
함정 ① — 키 편중(hot partition)
- 파티션 0 : ████████████████ — ← 대형 고객 A의 트래픽이 전부 여기로 파티션 1 : ██ 파티션 2 : █
특정 키에 트래픽이 몰리면 그 파티션의 소비자만 밀린다. 다른 소비자는 놀고 있는데 전체 지연이 발생한다.
→ 키를 더 잘게 쪼개거나(고객ID → 고객ID:주문일자), 편중된 키만 별도 처리한다.
다만 쪼개면 그만큼 순서 보장 범위도 좁아진다 — 트레이드오프다.
함정 ② — 파티션 수를 바꾸면 배정이 달라진다
hash(key) % N 에서 N이 바뀌면 같은 키가 다른 파티션으로 간다.
파티션 3개일 때: hash("order-1") % 3 = 1 파티션 4개로 늘리면: hash("order-1") % 4 = 2 ← 다른 곳!
기존 순서 보장이 깨지고, 전환 시점에 같은 키의 메시지가 두 파티션에 나뉘어 순서가 역전될 수 있다. 그래서 파티션 증설은 신중해야 하고, 처음에 넉넉히 잡는 것이 관행이다(줄이는 것은 아예 불가능하다).