12/29

🔹 Kafka 자세히 알아보기

Kafka는 단순한 메시지 큐가 아니라 분산 로그 시스템이다.
그래서 내부 구성요소들이 “고성능 · 장애복구 · 확장성”을 중심으로 설계되어 있다.

---

🔹 Broker (브로커)

🔸 정의

• Kafka 서버 한 대
• 메시지를 저장하고 전달하는 역할
• 여러 Broker가 모여 Kafka Cluster를 구성

🔸 Broker의 핵심 책임

기능	설명
메시지 저장	Topic → Partition 단위로 디스크에 로그 저장
Producer 요청 처리	메시지 수신
Consumer 요청 처리	메시지 전달
Replica 관리	다른 Broker와 데이터 복제

📌 중요 포인트

• Kafka는 메모리 큐가 아니라 디스크 로그
• Broker 장애 시에도 데이터 유지 가능

---

🔹 Topic & Partition

🔸 Topic

• 메시지의 논리적 분류 단위
• 예: order-created, payment-completed

🔸 Partition

• Topic을 쪼갠 물리적 단위
• 병렬 처리와 확장성을 담당

🔸 핵심 특징

항목	설명
순서 보장	Partition 내부에서만 순서 보장
병렬 처리	Partition 수만큼 Consumer 병렬 처리 가능
확장성	Partition 증가 = 처리량 증가

📌 실무 핵심

• Kafka에서 성능 = Partition 수
• 단, Partition 늘리면 순서 보장 범위는 더 좁아짐

---

🔹 Replica & ISR (복제와 장애 복구)

🔸 Replica

• Partition의 복사본
• 여러 Broker에 분산 저장

🔸 Leader / Follower

역할	설명
Leader	Producer/Consumer와 직접 통신
Follower	Leader 데이터를 복제

🔸 ISR (In-Sync Replicas)

• Leader와 동기화 상태인 Replica 집합
• ISR에 속한 Replica만 Leader 승격 가능

📌 왜 중요한가?

• Leader Broker 장애 → ISR 중 하나가 즉시 Leader 승격
• 데이터 유실 없이 서비스 지속 가능

---

🔹 Controller (클러스터의 두뇌)

🔸 정의

• Kafka Cluster에서 단 하나만 존재
• Broker 중 하나가 Controller 역할 수행

🔸 Controller의 역할

기능	설명
Broker 상태 관리	Broker 다운/복구 감지
Leader 선출	Partition Leader 재선출
ISR 관리	Replica 동기화 상태 관리
메타데이터 관리	Topic, Partition 정보 유지

📌 Controller 장애 시

• 다른 Broker가 자동으로 Controller 승격
• 서비스 중단 없음

---

🔹 Zookeeper vs KRaft (RAFT 기반)

🔸 과거: Zookeeper 기반

Zookeeper가 담당했던 것

• Broker 등록
• Controller 선출
• Topic / Partition 메타데이터 저장

❌ 문제점

• 운영 복잡도 ↑
• Kafka + Zookeeper 이중 관리
• 확장성 한계

🔸 현재/미래: KRaft (Kafka Raft)

Kafka 2.8+부터 도입된 Zookeeper 제거 아키텍처

항목	Zookeeper	KRaft
메타데이터 저장	Zookeeper	Kafka 내부
합의 알고리즘	ZAB	RAFT
운영 복잡도	높음	낮음
장애 포인트	2개	1개

📌 실무 기준

• 신규 Kafka 클러스터 → KRaft 권장
• 기존 운영 중 → 점진적 마이그레이션 고려

---

🔹 Producer → Broker 내부 흐름

1. Producer가 메시지 전송
2. Partition Leader가 메시지 저장
3. Follower Replica들이 복제
4. acks 설정에 따라 Producer 응답

🔸 acks 옵션

값	의미
acks=0	저장 확인 안 함 (빠르나 위험)
acks=1	Leader 저장만 확인
acks=all	ISR 전체 저장 확인 (가장 안전)

---

🔹 Consumer Group 내부 동작

🔸 Consumer Group

• 같은 Group ID를 가진 Consumer 묶음
• Partition은 Group 내에서 1 Consumer만 처리

🔸 Rebalance

• Consumer 추가/제거 시
• Partition 재분배 발생

📌 주의

• Rebalance 동안 메시지 소비 일시 중단
• Consumer 설계 시 처리 시간 최소화 중요

---

🔹 전체 구조 요약

[Producer]
     ↓
[Partition Leader (Broker)]
     ↓ (Replica)
[Follower Broker]
     ↓
[Consumer Group]

구성요소	핵심 역할
Broker	메시지 저장 & 전달
Partition	성능 & 순서 단위
Replica / ISR	장애 복구
Controller	클러스터 제어
KRaft	메타데이터 합의

---

🔹 실무에서 꼭 기억할 포인트

1. Kafka = 분산 로그 시스템
2. 성능 튜닝의 핵심은 Partition 설계
3. 장애 대응은 Replica + ISR
4. 최신 Kafka는 Zookeeper 제거(KRaft) 방향
5. 이벤트 기반 아키텍처의 핵심 인프라