Kafka 가 어울리는 자리
Kafka 가 어울리는 자리, 그렇지 않은 자리
Kafka 는 흔히 "큐" 로 불리지만 정확히 말하면 분산 커밋 로그입니다. 강점은 큐 이상의 자리에서 드러납니다. 동시에 단순한 작업 큐에는 과한 도구이기도 합니다.
1. Kafka 에 대한 이야기
Kafka 는 LinkedIn 에서 시작된 분산 메시지·로그 시스템입니다. 2010 년 사내 프로젝트로 출발해 2011 년 Apache Software Foundation 에 인큐베이션, 2012 년 톱-레벨 프로젝트가 됐습니다. 1.0 정식 릴리스는 2017 년입니다.
| 사건 | 시기 |
|---|---|
| 사내 개발 시작 (LinkedIn) | 2010 |
| Apache 인큐베이션 | 2011 |
| Apache 톱-레벨 프로젝트 | 2012 |
| Kafka Streams 도입 | 0.10 (2016) |
| Exactly-once semantics | 0.11 (2017) |
| 1.0 GA | 2017-11 |
| KRaft (ZooKeeper 제거 모드) | 3.3 (2022) |
| ZooKeeper 비-사용이 기본 옵션화 | 3.5+ |
설계 의도는 처음부터 "고처리량 · 디스크 추가만으로 보존 기간 연장 · 재처리 가능" 이었습니다. 큐의 일반화가 아니라 분산 로그의 발견이라고 표현되기도 합니다.
2. 토픽 · 파티션 · 컨슈머 그룹
- 토픽 (topic) — 메시지의 논리적 채널.
- 파티션 (partition) — 토픽을 분산·병렬로 다루기 위한 분할 단위. 파티션 안에서는 순서가 보장됩니다.
- 메시지 — 키·값·헤더·오프셋. 키 해시로 파티션이 결정되는 것이 흔합니다.
- 오프셋 (offset) — 파티션 안에서의 위치. 컨슈머가 자기 진행도를 기록합니다.
- 컨슈머 그룹 (consumer group) — 같은 그룹 안의 컨슈머들이 파티션을 나눠 가져갑니다. 한 파티션은 그룹 안에서 한 컨슈머에게만 할당됩니다.
이 모델 덕분에 같은 토픽을 다른 그룹이 각자의 진행도로 따로 읽을 수 있습니다. 큐의 "가져가면 사라진다" 와 다르게, Kafka 는 보존 기간이 다 되기 전까지 메시지가 디스크에 남습니다.
3. 보존 정책
- 시간 기반 (
retention.ms) — 예: 7 일. - 크기 기반 (
retention.bytes) — 예: 100 GB. - 압축 (
compaction) — 같은 키의 마지막 값만 남깁니다 — 키-값 스냅샷 토픽으로 활용.
4. 전달 보증
| 보증 | 구성 |
|---|---|
| at-most-once | producer 가 ack 미기다림 + 컨슈머 자동 커밋. 손실 가능. |
| at-least-once | 기본. ack=all + 수동 커밋. 중복 가능. |
| exactly-once | producer 의 idempotent + transactional + 컨슈머의 read-committed. Kafka 토픽 안에서만 성립. 외부 시스템 결합 시에는 멱등 컨슈머가 여전히 권장됩니다. |
acks (producer) · enable.idempotence · isolation.level (consumer) 가 핵심 설정입니다.
5. 스토리지 · 복제 · KRaft
각 파티션은 leader + followers 로 복제됩니다. replication.factor 가 보통 3. ISR (In-Sync Replicas) 안의 레플리카들이 leader 와 동기화된 상태입니다. leader 장애 시 ISR 중 하나가 새 leader 가 됩니다.
오랫동안 메타데이터 관리에 ZooKeeper 를 썼습니다. 2022 년부터 KRaft (Raft 합의 알고리즘 기반) 가 등장해 ZooKeeper 없이 Kafka 자체 노드만으로 운영이 가능해졌습니다. 운영 표면이 줄었다는 평가가 많습니다.
6. Kafka 가 강한 자리
- 이벤트 소싱 · CDC — 모든 변경의 보존·재생.
- 여러 컨슈머가 같은 스트림을 다른 속도로 읽는 자리 — 토픽 한 번 발행, 다중 그룹 소비.
- 고처리량 로그 수집 — 초당 수십만 메시지.
- 실시간 분석의 입구 — Flink · Spark Streaming · Kafka Streams.
- 메시지 보존을 통한 백필·재처리.
7. Kafka 가 과한 자리
- 단순한 작업 큐 (이메일 발송, 백그라운드 처리) — RabbitMQ · Redis · SQS 가 더 단순합니다.
- 짧은 TTL · 적은 처리량 — Kafka 의 운영 비용이 정당화되지 않습니다.
- 작업당 사람이 직접 보고 싶은 워크플로 — Airflow 계열이 어울립니다.
8. 다른 후보들
| 시스템 | 출자·시기 | 모델 | 메모 |
|---|---|---|---|
| RabbitMQ | 2007, AMQP 0-9-1 기반 | 큐·exchange·routing | 라우팅·라운드로빈·DLQ. 메시지 영속·보존 기간이 Kafka 같지는 않습니다. |
| NATS | 2010, Derek Collison | pub/sub · JetStream | 가벼움·낮은 지연. JetStream(2020) 으로 영속 추가. |
| Redis Streams | 2018, Redis 5.0 | log + consumer group | Kafka 의 축소판 같은 모델. 보유 데이터 양이 작은 자리에 적합. |
| AWS SQS | 2006 | 단순 큐 | 매니지드. FIFO 큐 옵션. 단일 메시지 ≤ 256KB. |
| AWS Kinesis | 2013 | 스트림 | Kafka 와 유사 모델의 매니지드. 24h ~ 365d 보존. |
| Google Pub/Sub | 2015 | pub/sub | 매니지드. 자동 확장. 순서 옵션. |
| Apache Pulsar | 2016, Yahoo (오픈소스) | 다층 (broker + bookie) | 멀티 테넌시·지오 복제 강조. |
선택의 결정 요인은 다음 중 한두 개로 좁아집니다.
- 데이터 보존 기간 (분 단위인가, 일 단위인가).
- 처리량 (초당 수만~수십만인가).
- 매니지드를 쓸 수 있는가.
- 라우팅·필터링이 복잡한가 (RabbitMQ 가 강함).
- 한 토픽을 여러 컨슈머가 다른 속도로 읽는가 (Kafka 형 모델이 자연스러움).
9. 토픽·컨슈머·운영
토픽 네이밍 — <도메인>.<엔티티>.<이벤트> 형식이 흔합니다 (예: orders.created). 환경을 prefix 또는 별도 클러스터로 분리합니다. 스키마는 Schema Registry (Avro · Protobuf · JSON Schema) 로 관리합니다.
컨슈머 설계 — 멱등 처리가 기본입니다. DLQ (Dead Letter Queue) 로 처리 실패가 반복되는 메시지를 별도 토픽으로 보냅니다. 일시적 외부 의존 (예: API 5xx) 에는 재시도 + backoff + DLQ 를 묶습니다.
파티션 수는 처리량과 컨슈머 수의 상한을 결정합니다. 처음에 너무 작게 잡으면 늘리기는 가능하지만 키-파티션 매핑이 바뀌어 순서 가정이 깨질 수 있습니다.
모니터링 — lag (컨슈머가 leader 끝과 얼마나 떨어졌는가), 메시지율, replication lag.
10. 자주 걸리는 자리
순서 가정 — 토픽 전체가 아니라 파티션 안에서만 순서가 보장됩니다. 여러 파티션을 사용하면 글로벌 순서는 없습니다.
파티션 수 변경 — 늘리는 것은 가능하지만 키 → 파티션 매핑이 바뀝니다. 같은 키의 메시지가 새 파티션으로 가게 되는 점이 운영 사고로 이어질 수 있습니다.
컨슈머 그룹 리밸런싱 — 새 컨슈머 합류·이탈 시 파티션 재할당이 일어납니다. 그동안 처리가 멈출 수 있습니다 (cooperative rebalancing 으로 완화).
exactly-once 의 범위 — 토픽 안에서만이라는 점입니다. 외부 DB 에 쓰는 컨슈머는 결국 멱등 설계가 필요합니다.
운영 자원 — 작은 팀에 매니지드 없이 자가 운영되는 Kafka 는 부담이 큽니다. Confluent Cloud · MSK · Aiven 같은 매니지드를 검토합니다.
하고픈 말
Kafka 는 "큐가 필요한가" 라는 질문에 늘 정답은 아닙니다. 보존·재처리·다중 컨슈머가 진짜 필요한 자리에서만 강합니다. 작은 팀이면 Redis Streams 나 RabbitMQ 로 시작해 키워가는 편이 운영에 안전합니다.
Next
- pgvector-rag
- supabase
Apache Kafka 공식 문서 · Kafka 디자인 · KRaft 가이드 · Confluent 블로그 · RabbitMQ 공식 · NATS JetStream · Apache Pulsar 를 참고합니다.