☄ Kafka 핵심 개념과 데이터 스트림 구조

1️⃣ Kafka란 무엇인가?

Apache Kafka는 대규모 실시간 데이터 스트리밍 플랫폼이다.
로그, 센서, 거래, 이벤트 등 다양한 소스로부터 들어오는 데이터를
토픽(topic) 단위로 모아 처리·저장·전송한다.

📊 Kafka의 역할

구성요소	역할
Producer	데이터를 Kafka로 전송
Broker	메시지를 저장·복제·분배
Consumer	Kafka에서 데이터를 읽어 처리
Topic	메시지의 논리적 분류 단위 (테이블 개념 유사)
Partition	토픽 내 병렬 처리 단위
Offset	각 파티션 내 메시지의 순서 번호

💡 Kafka = 분산형 커밋 로그(distributed commit log)
→ 데이터를 “추가만 가능(append-only)”한 불변 로그로 저장한다.

---

2️⃣ Topic: Kafka의 기본 단위

Kafka의 모든 데이터는 토픽(Topic) 안에 저장된다.
토픽은 데이터베이스의 테이블(table) 과 유사하지만,
스키마나 제약 조건 없이 자유롭게 데이터를 보낼 수 있다.

예시 토픽들:
logs, purchases, twitter_tweets, trucks_gps

• 각 토픽은 데이터 스트림을 나타낸다.
• 토픽 이름으로 클러스터 내에서 식별된다.
• 토픽은 원하는 만큼 생성 가능하다.
• 데이터 형식은 제한이 없다. (JSON, Avro, Binary 등 가능)

✅ 중요: Kafka 토픽은 읽기 전용이 아니다.
데이터를 “추가”할 수는 있지만, 수정이나 삭제는 불가하다.

---

3️⃣ Partition: 병렬성과 순서를 보장하는 핵심 단위

토픽은 내부적으로 여러 개의 파티션(partition) 으로 나뉜다.
각 파티션은 순차적으로 증가하는 오프셋(offset) 을 가진 메시지들의 집합이다.

📘 파티션 구조 예시

Topic: trucks_gps
 ├── Partition 0 → offset 0, 1, 2, ...
 ├── Partition 1 → offset 0, 1, 2, ...
 └── Partition 2 → offset 0, 1, 2, ...

• 파티션 단위로 병렬 처리 가능 → 확장성 확보
• 각 파티션 내에서는 순서(order) 가 보장된다.
• 다른 파티션 간에는 순서가 보장되지 않는다.

💡 Offset

• 각 파티션의 메시지마다 고유한 번호
• 오프셋은 파티션마다 독립적이다
• 컨슈머는 이 오프셋을 기억하고 다음 메시지를 이어서 읽는다

---

4️⃣ Producer: 데이터를 보내는 주체

Kafka 프로듀서(Producer) 는 데이터를 토픽의 특정 파티션으로 전송한다.
메시지의 위치를 결정하는 주체는 Kafka가 아니라 프로듀서다.

📘 파티션 결정 방식

방식	설명
키 없음 (null key)	라운드 로빈 방식으로 모든 파티션에 분산
키 있음 (keyed)	동일한 키는 항상 같은 파티션으로 전달 (해시 기반)

💡 예시

• truck_id 를 키로 지정하면 해당 트럭의 모든 위치 정보가 같은 파티션에 저장된다.
• 키가 없으면 데이터가 균등하게 분산되어 부하 분산 효과를 얻는다.

📦 Kafka 메시지 구성

항목	설명
Key	파티션 할당 기준 (선택사항)
Value	실제 데이터 내용
Headers	부가 정보 (선택사항)
Partition	메시지가 저장될 위치
Offset	메시지 순서 번호
Timestamp	생성 시간

💾 직렬화 (Serialization)
Kafka는 데이터를 바이트 형태로 주고받는다.
따라서 프로듀서는 메시지 키와 값을 Serializer 를 이용해 변환해야 한다.

예시:

key.serializer = org.apache.kafka.common.serialization.StringSerializer
value.serializer = org.apache.kafka.common.serialization.JsonSerializer

---

5️⃣ Consumer: 데이터를 읽는 주체

컨슈머(Consumer) 는 Kafka에서 메시지를 읽어 처리한다.
Kafka는 Push 모델이 아닌 Pull 모델을 사용한다.

즉, 컨슈머가 직접 데이터를 요청해야 한다.

📘 컨슈머 동작 방식

1. 컨슈머가 브로커에 요청(pull)을 보냄
2. 브로커는 요청한 오프셋부터 데이터를 전달
3. 컨슈머는 메시지를 처리 후 오프셋을 “커밋(commit)”

💡 Deserializer

• Kafka는 메시지를 바이트로 전달하므로,
  컨슈머는 이를 다시 객체로 복원해야 한다.
