핵심 인사이트 (3줄 요약)
- 본질: Apache Kafka는 분산 이벤트 스트리밍 플랫폼으로, 수천만 TPS(Transactions Per Second)의 대규모 실시간 로그·이벤트를 내구성 있게 보관하며 다수의 소비자가 독립적으로 읽어갈 수 있는 고가용 메시지 브로커다.
- 가치: 생산자(Producer)와 소비자(Consumer)를 **분리(Decoupling)**하여 시스템 간 결합도를 낮추고, 파티션 기반 병렬 처리로 수평 확장이 가능하며, 메시지를 디스크에 영속 저장해 재처리를 지원한다.
- 판단 포인트: Kafka는 전통적 메시지 큐(RabbitMQ)와 달리 소비 후에도 메시지를 보존하므로, 여러 팀이 동일 스트림을 독립적으로 소비하는 이벤트 허브 용도에 최적이다.
Ⅰ. 개요 및 필요성
2010년 LinkedIn에서 대규모 활동 로그(페이지뷰, 클릭, 좋아요)를 실시간으로 처리하기 위해 개발했다. LinkedIn의 데이터 시스템들이 서로 직접 연결되어 있었는데, 서비스가 늘어날수록 N×M 연결 지옥이 됐다. Kafka는 이를 스타 토폴로지로 해결했다.
[Kafka 이전: 직접 연결 지옥] [Kafka 이후: 허브 토폴로지]
서비스A ──▶ DB1 서비스A ─┐
서비스A ──▶ DB2 서비스B ─┤─▶ Kafka ─┬─▶ DB1
서비스B ──▶ DB1 서비스C ─┘ ├─▶ DB2
서비스B ──▶ DB3 (n×m 연결) └─▶ Analytics
서비스C ──▶ DB2
→ 서비스 추가 시 연결 수 폭발 → 새 서비스는 Kafka만 연결
Kafka가 필요한 상황:
- 초당 수십만 건 이벤트를 다수의 소비자가 읽어야 할 때
- 생산자-소비자 처리 속도 차이를 버퍼링할 때
- 소비자 장애 시 재처리를 보장해야 할 때
- 이벤트 소싱(Event Sourcing) 아키텍처 구현
📢 섹션 요약 비유: Kafka는 TV 방송국이다. 방송국(Kafka)은 프로그램(이벤트)을 한 번 방송하면, 수백만 시청자(Consumer)가 각자 원하는 시간에 다시 보기(재소비)할 수 있다. 방송 프로그램은 지워지지 않고 보존된다.
Ⅱ. 아키텍처 및 핵심 원리
Kafka 클러스터 아키텍처
┌────────────────────────────────────────────────────────────────┐
│ Kafka 클러스터 │
│ │
│ Producer Brokers (복수 서버) Consumer │
│ ┌───────┐ write ┌────────────────────┐ read ┌───────┐ │
│ │ 앱A │ ─────────▶ │ Broker 1 (Leader) │ ────▶ │ 앱X │ │
│ │ 앱B │ │ Topic: orders │ │ 앱Y │ │
│ │ IoT │ │ Partition 0 ──┐ │ │ ML │ │
│ └───────┘ │ Partition 1 ──┤ │ └───────┘ │
│ │ Partition 2 ──┘ │ │
│ └────────────────────┘ │
│ ┌────────────────────┐ │
│ │ Broker 2 (Replica) │ ← 복제본 보관 │
│ │ Topic: orders │ │
│ └────────────────────┘ │
│ │
│ ZooKeeper (또는 KRaft): 클러스터 메타데이터 관리 │
└────────────────────────────────────────────────────────────────┘
핵심 구성 요소
| 구성 요소 | 역할 | 핵심 특성 |
|---|---|---|
| Topic | 메시지 분류 채널 | 이름으로 구분, 논리적 스트림 |
| Partition | Topic 물리 분할 단위 | 순서 보장 (파티션 내), 병렬 처리 |
| Broker | Kafka 서버 | 파티션 저장·서빙, 다수 브로커 클러스터 |
| Producer | 메시지 발행자 | 파티션 키로 파티션 선택 |
| Consumer | 메시지 소비자 | 오프셋 기반 순차 읽기 |
| Consumer Group | 소비자 그룹 | 파티션 분산 소비, Scale-out |
| Offset | 파티션 내 메시지 위치 | 소비자가 어디까지 읽었는지 추적 |
| Replication Factor | 파티션 복제 수 | 브로커 장애 시 가용성 보장 |
Kafka 메시지 저장 구조
Topic: "user-events" Replication Factor: 3
┌─────────────────────────────────────────────┐
│ Partition 0 (Broker 1 Leader) │
│ [0][1][2][3][4][5][6][7]... ← 오프셋 순서 │
│ │
│ Partition 1 (Broker 2 Leader) │
│ [0][1][2][3][4]... │
│ │
│ Partition 2 (Broker 3 Leader) │
│ [0][1][2][3][4][5]... │
└─────────────────────────────────────────────┘
각 파티션은 순서 보장 / 파티션 간 순서 미보장
메시지 보존: log.retention.hours 설정 (기본 168시간=7일)
📢 섹션 요약 비유: 파티션과 오프셋은 책의 챕터와 페이지 번호다. 여러 챕터(파티션)가 있고, 각 챕터를 여러 독자(Consumer)가 각자 어디까지 읽었는지(오프셋) 북마크를 가진다. 책은 읽어도 지워지지 않는다.
Ⅲ. 비교 및 연결
Kafka vs 전통 메시지 큐 비교
| 비교 항목 | Apache Kafka | RabbitMQ | Amazon SQS |
|---|---|---|---|
| 처리 모델 | Pub/Sub + Log | Pub/Sub + Queue | Queue |
| 메시지 보존 | 설정된 기간 보존 | 소비 후 삭제 | 소비 후 삭제 |
| 재처리 | 오프셋 리셋으로 재소비 | 불가 (삭제됨) | 가시성 타임아웃 |
| 처리량 | 매우 높음 (수백만 TPS) | 보통 | 보통 |
| 순서 보장 | 파티션 내 보장 | Queue별 보장 | 제한적 |
| 소비자 모델 | Pull 방식 | Push 방식 | Pull 방식 |
| 클러스터링 | 네이티브 분산 | 클러스터 가능 | AWS 관리형 |
| 적합 사례 | 이벤트 스트리밍, 로그 | 작업 큐, RPC | AWS 서비스 간 큐 |
Kafka 활용 패턴
| 패턴 | 설명 | 예시 |
|---|---|---|
| 이벤트 허브 | 다수 시스템 이벤트 중앙 집중 | 마이크로서비스 이벤트 버스 |
| 로그 집계 | 분산 서버 로그 중앙 수집 | ELK 스택 로그 파이프라인 |
| CDC 파이프라인 | DB 변경 이벤트 전달 | Debezium → Kafka → DW |
| 스트림 처리 | Flink/Spark가 실시간 처리 | 실시간 이상 탐지 |
| 이벤트 소싱 | 상태 변경을 이벤트로 보관 | 주문 상태 변경 이력 |
📢 섹션 요약 비유: Kafka와 RabbitMQ의 차이는 TV 방송과 편지 배달의 차이다. TV(Kafka)는 방송을 저장했다가 누구든 원하는 시간에 다시 볼 수 있지만, 편지(RabbitMQ)는 받은 사람이 읽으면 배달부가 수거해 간다.
Ⅳ. 실무 적용 및 기술사 판단
Kafka 클러스터 설계 원칙
[Kafka 설계 체크리스트]
□ 파티션 수 = 예상 최대 소비자 스레드 수
□ Replication Factor = 3 (브로커 3대 이상, 장애 허용)
□ acks = all (모든 레플리카 확인 후 쓰기 완료, 데이터 유실 방지)
□ min.insync.replicas = 2 (최소 2개 레플리카 동기화 보장)
□ log.retention.hours = 168 (7일 보존, 규정에 따라 조정)
□ 컨슈머 그룹 ID 명시 (재시작 시 오프셋 이어받기)
□ 스키마 레지스트리 (Avro/Protobuf 스키마 버전 관리)
실무 장애 패턴과 대응
| 장애 | 원인 | 대응 |
|---|---|---|
| 컨슈머 지연 증가 | 처리 속도 < 생산 속도 | 파티션 수 증가, 컨슈머 수 증가 |
| 파티션 쏠림 | 파티션 키 편중 | 파티션 키 재설계 |
| 리더 선출 폭풍 | 브로커 동시 재시작 | 롤링 재시작, Unclean Leader 방지 |
| 오프셋 커밋 누락 | 컨슈머 비정상 종료 | enable.auto.commit=false + 수동 커밋 |
📢 섹션 요약 비유: Kafka 파티션과 컨슈머 그룹의 관계는 카운터와 계산원 관계다. 마트 카운터(파티션) 3개에 계산원(컨슈머)이 3명이면 최적이지만, 계산원이 2명이면 한 명이 카운터 2개를 담당해야 해서 처리가 느려진다.
Ⅴ. 기대효과 및 결론
기대효과
| 효과 | 내용 |
|---|---|
| 고처리량 | 수백만 TPS 처리, LinkedIn 기준 1조 건/일 |
| 내구성 | 디스크 영속 저장, 브로커 장애 시 레플리카 자동 승격 |
| 재처리 지원 | 오프셋 리셋으로 과거 데이터 재처리 가능 |
| 시스템 분리 | Producer-Consumer 독립 배포·확장 |
| 멀티 컨슈머 | 동일 토픽을 여러 팀이 독립 소비 |
한계 및 주의점
| 한계 | 내용 |
|---|---|
| 운영 복잡성 | ZooKeeper(또는 KRaft), 브로커 관리 필요 |
| 파티션 수 고정 | 파티션 수 줄이기 불가 (증가는 가능) |
| 메시지 순서 | 파티션 내 순서만 보장, 전체 토픽 순서 미보장 |
| 소비자 그룹 리밸런싱 | 컨슈머 추가/제거 시 파티션 재할당 중 처리 중단 |
| 학습 곡선 | 파티션·오프셋·그룹 개념 이해 필요 |
📢 섹션 요약 비유: Kafka는 거대한 로그 기록 시스템이다. 모든 이벤트를 빠짐없이 순서대로 기록하고(순서 보장), 원하는 시점으로 되감아 다시 읽을 수 있다(재처리). 단, 이 시스템을 운영하려면 전문 관리자(운영 복잡성)가 필요하다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 카프카 토픽/파티션/컨슈머 그룹 | Kafka 내부 구조의 핵심 세 요소 |
| Apache Flink | Kafka를 소스로 사용하는 스트림 처리 엔진 |
| CDC / Debezium | DB 변경 이벤트를 Kafka로 전송하는 패턴 |
| 이벤트 소싱 | Kafka 토픽을 이벤트 저장소로 사용하는 아키텍처 |
| Pub/Sub 패턴 | Kafka의 핵심 메시징 패턴 |
| 스키마 레지스트리 | Kafka 메시지 스키마 버전 관리 (Confluent) |
| RabbitMQ / SQS | 전통 메시지 큐와의 비교 대상 |
👶 어린이를 위한 3줄 비유 설명
- Kafka는 유튜브 채널이다. 동영상(이벤트)을 올리면(Producer가 발행), 구독자(Consumer)가 각자 원하는 시간에 볼 수 있고, 영상은 지워지지 않아서 나중에 다시 볼 수 있다(재처리).
📈 관련 키워드 및 발전 흐름도
Point-to-Point 메시징 (RabbitMQ)
│
▼
Kafka: 분산 로그 기반 Pub/Sub
├─► Topic · Partition · Consumer Group
├─► 영속성: 디스크 순차 쓰기 + 복제
└─► Connect · Streams · Schema Registry
│
▼
Event-Driven Architecture (EDA) + CDC
- 파티션은 유튜브 재생목록과 같다. 한 채널의 영상이 여러 재생목록에 나뉘어 있으면, 여러 친구가 각자 다른 재생목록을 동시에 볼 수 있어 더 빠르다(병렬 처리).
- 오프셋은 책갈피다. 어디까지 읽었는지(소비했는지) 북마크를 저장해두면, 다음에 이어서 읽을 수 있고, 처음부터 다시 읽고 싶으면 북마크를 앞으로 옮기면 된다(재처리).