Kafka 파티션은 컨슈머에게 배정된다.

Kafka의 Topic은 생성될 때 파티션 개수를 지정하고 그 개수만큼 파티션으로 나뉜다.

post-events // 토픽
 ├─ partition 0
 ├─ partition 1
 └─ partition 2

그리고 이렇게 나눠진 각각의 파티션들은 컨슈머 그룹 내의 컨슈머들에게 하나씩 배정이 된다.

이렇게 카프카가 파티션을 컨슈머에게 배정하는 이유가 뭘까?
크게 3가지 이유가 있다.
큐에 들어온 이벤트의 중복 소비를 막고, 병렬 처리를 하면서, 파티션 내부 순서를 보장하기 위함이다.

1. 같은 그룹 안에서 중복 처리를 막는다.

예를 들어 post-events 라는 토픽에 3개의 파티션이 있다고 해보자.

컨슈머가 3개 있고 모두 같은 consumer group에 속하면 kafka는 이렇게 파티션 하나를 컨슈머 하나에게 배정한다.

consumer A → partition 0

consumer B → partition 1

consumer C → partition 2

그렇게 되면 partition 0의 메시지는 consumer A만 읽을 수 있게된다.

만약 파티션 배정이 없다면 메시지 하나가 들어왔을 때 consumer A, B, C가 전부 같은 메시지를 읽게 되어 글 발행 이벤트가 한번 일어나도 알림이 세번 생성되는 등의 문제가 발생할 수 있다.

하지만 카프카는 하나의 파티션 = 하나의 컨슈머에게 배정 이라는 원칙을 둬서 이런 중복처리를 막는다.

2. 병렬 처리

카프카는 파티션 단위로 병렬성을 만든다.
파티션이 3개면 동시에 최대 3개의 컨슈머가 나눠서 처리할 수 있다.

partition 0 → consumer A
partition 1 → consumer B
partition 2 → consumer C

이렇게 하면 한 컨슈머가 모든 파티션을 혼자서 읽고 처리할 때보다 훨씬 빠르다.

다만 이때 고려할 점이 하나 있는데 같은 consumer group의 병렬 처리 최대치는 보통 파티션 개수와 같기 때문에 파티션이 3개인데 컨슈머를 10개로 늘린다고 해서 처리속도가 증가하진 않는다.

3. 파티션 내부 순서를 보장

카프카에서는 메시지 순서가 토픽 전체 기준이 아니라 파티션 내부 기준으로 보장된다.
그래서 만약 하나의 파티션을 여러 컨슈머가 동시에 읽게 하면 순서가 꼬일 수 있다.

예를 들어 주문 상태 이벤트가 있다고 해보자.

partition 0
offset 0: OrderCreated
offset 1: OrderPaid
offset 2: OrderShipped

이걸 여러 컨슈머가 동시에 읽으면 아래와 같은 문제가 생길 수 있는데

consumer A → OrderCreated 처리 중
consumer B → OrderPaid 먼저 처리 완료
consumer C → OrderShipped 먼저 처리 완료

위와 같은 케이스에서는 결제 완료가 주문 생성보다 먼저 처리되거나 배송 시작이 결제 완료보다 먼저 처리되는 등의 비즈니스 로직 문제로 이어지게 된다.