Kafka 파티션 증설 없이 처리량 한계 돌파하기: Parallel Consumer 적용기 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#performance-optimization#consumer-lag#apache-kafka#parallel-consumer#event-streaming#message-processing

AI 요약

주문 이벤트 플랫폼에서 Kafka lag이 주문 취소로 이어질 수 있는 처리량 문제에서 출발한다. consumer 증설은 partition 수에 막히고 partition 증설은 rebalance·offset 유실·DLT 불일치 위험을 만든다는 딜레마를 짚고, 한 partition 안에서도 병렬 처리하는 Confluent Parallel Consumer 도입기로 이어진다.

핵심 포인트

서버 증설은 병렬성이 partition 수를 넘지 못하고 운영 중 partition 증설은 rebalance 지연·latest offset 유실·DLT partition 불일치 위험을 동반한다는 기존 해법의 한계를 분석
Parallel Consumer는 poll한 record를 key별 shard로 나눠 worker thread에 배정해 서로 다른 key는 병렬, 같은 key는 순서를 유지하고, key·partition·unordered 중 순서 기준을 선택
offset map이 완료·미완료 record를 따로 기록하고 연속 처리된 최고 offset만 commit해 재시작 시 재처리 대상을 구분 — canary 배포 lifecycle, 무한 retry·미내장 DLT 직접 구현, rollback 시 중복 처리 가이드까지 SDK로 통합
47만 건 등 세 조건 검증에서 큰 workload는 처리 시간 52.9% 감소, 평균 66.36% 비용 절감. 단 committed offset과 내부 완료 상태가 달라 자체 metric이 필요하고, I/O 대기가 크고 partition 확대가 어려운 서비스에 선택 적용

왜 읽나Kafka 처리량이 partition 수에 묶여 고민하는 백엔드 개발자에게 partition 증설 없이 병렬성을 끌어올리는 Parallel Consumer의 내부 구조·운영 함정·적용 조건을 담은 실전 레퍼런스.

챕터별 상세

010:39 – 9:42

주문 이벤트 처리량 문제와 기존 해법의 한계

주문 이벤트 플랫폼의 consumer 처리량이 부족해 Kafka lag이 늘면 피크 시간에는 초당 수백 건의 주문 이벤트가 지연되고 주문 취소까지 이어질 수 있다. 서버를 더 띄워도 병렬성은 partition 수를 넘지 못하고, 로직 최적화는 각 소비처의 대응에 의존하며, 운영 중 partition 증설은 rebalance 지연과 latest offset 유실 가능성 및 DLT partition 불일치 같은 위험을 만든다.

Parallel Consumer는 단일 consumer 인스턴스에서 한 partition의 여러 메시지를 동시에 처리해 Kafka의 partition 수와 처리 병렬성 사이의 결합을 완화하는 JVM 라이브러리다. Spring Kafka와 batch consumer가 partition 단위 동시성에 묶이는 것과 달리 key·partition·unordered 가운데 순서 보장 기준을 선택하고 concurrency로 처리 폭을 조정할 수 있다.

poll한 record를 key별 shard로 나누고 각 shard를 worker thread에 배정하면 서로 다른 key는 병렬 처리하면서 같은 key의 순서는 유지할 수 있다. 완료 순서가 뒤섞이는 상황에서는 offset map이 완료·미완료 record를 따로 기록하고, 연속으로 처리된 가장 높은 offset만 commit해 재시작 때 이미 완료한 record와 다시 처리할 record를 구분한다.

기존 canary 배포의 stop·start 과정에서는 같은 ParallelStreamProcessor를 두 번 poll할 수 없어 supplier 기반 지연 생성과 종료 시 참조 제거로 객체 lifecycle을 다시 설계했다. Spring Kafka와 달리 무한 retry가 기본이고 DLT가 내장되지 않아 횟수 제한과 재발행을 직접 구현했으며, rollback 시 offset map을 모르는 기존 consumer가 일부 record를 중복 처리할 수 있다는 운영 가이드도 마련했다.

적체, 47만 건 처리, 일부 느린 메시지라는 세 조건에서 Parallel Consumer는 처리 시간을 각각 유의미하게 줄였고 큰 workload에서는 52.9% 감소를 확인했다. 다만 committed offset과 내부 완료 상태가 달라 기존 Kafka lag만으로 상태를 판단할 수 없어 처리 중·대기 중 메시지와 최고 metadata offset 등의 자체 metric을 추가했으며, I/O 대기가 크고 partition 확대가 어려운 서비스에 선택적으로 적용해야 한다.