• Key, Value 각각에 Deserializer 지정 필요.

예시:

key.deserializer = org.apache.kafka.common.serialization.StringDeserializer
value.deserializer = org.apache.kafka.common.serialization.JsonDeserializer

---

6️⃣ Consumer Group: 확장성과 내결함성의 핵심

여러 컨슈머를 하나의 그룹(Consumer Group) 으로 묶으면
Kafka는 파티션을 자동으로 분배해 병렬 처리를 수행한다.

📘 예시

Topic-A (5 partitions)
Consumer Group A:
  - C1 → Partition 0, 1
  - C2 → Partition 2, 3
  - C3 → Partition 4

• 각 파티션은 그룹 내에서 하나의 컨슈머만 접근 가능
• 그룹 간에는 독립적으로 동일 토픽을 소비 가능

💡 컨슈머 오프셋 관리

• Kafka 내부 토픽 __consumer_offsets 에 저장
• 컨슈머는 오프셋을 커밋하여 “어디까지 읽었는가”를 기록
• 장애 시 재시작해도 중단 지점부터 다시 읽기 가능

📎 전달 보장 모드

모드	설명
At most once	빠르지만 일부 데이터 유실 가능
At least once	기본값, 중복 가능하지만 안전
Exactly once	중복·유실 모두 없음 (트랜잭션 기반)

---

7️⃣ Broker와 Cluster 구조

Kafka는 여러 브로커(Broker) 가 모여 클러스터를 이룬다.
각 브로커는 데이터를 분산 저장하며, 클러스터 전체가 하나의 Kafka 시스템으로 동작한다.

📘 브로커 특징

• 각 브로커는 고유 ID 로 구분된다.
• 브로커는 클러스터 메타데이터(토픽, 파티션, 리더 정보)를 공유한다.
• 부트스트랩 서버(bootstrap server) 로서
  클라이언트는 브로커 한 곳에만 연결해도 전체 클러스터를 인식할 수 있다.

💡 예시

Cluster
 ├── Broker 101 → Partition 0, 1
 ├── Broker 102 → Partition 2
 └── Broker 103 → Partition 3

---

8️⃣ 복제(Replication)와 내결함성

Kafka는 복제 계수(replication factor) 를 통해
데이터의 내구성과 가용성을 보장한다.

📘 개념 요약

항목	설명
Leader Replica	쓰기/읽기 요청 담당
Follower Replica	리더를 복제하며 대기
ISR (In-Sync Replica)	리더와 완전히 동기화된 레플리카
Replication Factor = 3	동일 데이터가 3개 브로커에 저장됨

💡 프로듀서 ACK 옵션

설정	의미
acks=0	응답 대기 없음, 유실 가능
acks=1	리더만 확인
acks=all	모든 ISR이 확인 후 성공 응답 (가장 안전)

✅ 원칙: 복제 계수가 N이면,
최대 N−1개의 브로커가 중단되어도 데이터는 유지된다.

---

9️⃣ Zookeeper와 KRaft

🦓 Zookeeper (기존 구조)

• Kafka 2.x까지 필수 구성 요소
• 브로커 등록, 메타데이터 관리, 리더 선출 담당
• 3개 이상의 서버(quorum) 구성 필요

⚡ KRaft (Kafka Raft Mode)

• Kafka 3.x부터 Zookeeper 없이 독립 동작
• KIP-500 제안으로 개발됨
• 메타데이터 관리와 리더 선출을 Kafka 내부에서 처리
• 단일 보안 모델, 빠른 복구, 확장성 개선

💡 정리

항목	Zookeeper	KRaft
관리 주체	외부 주키퍼 서버	Kafka 내부 컨트롤러
필요 버전	2.x	3.3.1+ (프로덕션 안정화)
복구 시간	느림	빠름
아키텍처 복잡도	높음	단순

---

🔟 핵심 요약

항목	설명
Topic	메시지를 저장하는 논리 단위
Partition	병렬성과 순서를 위한 분할 단위
Offset	각 파티션 내 메시지 순번
Producer	메시지 전송 주체, 직렬화 필요
Consumer	메시지 수신 주체, 역직렬화 필요
Consumer Group	병렬 소비 및 확장성 제공
Broker	클러스터 내 데이터 저장 서버
Replication	데이터 내구성 보장
Zookeeper / KRaft	클러스터 관리 및 리더 선출 담당

---

💬 결론

Kafka는 단순한 메시지 큐를 넘어
“데이터 스트림의 운영 체계(Data Streaming OS)” 로 진화했다.

Topic–Partition–Offset 구조로 확장성과 순서를 보장하며,
Producer–Consumer 모델로 안정적 데이터 파이프라인을 구축한다.
Zookeeper에서 KRaft로 전환하며,
Kafka는 더욱 단순하고 안정적인 분산 시스템으로 발전하고 있다.