Kafka 컨슈머 순서 보장: 파티션 키와 체크포인트로 병렬 처리하기

Kafka 컨슈머를 늘렸는데도 주문과 취소처럼 순서가 필요한 이벤트가 서로 기다리면 처리량이 묶입니다. 이때 순서를 토픽 전체에 걸지 말고, 같은 업무 키가 들어가는 파티션 안으로 좁히면 컨슈머를 병렬로 돌리면서 순서를 지킬 수 있습니다.

직접 돌려보지는 않았습니다. Apache Kafka 공식 문서와 공개된 설계 내용을 읽고 정리했습니다. 저라면 전역 순서를 만들기보다 user_id나 order_id처럼 업무상 묶여야 할 키부터 정하겠습니다.

개요

Kafka consumer group에서는 한 파티션을 한 컨슈머만 읽습니다. 파티션이 여러 개면 컨슈머가 나눠 읽습니다. 같은 사용자의 이벤트를 같은 파티션으로 보내면, 그 사용자 흐름은 파티션 offset 순서로 제한할 수 있습니다.

토픽 전체 순서는 포기해야 합니다. 대신 서로 무관한 사용자의 이벤트는 다른 파티션에서 바로 처리됩니다. 주문 생성 뒤 결제가 와야 하는 서비스라면 이 경계가 훨씬 현실적입니다.

1. 메시지 키

Producer가 순서를 묶을 기준을 key로 넣습니다. 사용자 단위라면 user_id, 결제 단위라면 order_id가 후보입니다. 같은 키가 항상 같은 파티션으로 가는지부터 확인하시면 됩니다.

{
  "key": "<order_id>",
  "value": {"event": "payment_completed"}
}

키를 비워 두면 필요한 이벤트가 다른 파티션에 흩어질 수 있습니다. 파티션 수를 나중에 바꾸는 일도 조심해야 합니다. 해시 결과가 달라지면 같은 키의 도착 파티션이 달라질 수 있습니다.

2. 체크포인트

단계가 다른 컨슈머가 같은 파티션을 읽는 구조라면 뒤쪽 컨슈머는 앞 단계 체크포인트를 넘지 않게 둡니다. 앞 단계가 offset 120까지 끝냈다면 뒤 단계도 120까지만 처리합니다. 121이 멈춘 상태에서 122만 끝나도 commit은 120에 둡니다.

빈 offset 없이 끝난 위치만 commit합니다. 이 규칙이 중복 처리와 유실을 살피는 기준입니다. 처리 속도가 느린 단계가 있어도 다른 파티션까지 멈출 이유는 없습니다. 파티션별 지연만 따로 보시면 됩니다.

3. 적용 범위

이 방식은 사용자 행동, 주문 상태, 재고 변경처럼 같은 키 안의 순서가 필요한 이벤트에 맞습니다. 모든 이벤트를 한 줄로 세워야 하는 경우에는 맞지 않습니다. 그런 요구라면 파티션 수와 업무 모델을 먼저 나눕니다.

기존 Docker MongoDB Replica Set 구축 글처럼 여러 노드가 같은 데이터를 다룰 때도, 어떤 단위에서 순서를 보장할지 먼저 정하면 운영 기준이 선명해집니다.

확인

컨슈머 그룹의 파티션 배정과 offset을 아래 명령으로 확인하시면 됩니다.

kafka-consumer-groups --bootstrap-server <BROKER> --describe --group <GROUP_ID>

파티션별 CURRENT-OFFSET과 LAG가 보이면 그룹 상태를 확인한 것입니다. 같은 키가 한 파티션으로 들어오는지는 Producer 로그와 파티션 번호를 함께 살피시면 됩니다.