Kafka에서 Consumer Group은 단순히 “여러 Consumer가 메시지를 나눠 읽게 하는 기능”이 아니다.
Consumer Group 구조는 고가용성(HA), 병렬 처리, Failover, 부하 분산, Offset 관리, Rebalance 안정성까지 포함하는 Kafka 고유의 핵심 메커니즘이다.
Consumer Group을 제대로 이해하면 Kafka 메시지가 왜 특정 Consumer로만 배정되는지, Failover 시 어떤 편향이 생기는지, Lag이 왜 생기는지 등 대부분의 문제를 스스로 분석할 수 있게 된다.
1. Consumer Group이 필요한 이유
Kafka는 병렬 처리와 확장성 때문에 Partition 구조를 사용한다.
하지만 Partition을 여러 Consumer가 동시에 읽으면 순서가 깨지고 중복 처리 문제가 발생할 수 있다.
이를 해결하는 구조가 바로 Consumer Group이다.
Consumer Group 목적
- 각 Partition을 한 시점에 오직 한 Consumer만 읽도록 보장
- Consumer 수를 늘려 병렬 처리량 획득
- Consumer 장애 시 자동 Failover
- Offset을 Group 단위로 관리하여 상태 일관성 유지
예: Partition 6개, Consumer Group 1개 (3개 Consumer)
→ Consumer당 2개 Partition씩 배정되어 병렬 처리 가능
그림으로 다시보자.
- Topic의 Partition들은 Consumer Group A와 B에 각각 독립적으로 할당되며, 서로의 처리에 영향을 주지 않는다.
- 각 Consumer Group 내부에서는 Partition이 겹치지 않게 분배되어 Group 내에서 한 Partition은 반드시 하나의 Consumer만 읽는다.
- Consumer Group을 늘리면 병렬 처리량이 증가하고, 각 Group은 자체 offset을 관리해 완전히 독립된 처리 흐름을 가진다.
2. Partition Assignment 방식
Kafka는 Rebalance 시 Partition을 Consumer들에게 어떻게 배정할지 다양한 전략을 제공한다.
가장 많이 사용되는 세 가지는 다음과 같다.
A. Range Assignment
가장 기본적인 방식
Partition ID를 기준으로 Range 단위로 나눈다.
예: Partition 6개, Consumer 3명
- C1: 0,1
- C2: 2,3
- C3: 4,5
특징
- 단순하고 빠름
- Partition Key가 특정 범위에 모이면 편향(Skew)이 발생할 수 있음
- 여기서 말하는 편향이란 ?
- 일부 Partition에만 데이터가 몰려서 특정 Consumer만 과부하가 걸리는 상황
- 여기서 말하는 편향이란 ?
B. Round Robin Assignment
Partition을 Consumer에게 순환 방식으로 배정한다.
예: Partition 6개, Consumer 3명
- C1: 0,3
- C2: 1,4
- C3: 2,5
특징
- 가장 균등 분배
- Consumer와 Partition 수가 클 때 유리
C. Sticky Assignment (Kafka 최신 기본 방식)
Kafka 2.4 이후 기본 정책
Rebalance가 발생하더라도 “이전 배치를 최대한 유지”하려고 한다.
특징
- Rebalance 비용 최소화
- Partition 재배치 최소
- 안정성 및 성능 개선
3. Rebalance의 전체 과정
Rebalance는 Kafka Consumer Group에서 가장 중요한 동작이다.
여기서 Rebalance란 Kafka Consumer Group 안에서 Partition을 어떤 Consumer가 가져갈지 재조명 하는 과정이다.
Consumer Group 내 Consumer 수가 바뀌거나, Consumer가 느려지거나, Heartbeat가 끊기면 Rebalance가 발생한다.
Rebalance는 다음 단계로 진행된다.
1) Join Group
모든 Consumer는 GroupCoordinator에게 “나는 이 그룹에 참여할게” 요청을 보낸다.
이 단계에서는 Consumer 모두가 일시적으로 메시지 소비(poll loop)를 멈춘다.
2) Leader Consumer 선출
GroupCoordinator는 참여한 Consumer 중 한 명을 Leader로 지정한다.
Leader는 Partition–Consumer 매핑을 담당한다. (Partition Allocator)
3) Partition Assignment
Leader는 할당 정책(Range, RoundRobin, Sticky 등)을 기준으로
“어떤 Consumer가 어떤 Partition을 가져갈지” 계산한다.
- Range 방식
- RoundRobin 방식
- Sticky 방식
4) Sync Group
Leader는 계산된 assignment를 GroupCoordinator에게 보내고, Coordinator는 이를 모든 Consumer에게 전파한다.
5) 각 Consumer는 Assigned Partition을 poll()하여 소비 시작
모든 Consumer가 새로운 Partition 세트를 받아 poll loop 재개
Rebalance가 일어나면 어떤 일이 발생하는가?
- 모든 Consumer가 잠깐 멈춤
- Offset commit이 이루어지지 않았다면 중복 처리 가능
- Partition 소유권이 바뀌므로 상태(세션 캐시 등) 초기화 필요
그림으로 다시보자.
- Consumer가 리밸런스를 시작하면 기존 Partition을 반납(onRevoked)하고, JoinGroup → Assign → SyncGroup 순서로 새로운 Partition 할당을 받는다.
- 이 과정 동안 Heartbeat 간격, 네트워크 왕복 시간, Rebalance Listener 콜백(onRevoked/onAssigned)이 단계별로 발생한다.
- 전체 Rebalance Latency(파란색)는 Consumer가 메시지를 완전히 멈춘 채 Partition 재할당을 기다리는 시간 구간을 의미한다.
4. Consumer Failover
Consumer 하나가 죽거나 느려지면 Kafka는 자동으로 Failover를 수행한다.
동작:
- 특정 Consumer가 Heartbeat를 일정 시간 동안 보내지 않음
- GroupCoordinator는 해당 Consumer를 그룹에서 제외
- Rebalance 시작
- 해당 Consumer가 담당하던 Partition을 다른 Consumer에게 재배정
- 정상 소비 재개
Kafka는 Consumer 장애를 별도의 알림 없이 자동으로 처리한다.
이 때문에 Kafka는 HA 분산 메시징 시스템으로 높은 신뢰성을 가진다.
5. Consumer Lag 의미 및 계산
Consumer Lag이란?
어떤 Partition에서 현재 Producer가 보내서 Kafka 서버가 기록한 “최신 Offset”과 Consumer가 “마지막으로 committed한 Offset”의 차이를 뜻한다.
즉,” 읽어야할 메시지가 얼마나 밀려있는가” 를 뜻한다.
Lag = LatestOffset - CommittedOffsetLag가 높다는 것은?
- Consumer가 정상 속도로 데이터를 읽지 못하고 있다
- 처리량 병목 현상 발생
- Scaling 또는 Consumer 튜닝 필요
Lag가 발생하는 주요 원인
- Consumer 처리 속도가 Producer보다 느림
- Rebalance 직후 아직 데이터 읽기 시작 못함
- Consumer 장애/지연
- 네트워크 부하
Lag 모니터링은 Kafka 운영의 필수 요소
대부분의 Kafka Dashboard(Grafana, Lenses, Conduktor 등)에서 Consumer Lag은 핵심 지표 중 하나다.
그림으로 다시보자.
- Producer는 시간이 지날수록 더 높은 Offset(134 → 144 → 154)을 가진 메시지를 계속 생성한다.
- Consumer는 뒤처진 Offset에서 읽기 때문에 Producer와 Consumer 사이에 Lag이 발생한다.
- Consumer가 읽은 최신 Offset과 Producer가 생성한 최신 Offset의 차이가 바로 Consumer Lag이다.
6. Consumer 확장과 한계
Kafka에서 Consumer를 늘린다고 무조건 처리량이 세 배, 네 배 증가하지는 않는다.
Consumer 확장성에는 명확한 제약이 있다.
제약 1: Partition 수 ≥ Consumer 수
Consumer 하나는 한 순간에 하나의 Partition만 담당할 수 있다.
따라서 Partition이 10개면 Consumer도 최대 10개까지만 병렬 처리 가능하다.
제약 2: Partition보다 Consumer 수가 많으면?
- 초과 Consumer들은 Idle 상태가 되며, Poll을 하지 않는다.
- 즉, Consumer는 Partition 수 만큼만 유효하게 동작한다.
제약 3: 너무 많은 Consumer는 Rebalance 비용 증가
Consumer가 늘어나면 Rebalance 시간이 비례해 늘어난다.
대규모 환경에서는 Rebalance가 장애처럼 느껴질 수 있다.
실무 팁
대부분 회사에서는 Partition 수를 다음 기준으로 정한다:
- Consumer 한 대 처리량 * Consumer 수 = 목표 처리량
- Partition 수는 Consumer 수보다 약간 많게
7. GroupCoordinator / Heartbeat 구조
Consumer Group에는 “그룹을 관리하는 중앙 관리자”가 필요하다.
Kafka는 이 역할을 GroupCoordinator에게 맡긴다.
GroupCoordinator 역할
- Consumer Group의 메타데이터 관리
- 어떤 Consumer가 어떤 Group에 참여 중인지
- 어떤 Consumer가 살아 있는지/죽었는지
- Partition–Consumer 매핑 정보 유지
- Consumer Join/Leave 이벤트 처리
- 새로운 Consumer 등록
- Group의 ‘leader consumer’를 다시 선출할지 여부 판단
- 필요한 경우 Rebalance 트리거
- Partition assignment 전달
- commit한 Offset 저장 관리(__consumer_offsets)
- Heartbeat 감시하여 Failover 처리
- 모든 Consumer는 Coordinator에게 정기적으로 heartbeat를 보낸다.
GroupCoordinator는 어디에 존재하는가 ?
Kafka Broker 중 하나가 자동으로 특정 Consumer Group의 Coordinator 역할을 맡는다.
- Consumer Group ID → 내부 알고리즘으로 hash
- hash 값을 특정 Broker에 매핑
- 그 Broker가 해당 Group의 Coordinator가 됨
Heartbeat는 왜 중요한가?
Consumer는 poll()과 별개로 Heartbeat를 정기적으로 보내 “나 아직 살아있다”를 Coordinator에게 알린다.
Heartbeat가 끊기면?
- Coordinator는 해당 Consumer를 죽은 것으로 판단
- 즉시 Rebalance 발생
- Partition은 다른 Consumer에게 재배정
Heartbeat가 느리면 Rebalance가 과도하게 발생할 수 있으므로 Consumer 애플리케이션에서 poll/처리 시간을 적절히 조절해야 한다.
8. 정리
Consumer Group은 Kafka의 핵심이자 가장 섬세한 구성 요소다.
그 역할은 단순히 “여러 Consumer가 메시지를 나눠 읽는 것”에 그치지 않는다.
핵심 요약
- Consumer Group은 Partition–Consumer 1:1 매핑을 보장
- Assignment 방식은 Range / Round Robin / Sticky
- Rebalance는 Join → Leader 선출 → Assignment → Sync 흐름
- Failover는 Heartbeat 기반으로 자동 처리
- Lag는 Consumer 성능 병목을 나타내는 핵심 지표
- Consumer 수는 Partition 수 이상의 스케일 아웃 불가
- GroupCoordinator가 Commit, Rebalance, Heartbeat를 관리
이 구조를 명확히 이해하면 Kafka의 메시지 처리 속도, 중복, 유실, Failover, Lag 원인을 대부분 설명할 수 있다.
참고문헌
https://ibm-cloud-architecture.github.io/refarch-eda/technology/kafka-consumers/
