Kafka

✅ Apache Kafka

실시간으로 스트리밍 데이터를 게시, 구독, 저장 및 처리할 수 있는 ' 분산형 데이터 스트리밍 플랫폼'

 

 

 

 

 

 

* 카프카는 요청 - 응답 구조가 감당 못하는 트래픽과 복잡도를 해결하려고 나왔다.

기존 에는 Client -> Controller -> Service -> DB

 

이 구조의 특징

요청 - 처리 - 응답이 한개의 흐름으로 되는데 실패하게되면 요청은 실패하고 사용자는 대기하고 재시도의 무한으로 빠지게된다.

 

이러한 문제점들을 해결하기 위해 나온게 Kafka인데

 

"지금 처리하지 못해도, 이벤트는 절대 잃지 않는다."

기존의 Spring Controller 는 한개의 흐름이 동기로되어 있어서 끝날때까지 기다려야된다.

 

Kafka는 이벤트 발생 - Kafka에 적재 (끝) 처리 책임을 비동기로 분리

 

 

✅ Kafka핵심개념

Producer : 이벤트를 보내는 역할

Consumer : 이벤트를 받는 역할

Topic : 이벤트를 저장하는역할 (DB가 아님)

 

항목Spring ControllerKafka

통신	HTTP	이벤트
방식	동기	비동기
결합도	높음	낮음
장애 영향	즉시 영향	격리 가능
재처리	어려움	가능
확장	서버 증설	Consumer 추가

 

 

“Controller/Service는 요청-응답 중심이라
복잡한 후처리와 장애 격리에 한계가 있다
Kafka는 이벤트를 영속화하고
Consumer로 처리 책임을 분리함으로써
확장성과 안정성을 확보한다.

 

 

 

예시로 이해

 

 

먼저 Kafka를 한 문장으로 바꾸자

Kafka = “이벤트를 종이에 적어서 통에 넣어두고,
사람들이 그 종이를 나눠서 읽는 시스템”

 

1️⃣ Kafka에서 제일 중요한 것: Topic

비유

Topic = 이벤트 통

예:

• user-event 통
• order-event 통

👉 “사용자 이벤트는 여기 넣어라”
👉 “주문 이벤트는 저기 넣어라”

 

 

2️⃣ Partition = 통 안의 줄 (레인)

비유

Partition = 통 안에 여러 줄로 나뉜 종이 줄

 

Topic: user-event [Partition 0] [Partition 1]

왜 줄을 나눌까?

👉 여러 사람이 동시에 읽게 하려고

---

Partition이 없으면?

 

[통 1개] 사람 1명만 읽음

→ 느림 😵

---

Partition이 있으면?

 

Partition 0 → 사람 A Partition 1 → 사람 B

→ 동시에 읽음 ⚡

---

중요한 포인트 (아주 중요)

Partition 안에서는 순서가 절대 안 깨진다

 

Partition 0: 0번 종이 1번 종이 2번 종이

 

 

 

 

3️⃣ Offset = 종이에 붙은 번호

비유

Offset = 줄에서 몇 번째 종이인지 번호

 

Partition 0: Offset 0 → 첫 번째 이벤트 Offset 1 → 두 번째 이벤트 Offset 2 → 세 번째 이벤트

---

Offset이 왜 필요할까?

상황

• 사람이 읽다가 졸아서 쓰러짐 😴
• 다시 돌아옴

👉 “어디까지 읽었더라?”

📌 Offset 보고 이어서 읽음

---

핵심

Offset 덕분에

• 중간부터 다시 읽을 수 있고
• 이벤트를 안 잃어버림

---

4️⃣ Consumer = 종이 읽는 사람

비유

Consumer = 통에서 종이 읽는 사람

예:

• 알림 보내는 사람
• 로그 저장하는 사람

---

Consumer는 이렇게 말한다

“나는 user-event 통을 읽을게”

---

5️⃣ Consumer Group = 같은 팀

여기서 대부분 헷갈린다. 천천히.

---

Consumer Group 비유

Consumer Group = 같은 목적의 팀

예:

• “주문 처리 팀”
• “로그 저장 팀”

---

예시 1️⃣: Consumer Group이 하나

 

Topic: user-event Partition 0 Partition 1 Group: event-group ├─ 사람 A └─ 사람 B

Kafka가 이렇게 나눠줌 👇

 

Partition 0 → 사람 A Partition 1 → 사람 B

👉 같은 팀에서는 나눠서 읽음

---

규칙 하나 (진짜 중요)

❗ 같은 Group 안에서는
하나의 Partition을
한 명만 읽는다

---

예시 2️⃣: Consumer가 하나 더 늘어나면?

 

Partition 2개 Consumer 3명

→ 1명은 놀고 있음 🫥

👉 Partition 수가 기준

---

6️⃣ Consumer Group이 다르면?

비유

팀이 다르면 같은 종이를 또 읽음

---

예시

 

Topic: user-event Group A (주문 처리) └─ Consumer A Group B (로그 저장) └─ Consumer B

👉 결과:

• 주문 처리 팀 → 모든 이벤트 읽음
• 로그 팀 → 모든 이벤트 읽음

📌 같은 이벤트를 “목적별”로 처리

---

7️⃣ 지금까지를 한 장면으로 정리

상황

• 버튼 클릭 이벤트 3개 발생

 

Topic: user-event Partition 0: Offset 0: 클릭 Offset 1: 클릭 Offset 2: 클릭

---

Consumer Group: event-group

 

Consumer 1 → Partition 0 Offset 0부터 읽음

• Offset 0 처리
• Offset 1 처리
• Offset 2 처리

---

중간에 죽었다가 다시 시작하면?

• 마지막 Offset = 1
• Offset 2부터 다시 읽음

👉 유실 없음

 

👉 “Kafka가 어떻게 살아있나”에 대한 설명

용어한 줄 정리

Kafka Cluster	Kafka 서버 여러 대 묶음
Broker	Kafka 서버 1대
ZooKeeper	Kafka 메타데이터 관리자
Producer	이벤트 보내는 쪽
Consumer	이벤트 받는 쪽

이건 인프라 / 운영 관점이야.

---

2️⃣ 우리가 앞에서 파던 개념은 뭐였냐면

👉 “Kafka가 어떻게 일을 나누고, 중복 없이 처리하나”

개념역할

Topic	이벤트 종류
Partition	병렬 처리 단위
Consumer Group	같은 목적의 처리 단위
Offset	어디까지 처리했는지