카프카(Kafka)란 무엇인가?

 

 

 

1 | Kafka의 등장 배경과 진화

LinkedIn은 2010년, 웹·앱에서 쏟아지는 클릭·조회·검색 이벤트를 실시간으로 수집·분석할 전용 로그 파이프라인이 필요했습니다. Jay Kreps, Neha Narkhede, Jun Rao 세 엔지니어가 이 문제를 해결하려고 사내 프로젝트로 Kafka를 만들었고, 2011년 초 아파치 2.0 라이선스로 공개했습니다.
오늘날 Kafka는 Fortune 100 기업의 80% 이상이 사용하며 데이터 파이프라인·마이크로서비스 통신·스트리밍 분석의 사실상 표준으로 자리잡았습니다.

ZooKeeper 의존성 제거: KRaft 모드

장기간 메타데이터 저장소로 ZooKeeper를 써왔지만, 2023–24년 KIP-500(“KRaft”)이 도입되면서 브로커가 Raft 합의 알고리즘으로 스스로 메타데이터를 관리하도록 진화했습니다. 운영자는 ZooKeeper 없이 클러스터를 구성해 단일 스택으로 배포 복잡도를 줄일 수 있습니다.

---

2 | Kafka란 무엇인가? — 정의와 특징

Apache Kafka는 “오픈소스 분산 이벤트 스트리밍 플랫폼”입니다. 즉, 대규모 이벤트(로그·센서 데이터·도메인 이벤트)를 발행(Publish)–구독(Subscribe) 방식으로 받아들이고, 장애 복원력·메시지 순서·확장성을 보장하며, 장기간 메시지를 저장해 ‘데이터 레이크’ 역할까지 수행합니다.
Kafka의 설계 철학은 다음과 같습니다.

1. 분산·샤딩 — 토픽을 파티션으로 분할해 다수 브로커에 분산 저장, 선형 확장.
2. 기록(log) 지향 — 메시지가 파티션 로그 파일에 순차 기록되고 삭제 시점(retention)을 넘어설 때까지 유지.
3. 오프셋 기반 재처리 — 소비자가 읽은 위치를 오프셋 숫자로 기억·제어해, 장애나 신규 기능 배포 시 중복·재처리가 쉬움. 
4. 고가용성 — 파티션을 여러 브로커에 복제해 한 노드가 내려가도 데이터 손실 없음.

---

3 | Kafka 핵심 용어 해설

용어 정의 핵심 포인트

브로커 (Broker)	Kafka 클러스터를 구성하는 개별 서버 프로세스. 토픽·파티션 데이터를 실제로 저장하고, 생산자·소비자 요청을 처리한다.	각 브로커는 고유 ID를 가지며, 모든 브로커가 메타데이터를 공유해 ‘어느 브로커가 어느 파티션을 가지는지’를 자동 관리합니다.
토픽 (Topic)	이벤트 로그의 ‘카테고리’ 또는 ‘채널’. 예: order-created, user-activity.	생산자는 토픽 단위로 메시지를 보냅니다. 소비자는 원하는 토픽을 구독해 스트림을 수신합니다.
파티션 (Partition)	토픽을 샤딩(sharding)한 물리적 로그 파일. 파티션 내부에서는 메시지 순서가 보장됩니다.	파티션 수를 늘리면 병렬 처리량을 높일 수 있으나, 파티션 간에는 순서를 보장하지 않습니다.
오프셋 (Offset)	파티션 내에서 메시지의 위치를 나타내는 0부터 시작하는 단조 증가 정수.	소비자가 ‘어디까지 읽었는지’를 표현해 장애 복구·재처리 시점을 제어합니다. 오프셋 3은 파티션마다 다른 메시지를 의미합니다.

추가 용어
프로듀서(Producer) — 메시지를 토픽에 발행.
컨슈머(Consumer) — 토픽(혹은 파티션)을 읽어 가공·저장.
컨슈머 그룹 — 컨슈머 집합이 토픽 파티션을 나눠 읽어 병렬 처리.

---

4 | 쉬운 예시: “푸드 딜리버리” 서비스로 보는 Kafka 흐름

시나리오
① 고객 앱이 주문을 생성하면 프로듀서가 orders 토픽에 JSON 메시지를 전송합니다.
② orders 토픽은 4 개의 파티션으로 구성돼 있어 브로커 3대에 분산 기록됩니다.
③ order-service 컨슈머 그룹은 파티션을 하나씩 맡아 실시간 주문 상태를 DB에 반영합니다.
④ analytics-service 컨슈머 그룹은 같은 토픽을 다른 오프셋 위치부터 읽어 매출 대시보드를 계산합니다.
⑤ 서비스 장애가 발생해도 컨슈머는 마지막 커밋된 오프셋부터 재시작하여 데이터 손실 없이 이어집니다.

이처럼 Kafka는 **“한 번 적고(Write-once), 필요할 때마다 읽는다(Read-many)”**는 로그 개념으로, 다중 서비스 간의 데이터 흐름을 느슨하게 결합·확장 가능한 구조로 바꿔줍니다. 메시지가 소비된 후에도 로그에서 곧바로 사라지지 않으므로, 분석·백필(back-fill)·재처리 요구에 즉시 대응할 수 있습니다.