[개념정리] Kafka - Broker와 Consumer Group

Kafka 기본 개념을 정리했었다.

그 이후에 더 알아야 할 브로커와 컨슈머 그룹에 대한 자세한 내용을 정리하고자 한다.

 

❓ 브로커(Broker)란 무엇인가?

브로커는 메시지를 저장하는 Kafka 서버 (혹은 Kafka 프로세스)

Producer가 보낸 데이터는 Topic과 Partition 형태로 만들어져 브로커 내부에 저장된다.

 

브로커의 핵심 역할

• Producer가 보낸 메시지를 저장한다.
• Consumer가 메시지를 읽을 수 있도록 제공한다
• Topic 과 Partition의 파일 구조를 관리한다.

→ 브로커는 Kafka 메시지가 실제로 저장되는 창고 역할을 수행한다.

 

✅ Topic과 Partition은 브로커에서 어떻게 관리되는가?

Topic을 생성하면 브로커 내부에 Partition 디렉토리가 자동으로 만들어진다.

각 Partition 안에 메시지를 파일(log segment)로 저장한다.

 

Partition의 메시지 저장 규칙

Partition 안에서는 메시지가 순서대로만 쌓이고, Producer가 메시지를 보내면 항상 Partition의 끝에 순서대로 추가된다. 

또한 Partition 내부의 메시지 순서는 절대 변하지 않는다.

 

✅ Consumer Group이 필요한 이유

Consumer Group은 Kafka의 병렬 처리 기능을 제공하는 핵심 구조

 

Consumer Group의 필요성

• 메시지가 많아지면 Consumer 1개로는 처리 속도가 부족
• 여러 Consumer가 하나의 팀처럼 협업하여 처리해야 함
• Kafkasms Partition을 여러 Consumerd에게 나누어 제공하여 병렬 처리를 가능하게 한다

Kafka의 규칙에 따라 

Partition 하나는 Consumer Group내의 하나의 Consumer로 일대일로 할당되게 되며,

Consumer가 Partition보다 많아도 남는 Consumer는 대기 상태가 된다.

이를 통해 병렬 처리량의 상한선은 Partition의 수에 따라 결정된다고 볼 수 있다.

✅ Consumer Group별 Offset 관리 구조

Offset이란 ?

Partition 내부에서 메시지가 저장된 순서를 나타내는 번호

• Kafka는 메시지를 Partition의 끝에 차곡차곡 쌓아두는데
• Partition 안에 메시지가 저장될 때 메시지마다 자동으로 0,1,2,3 과 같은 번호(offset)이 붙게 된다.
• Offset은 해당 Partition 내에서만 유효하며, 다른 Partition에서는 별개로 관리된다.

Offset을 따로 관리하는 이유

Consumer Group은 메시지를 읽을 때 어디까지 읽었는지를 Kafka에 기록한다. 그 이유로는

• 중복해서 같은 메시지를 반복 처리하지 않도록
• 놓치는 메시지가 없도록
• 서버가 재시작되더라도 중단했던 위치부터 다시 읽을 수 있도록

Consumer Group이 Offset을 직접 관리하며, Partition 별로 Offset을 따로 관리한다.

이러한 구조로 인해 Kafka는 병렬 처리와 안정적인 메시지 소비가 모두 가능해짐

 

✅ 하나의 Topic을 여러 Consumer Group이 사용하는 구조

Kafka의 장점은 하나의 메시지를 여러 Consumer Group에서 서로 다른 목적에 따라 동시에 소비할 수 있다는 점

 

예시로, Category-click 이라는 Topic이 있는 상황이라고 보았을 때 이 Topic은

• 모든 카테고리 클릭 이벤트가 저장됨
• Producer는 이 데이터를 Kafka에 기록하기만 한다.
• Producer는 이 데이터를 누가, 어떻게 사용할지 신경쓰지 않는다
• 카테고리 클릭 데이터가 필요한 Consumer Group이 해당 데이터를 스스로 가져가서 처리한다.

또한 Consumer Group은 각각

 

Group A (추천 서비스 팀)

• 사용자 관심사 분석
• 추천 알고리즘 데이터 수집
• Offset: 3 까지 읽음

Group B (실시간 랭킹 팀)

• Redis Sorted Set 업데이트
• 최근 인기 카테고리 계산
• Offset: 5 까지 읽음

Group C (로그 저장 팀)

• 장기 보관용 스토리지 적재
• Offset: 1 까지 읽음

 

✅ Kafka에서 이루어지는 빠르고 안정적인 데이터 처리 구조

Kafka에서는 거의 실시간으로 대규모 데이터를 저장하고, 소비하는 상황이 진행된다.

이러한 대규모 처리가 간으한 이유는 데이터 생성자와 소비자의 역할이 명확하게 분리되어있고, 서로 간섭 없이 처리할 수 있도록 설계되어 있기 때문

 

역할을 다시 한 번 정리하자면

 

1. Producer는 이벤트가 발생할 때 마다 Topic에 메시지를 기록

• 이 데이터를 어떻게 사용할지는 Producer의 관심사가 아님
• Kafka에 메시지를 차곡차곡 저장함

2. Consumer는 관심있는 Topic을 보고 있다가, 원하는 데이터가 들어오면 처리

• 데이터가 어떻게 생성되는지는 Consumer의 관심사가 아님
• Kafka에 쌓인 메시지를 중복 없이, 누락 없이 처리하는데에만 집중하면 됨