Kafka 개념 이해하기

Kafka

---

Kafka는 대규모 실시간 데이터 스트리밍을 위한 분산 메시징 시스템이다. 데이터를 생산자(Producer) 가 보내면 Kafka가 이를 토픽(Topic) 단위로 저장하고, 필요한 소비자(Consumer) 가 가져가서 처리하는 시스템으로 보면 된다.

출처: https://aws.amazon.com/ko/what-is/apache-kafka/

대기열 및 게시/구독(PubSub)방식을 통해 분산 메시징/스트리밍을 수행

---

Kafka 구성 요소

구성 요소	설명
Producer	데이터를 Kafka에 전송하는 역할. 예: 서버 로그, 센서 데이터, 애플리케이션 이벤트
Topic	데이터를 분류하는 단위. 스트림을 분리해서 저장하고 구독 가능
Broker	Kafka 서버 한 대. 여러 개의 브로커가 모여 클러스터를 이룸
Consumer	Topic으로부터 데이터를 구독해서 처리하는 애플리케이션
Zookeeper	(기존 구조에서) 클러스터 상태를 관리하던 서비스 (현재는 KRaft로 대체 추세)
Partition	Topic 내 데이터를 분산 저장하는 단위. 병렬성 향상 가능
Offset	Partition 내에서 메시지의 순서를 나타내는 번호

---

Kafka = 이벤트 브로커 + 분산 로그 저장소

1. 이벤트 브로커(Event Broker) 역할

• Event: 시스템에서 발생한 상태 변화나 행동을 나타내는 기록
• Broker: Producer–Consumer 사이의 중개자 — 서로 다른 기술 스택이어도 문제없이 메시지 전달

이벤트 브로커는 시스템에서 발생하는 이벤트를 수집해 다양한 소비자에게 비동기로 전달하는 중간 계층이다. Kafka는 이러한 이벤트를 append‑only log 형태로 저장하므로, offset(이벤트 순번)을 이용해 원하는 지점부터 재처리할 수 있다.

장점	설명
비동기 처리	시스템 간 강한 결합 없이 느슨한 연동 가능
확장성	이벤트를 기반으로 마이크로서비스 확장 가능
복구 및 리플레이	이전 이벤트를 다시 읽어서 재처리 가능
분산 처리 지원	여러 Consumer가 병렬로 이벤트 처리 가능
실시간 스트리밍	이벤트 흐름을 기반으로 실시간 분석 가능

2. 분산 로그 저장소(Distributed Log Store)

전송되는 데이터량이 커질수록 하나의 서버에 로그를 저장하면 저장 공간·처리 속도에 한계가 생긴다. Kafka는 Topic을 여러 Partition으로 나누고, 각 Partition을 여러 Broker에 분산 저장해 이 문제를 해결한다.

---

Kafka vs. RabbitMQ vs. Redis Pub/Sub

항목	Kafka	RabbitMQ	Redis Pub/Sub
설계 목적	대용량 이벤트 스트리밍 & 로그 저장	신뢰성 있는 작업 큐, 시스템 간 비동기 메시지 전달	초경량 실시간 브로드캐스트 통신
메시지 저장 방식	디스크 기반 로그 저장 (Append‑only)	메모리+디스크 혼합, 큐에 보존	메모리 기반, 저장 없음
순서 보장	Partition 내 순서 보장, 전체 전역 순서 X	Queue 단위로 순서 보장 (FIFO)	순서 보장 없음
재처리 가능 여부	Offset 기반 재처리 가능	ack/nack 기반 재시도 지원	불가능 (소비자가 없으면 손실)
라우팅 방식	key → partition (해시 기반 분산 라우팅)	Exchange → Queue (AMQP)	Channel 이름으로 단순 브로드캐스트
통신 방식	Pub/Sub + 로그 저장 (Consumer Group)	Queue + Worker (ack/nack)	Pub/Sub 브로드캐스트, 1:N 직접 전달
확장성	매우 뛰어남 (Partition & Broker 수평 확장)	중간 (클러스터 가능하나 구조 복잡)	낮음 (단일 노드 처리 한계)
처리량	수십 만 TPS 이상	수천 ~ 수만 TPS	수만 TPS 내외 (단일 서버)
사용 예시	실시간 로그/이벤트, 마이크로서비스 이벤트 브로커	비동기 작업 처리, 백엔드 큐잉	채팅, 실시간 알림, 테스트 메시징
장점	고내구성, 재처리, 대규모 스트리밍	신뢰성 높은 메시지 큐, 복잡한 라우팅 처리 가능	매우 가볍고 빠른 실시간 통신
단점	설정·운영 복잡, 순서 보장 제한	설정 복잡도, 대용량 스트리밍 부적합	메시지 손실 가능, 내구성 없음

