
"Kafka Cluster", 왜 필요할까?
대규모 데이터를 실시간으로 처리하려면 어떤 시스템이 필요할까요?
바로 Kafka예요.
Kafka는 분산 이벤트 스트리밍 플랫폼으로, 고성능과 확장성, 그리고 안정성을 바탕으로 대량의 데이터를 처리할 수 있게 도와줘요.
우리 프로젝트에서도 여러 서비스 간에 이벤트를 주고받고, 이를 안전하게 처리하기 위해 Kafka를 활용하고 있어요.
이번 글에서는 Kafka의 구조와 핵심 개념들을 차근차근 살펴볼게요.
Producer와 Consumer

Kafka의 기본 개념부터 볼까요?
- Producer(프로듀서): 데이터를 생산해서 Kafka로 전송하는 주체예요.
- Consumer(컨슈머): Kafka에 쌓인 데이터를 구독해서 처리하는 주체예요.
원래는 Producer가 Consumer에게 직접 데이터를 전송하는 방식(API 호출)으로도 가능해요. 하지만 이 경우 Consumer에 장애가 생기면 Producer도 영향을 받아 데이터 유실이 발생할 수 있어요. 그래서 중간에 메시지 큐(Message Queue) 같은 시스템을 두는 방식이 발전했어요.

메시지 브로커와 Pub/Sub 구조

Producer와 Consumer 사이에 메시지 브로커를 두면 구조가 훨씬 안정적이에요.
브로커가 여러 메시지 큐를 관리하면서 데이터를 분산 처리해주고, Consumer는 필요할 때 스스로 데이터를 가져오는(Pull) 방식으로 안정성을 높일 수 있어요.
이때 데이터 전송 방식은 Pub/Sub(발행/구독) 패턴을 따라요.
- Producer는 데이터를 발행(publish)하고,
- Consumer는 필요한 토픽을 구독(subscribe)해서 데이터를 읽어가요.
Kafka의 등장
그렇다면 이런 시스템을 우리가 직접 만들 수 있을까요?
가능하긴 하지만, 안정성·성능·확장성을 모두 보장하는 분산 시스템을 직접 구축하는 건 쉽지 않아요. 그래서 이미 잘 만들어진 솔루션인 Kafka를 사용하는 거예요.
Kafka에서는 Producer와 Consumer 사이에서 Broker가 데이터를 중개하고 처리해요.
여러 대의 Broker가 모이면 Kafka Cluster가 되고, 이를 통해 대규모 데이터를 병렬로 안전하게 다룰 수 있어요.
Topic과 Partition

Kafka에서 데이터는 Topic 단위로 구분돼요. 예를 들어:
- 게시글 이벤트 → article-topic
- 댓글 이벤트 → comment-topic
- 좋아요 이벤트 → like-topic
각 Topic은 다시 Partition으로 나눠져 여러 Broker에 분산 저장돼요. Partition은 순차적으로 데이터가 기록되는 단위라서 한 Partition 내에서는 순서가 보장돼요. 하지만 Partition 간에는 순서가 보장되지 않기 때문에, 순서를 맞춰야 하는 이벤트라면 같은 Partition으로 모아야 해요.
데이터 안전성: Replication과 Acks
Kafka는 장애 상황에서도 데이터가 안전하게 보존될 수 있도록 Replication(복제) 기능을 제공해요.
예를 들어 Replication Factor를 3으로 설정하면, 한 Partition의 데이터가 세 개의 Broker에 복제돼요. 한 Broker가 장애를 일으켜도 다른 Broker에 복제된 데이터를 기반으로 계속 서비스할 수 있어요.
또 Producer는 acks 설정을 통해 데이터 전송 확인 방식을 조절할 수 있어요.
- acks=0 → 확인하지 않음 (빠르지만 위험해요)
- acks=1 → Leader만 확인
- acks=all → Leader + 모든 Follower 확인 (가장 안전해요)
@Configuration
public class KafkaTopicConfig {
@Bean
public NewTopic articleTopic() {
return TopicBuilder.name("article-topic")
.partitions(6)
.replicas(3) // 복제 3
.build();
}
}
props.put(ProducerConfig.ACKS_CONFIG, "all"); // "0", "1", "all" 중 선택
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
producer:
acks: all # <= 가장 안전해요 (leader + ISR follower에 기록)
retries: 10
key-serializer: org.apache.kafka.common.serialization.StringSerializer
...
Offset과 Consumer Group
Consumer가 데이터를 어디까지 읽었는지 추적하기 위해 Kafka는 Offset이라는 개념을 사용해요. 각 데이터에는 고유한 Offset이 붙고, Consumer는 이 값을 기준으로 데이터를 이어서 읽어가요.
또한 Consumer는 Consumer Group 단위로 관리돼요.
- 하나의 Consumer Group에 속한 Consumer들은 데이터를 분담해서 읽고,
- 서로 다른 Consumer Group은 같은 데이터를 각자 독립적으로 소비할 수 있어요.
예를 들어,
- hot-article 서비스 Consumer Group은 인기글 분석을 위해 데이터를 소비하고,
- article-read 서비스 Consumer Group은 조회 최적화를 위해 같은 데이터를 따로 소비할 수 있어요.
메타데이터 관리: Zookeeper와 KRaft
Kafka는 Broker, Topic, Partition, Offset 같은 메타데이터를 관리해야 해요. 예전에는 Zookeeper라는 별도 시스템이 이를 관리했지만, Kafka 2.8 이후부터는 KRaft 모드를 통해 Broker 자체에서 메타데이터를 관리할 수 있게 되었어요.
저는 로컬 환경에서 KRaft 모드를 활용해 간단히 구성할 거예요.
정리
Kafka를 통해 우리는 대규모 데이터를 고성능·안전성·확장성 있게 처리할 수 있어요.
마지막으로 핵심 개념들을 정리해볼게요.
Producer: 데이터를 Kafka로 보내는 클라이언트
Consumer: Kafka에서 데이터를 읽는 클라이언트
Broker: 데이터를 중개하고 처리하는 실행 단위
Cluster: 여러 Broker가 모인 분산 시스템
Topic: 데이터를 구분하는 논리적 단위
Partition: Topic을 나눠 병렬로 처리하는 단위
Offset: Partition 내 데이터의 고유한 위치
Consumer Group: Consumer들이 그룹 단위로 데이터를 나누어 처리하는 방식
Kafka는 단순한 메시지 큐를 넘어서, 안정성과 확장성이 뛰어난 분산 이벤트 스트리밍 플랫폼이에요.
앞으로 프로젝트에서 Kafka를 활용하면서, 이런 개념들이 실무에서 어떻게 적용되는지 직접 경험해보면 더 확실하게 이해할 수 있을 거예요.
'SpringBoot' 카테고리의 다른 글
| [Spring Batch] Tasklet vs Chunk 간단 정리 (0) | 2025.12.15 |
|---|---|
| Kafka를 이용해서 인기글 서비스를 어떻게 구현할 수 있을까? (0) | 2025.08.20 |
| Swagger를 사용해서 쉽게 api명세서를 만들어보자! (2) | 2024.12.01 |
| Springboot에서 SMTP(google)를 통해 인증번호를 보내보자! (1) | 2024.11.29 |
| JWT, Redis를 활용하여 RefreshToken을 관리해보자! (0) | 2024.11.27 |