Kafka는 이벤트(메시지)를 디스크의 추가 전용 로그(append-only log)에 쌓아 두고, 여러 소비자가 각자 읽은 위치를 기억하며 꺼내 가게 하는 분산 이벤트 스트리밍 플랫폼(distributed event streaming platform)이다. 흔히 메시지 큐(message queue)라고 부르지만 동작은 큐보다 로그에 가깝다.
큐와 로그의 차이
- 일반적인 큐(RabbitMQ 등)는 소비하면 메시지가 사라진다. 우체통에서 편지를 꺼내는 식이다
- Kafka는 읽어도 지우지 않는다. 보관 기간(예: 7일) 동안 남고, 소비자는 자기가 읽은 위치(offset)만 기록한다
- 그래서 같은 이벤트를 검색 색인·알림·정산 서비스가 각자의 속도로 독립적으로 읽을 수 있고, offset을 되감아 다시 처리(replay)할 수도 있다
topic: order-events, partition 0
offset 0 1 2 3 4
[생성] [수정] [취소] [생성] [수정]
▲ ▲
검색 서비스 위치 정산 서비스 위치용어
- producer / consumer: 이벤트를 쓰는 쪽 / 읽는 쪽. 서로를 몰라도 된다
- topic: 이벤트 분류 채널. 실제로는 여러 partition으로 나뉜다
- partition: 병렬 처리와 순서 보장의 단위. 순서는 같은 파티션 안에서만 보장되므로, 주문 ID 같은 키로 파티션을 정해 같은 엔티티의 이벤트 순서를 지킨다
- consumer group: 같은 그룹의 소비자들이 파티션을 나눠 맡아 처리량을 늘린다. 다른 그룹은 같은 이벤트를 따로 받는다
- broker: Kafka 서버. 최신 버전은 ZooKeeper 없이 KRaft 모드로 메타데이터를 스스로 관리한다(2026 기준)
왜 쓰나
- 느슨한 결합(loose coupling): 주문 서비스는 "주문 생성됨"을 던지고 끝낸다. 새 구독자가 생겨도 보내는 쪽 코드는 그대로다(옵저버 패턴의 분산판)
- 장애 격리·버퍼: 소비자가 잠시 죽어도 이벤트는 쌓여 있다가 멈춘 offset부터 이어 처리된다
- 재처리: 버그를 고친 뒤 과거부터 다시 읽어 검색 인덱스를 통째로 재구축할 수 있다
주의
기본 전달 보장은 보통 at-least-once(최소 한 번 전달)다. 같은 이벤트가 두 번 올 수 있으므로 소비자는 멱등하게 만든다. DB 변경을 Kafka로 내보낼 때는 CDC (변경 데이터 캡처)나 트랜잭셔널 아웃박스 패턴로 이중 쓰기(dual write) 문제를 피한다. 도커에서 띄울 때의 단골 함정은 Kafka advertised listeners 함정다. 저장소들의 역할 분담은 저장소 역할 분담 (DB·캐시·큐·검색)를 본다.