---

라우팅 방식 상세 설명

1. Kafka: key % partition 수 해시값으로 Partition 선택 → 같은 Key는 항상 같은 Partition
2. RabbitMQ: Exchange → Binding rule → Queue
   • Fanout, direct, topic, headers 등 다양한 라우팅 지원
3. Redis: PUBLISH로 채널에 메시지 발행 → 해당 채널 구독자에게 즉시 전달

---

상황 별 적합성

상황	적합한 시스템	이유
실시간 대용량 로그 처리	Kafka	높은 처리량 + 재처리 + 저장
백엔드 작업 분배 (Job Queue)	RabbitMQ	ack·retry, 큐 기반 처리 최적
실시간 브로드캐스트 알림	Redis Pub/Sub	지연 낮고 간단 (다만 신뢰성 낮음)
이벤트 기반 마이크로서비스 통신	Kafka 또는 RabbitMQ	이벤트 흐름이면 Kafka, Command면 RabbitMQ
순서 중요 + 일부 재전송 필요	RabbitMQ	FIFO 큐 처리 가능
순서보다 처리량이 중요	Kafka	병렬 분산 처리 가능

---

Kafka 구성 요소 상세

1. Producer — Kafka로 데이터를 전송
   • 예: 웹 서버 로그, 사용자 클릭 이벤트
   • Topic 지정, Key로 Partition 분배 제어 가능
2. Topic — 데이터를 분류하는 논리적 채널
   • 예: user_events, order_events
   • 하나의 Topic은 여러 Partition으로 구성 → 병렬 처리 가능
3. Broker — Kafka 서버 한 대
   • 다수 Broker → 하나의 클러스터
   • 각 Broker가 특정 Partition 저장·처리
4. Consumer — Topic 데이터를 구독해 처리
   • 여러 Consumer → Consumer Group 구성
   • 장애 시 파티션 리밸런싱으로 재구독·재시작 가능
5. Zookeeper — 클러스터 상태 관리 (기존)
   • Topic·Partition·ACL 등의 메타데이터 관리
   • Kafka 2.8+ 부터는 KRaft 모드로 대체 가능
6. Partition — Topic 내부 데이터 샤드
   • Offset 순서대로 Append‑only 저장
   • Partition 수가 확장성·성능에 직접적인 영향
7. Offset — Partition 내 메시지 순번
   • 예: 0, 1, 2, ...
   • 원하는 Offset부터 읽어 재처리 가능
   • manual commit 또는 auto commit 방식 지원

---

Zookeeper → KRaft(Kafka Raft) 전환 이유

Zookeeper 문제점	설명
운영 복잡성	Kafka 외에 Zookeeper 클러스터 별도 운영 필요
장애 전파	Zookeeper 장애 시 Kafka 전체 영향
확장성 한계	고성능 분산 저장에 최적화되지 않음
동기화 문제	Kafka ↔ Zookeeper 간 데이터 동기화 지연 가능성
기능 분산	클러스터 조정 기능이 Kafka 외부에 위치

KRaft: Kafka + Raft

Raft는 분산 시스템에서 합의(Consensus) 를 이끄는 알고리즘이다. Kafka는 내부적으로 Raft를 이용해 메타데이터를 직접 관리한다.

역할	설명
메타데이터 저장소	Kafka 내부 Topic __cluster_metadata 에 메타데이터 저장
Controller 노드 선출	Raft로 Broker 중 리더(Controller) 자동 선출
브로커 등록/탈퇴 관리	클러스터 구성 Broker 추적
클러스터 설정 관리	Topic 설정 변경, 파티션 리밸런싱 등 처리
장애 복구	Raft 복제 로그 기반으로 일관성 있게 복원

---