217. 아파치 카프카 이벤트 스트리밍 (Apache Kafka Event Streaming)

핵심 인사이트

본질: Apache Kafka는 LinkedIn이 2011년 오픈소스화한 분산 이벤트 스트리밍 플랫폼으로, Pub/Sub(Publish-Subscribe, 발행-구독) 패턴의 분산 커밋 로그(Distributed Commit Log)다. 토픽(Topic)/파티션(Partition)/오프셋(Offset)/컨슈머 그룹(Consumer Group) 4대 개념이 수백만 TPS(Transactions Per Second) 처리와 내구성을 동시에 보장한다.

가치: 이벤트 소싱(Event Sourcing) 아키텍처에서 Kafka는 모든 상태 변경을 불변 이벤트로 기록하는 **시스템 간 신뢰 원천(Source of Truth)**이 되며, 정확히 한 번(Exactly-once) 의미론은 금융·결제 시스템의 중복 처리를 원천 차단한다.

판단 포인트: 초당 수십만 건 이상의 고처리량 실시간 데이터 파이프라인, 마이크로서비스 간 비동기 통신, 이벤트 소싱 구현이 필요할 때 Kafka가 최적이며, 간단한 메시지 큐는 RabbitMQ/SQS도 충분하다.

Ⅰ. 개요 및 필요성

1.1 LinkedIn의 데이터 파이프라인 문제

2010년대 초 LinkedIn은 다양한 서비스(프로필, 뉴스피드, 광고, 추천) 간 데이터 교환을 위해 수십 개의 포인트-투-포인트(Point-to-Point) 파이프라인을 운영했다. 서비스 N개가 서로 연결되면 N²개의 파이프라인이 필요하고, 유지보수 비용이 폭발적으로 증가했다.

Kafka는 이를 중앙 이벤트 허브(Central Event Hub) 패턴으로 해결했다. 생산자(Producer)는 이벤트를 Kafka에 발행하고, 소비자(Consumer)는 필요한 이벤트를 독립적으로 구독한다. N개 서비스가 연결되어도 파이프라인은 N개(각 서비스와 Kafka 간 연결)로 유지된다.

1.2 Kafka의 핵심 설계 철학

이벤트 로그(Event Log): 데이터를 불변(Immutable) 순서 기록으로 보관
내구성(Durability): 디스크에 순차 저장, 복제 팩터로 장애 대응
확장성(Scalability): 파티션 수 증가로 처리량 선형 확장
재처리(Replay): 이전 오프셋부터 재소비로 데이터 재처리 가능

📢 섹션 요약 비유: Kafka는 TV 방송국과 같다. 방송국(Kafka)은 채널(토픽)마다 프로그램(이벤트)을 방영하고, 시청자(컨슈머)는 원하는 채널을 선택해 시청한다. 방송은 시청자가 없어도 계속되고(내구성), 녹화(오프셋 보존) 덕분에 지난 방송도 다시 볼 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

2.1 Kafka 아키텍처 구조

┌─────────────────────────────────────────────────────────────┐
│              Apache Kafka Architecture                      │
│                                                             │
│  Producers (생산자)        Kafka Cluster         Consumers  │
│  ┌───────────┐             ┌─────────────────┐  ┌────────┐ │
│  │ Web App   │────────────►│  Topic: orders  │  │Group A │ │
│  │ (주문 서비스│  Partition 0│ ┌─────────────┐│  │Consumer│ │
│  └───────────┘             │ │[0][1][2][3] ││──►│(분석팀)│ │
│                            │ └─────────────┘│  └────────┘ │
│  ┌───────────┐             │  Partition 1   │             │
│  │ Mobile App│────────────►│ ┌─────────────┐│  ┌────────┐ │
│  │ (결제 서비스│             │ │[0][1][2]   ││  │Group B │ │
│  └───────────┘             │ └─────────────┘│──►│Consumer│ │
│                            │  Partition 2   │  │(알림팀)│ │
│  ┌───────────┐             │ ┌─────────────┐│  └────────┘ │
│  │ IoT Device│────────────►│ │[0][1][2][3] ││             │
│  └───────────┘             │ └─────────────┘│  ┌────────┐ │
│                            └─────────────────┘  │Group C │ │
│                                        Offset→  │Consumer│ │
│  ZooKeeper / KRaft: 메타데이터 관리    재처리 가능│(ML팀) │ │
│                                                  └────────┘ │
└─────────────────────────────────────────────────────────────┘

2.2 토픽·파티션·오프셋·컨슈머 그룹

개념	설명	역할
토픽 (Topic)	이벤트 분류 채널 (예: orders, payments)	논리적 메시지 채널
파티션 (Partition)	토픽의 물리적 분할 단위, 순서 보장	병렬 처리 단위
오프셋 (Offset)	파티션 내 메시지 순번 (불변)	재처리·위치 추적 기준
컨슈머 그룹 (Consumer Group)	동일 토픽을 독립적으로 소비하는 컨슈머 집합	병렬 소비 + 독립 소비
브로커 (Broker)	Kafka 서버 노드, 파티션 저장·관리	분산 저장 단위
복제 팩터 (Replication Factor)	파티션 복제 수, 보통 3으로 설정	장애 내성

2.3 정확히 한 번(Exactly-once) 의미론

전달 의미론	설명	위험	사용
At-most-once	최대 1회 전달, 손실 가능	데이터 유실	로그, 비중요 이벤트
At-least-once	최소 1회 전달, 중복 가능	중복 처리	일반적 기본값
Exactly-once	정확히 1회 전달, 중복·손실 없음	높은 오버헤드	결제, 금융 트랜잭션

Exactly-once는 Idempotent Producer + Transactional API + **Stream Processing(Kafka Streams/Flink)**의 조합으로 구현된다.

📢 섹션 요약 비유: 파티션과 오프셋은 지하철 노선도와 같다. 토픽이 노선이고, 파티션이 각 열차 칸이며, 오프셋은 역 번호다. 컨슈머는 자신이 마지막으로 내린 역(오프셋) 번호를 기억하고, 다음에 그 다음 역부터 탑승한다. 재처리는 첫 번째 역부터 다시 탑승하는 것이다.

Ⅲ. 비교 및 연결

3.1 Kafka vs 전통 메시지 큐 비교

항목	Kafka	RabbitMQ	AWS SQS
패턴	Pub/Sub + 로그	큐 기반 메시징	큐 기반 관리형
처리량	수백만 TPS	수만 TPS	수만 TPS
메시지 보관	설정 기간 보관 (재처리 가능)	소비 후 삭제	소비 후 삭제
순서 보장	파티션 내 보장	큐 내 보장	FIFO 큐만
컨슈머 독립성	여러 그룹 독립 소비	메시지 경쟁 소비	메시지 경쟁 소비
적합 용도	이벤트 스트리밍, 로그 수집	작업 큐, RPC	서버리스, AWS 네이티브

3.2 이벤트 소싱(Event Sourcing) 아키텍처

이벤트 소싱은 시스템의 모든 상태 변경을 이벤트(불변 레코드)로 저장하는 패턴이다. Kafka를 이벤트 저장소로 사용하면 현재 상태를 이벤트 리플레이로 재계산할 수 있고, 완전한 감사 로그(Audit Log)를 자동으로 얻는다.

주문 이벤트 스트림:
[OrderCreated, orderId=001, amount=50000]
[PaymentProcessed, orderId=001, status=SUCCESS]
[OrderShipped, orderId=001, trackingNo=ABC123]
→ 현재 주문 상태: SHIPPED (이벤트 리플레이로 계산)

📢 섹션 요약 비유: Kafka는 전통 메시지 큐와 달리 편지를 보낸 후 배달부(브로커)가 원본을 보관한다. 여러 수신자가 각자 독립적으로 편지를 읽을 수 있고, 지난 편지도 다시 꺼내 읽을 수 있다. 전통 큐는 한 명이 가져가면 사라진다.

Ⅳ. 실무 적용 및 기술사 판단

4.1 Kafka 주요 활용 패턴

패턴	설명	예시
이벤트 수집	클릭스트림, 앱 로그, IoT 센서	사용자 행동 분석, 모니터링
마이크로서비스 연계	서비스 간 비동기 이벤트 전달	주문→결제→배송 이벤트 체인
실시간 ETL	소스→Kafka→스트림 처리→DW	CDC 기반 실시간 데이터 동기화
이벤트 소싱	상태를 이벤트 로그로 관리	금융 원장, 재고 관리
CQRS (Command Query Responsibility Segregation)	쓰기/읽기 모델 분리	고성능 조회 시스템

4.2 Kafka Streams vs Apache Flink 비교

항목	Kafka Streams	Apache Flink
배포	Kafka 내장, 별도 클러스터 불필요	별도 Flink 클러스터 필요
처리 모델	Kafka 토픽 기반	분산 스트리밍 엔진
상태 관리	RocksDB 로컬 상태	체크포인트, 분산 상태
복잡도	간단한 스트림 처리	복잡한 CEP(Complex Event Processing)

4.3 기술사 핵심 출제 포인트

Kafka 4대 핵심 개념: 토픽/파티션/오프셋/컨슈머 그룹의 역할 명확 구분
3가지 전달 의미론: At-most-once, At-least-once, Exactly-once 비교
이벤트 소싱 vs 전통 상태 저장: 이벤트 로그 기반의 장점
Kafka와 CDC 연동: Debezium을 통한 DB 변경사항 실시간 캡처

📢 섹션 요약 비유: Exactly-once는 ATM에서 돈을 뽑을 때 "정확히 요청한 금액만 한 번 인출"하는 것과 같다. At-most-once는 때로 인출이 안 되고(유실), At-least-once는 때로 두 번 인출되는(중복) 상황이다. 금융 시스템은 반드시 Exactly-once가 필요하다.

Ⅴ. 기대효과 및 결론

5.1 Kafka 도입 효과

효과	내용
처리량	단일 클러스터 초당 수백만 메시지 처리
내구성	복제 팩터 3으로 브로커 장애 시에도 데이터 보존
확장성	파티션 추가로 처리량 선형 확장
디커플링	생산자-소비자 완전 분리로 서비스 독립 배포
재처리	오프셋 리셋으로 과거 데이터 재처리 가능
실시간	밀리초 수준 이벤트 전달로 실시간 파이프라인 구현

5.2 Kafka 생태계와 미래

Kafka의 ZooKeeper 의존성 제거를 위한 KRaft(Kafka Raft) 메타데이터 관리가 Kafka 3.x에서 표준화됐다. Kafka Connect로 수백 개 소스/싱크 시스템과 표준화된 방식으로 연결하며, Schema Registry로 이벤트 스키마를 중앙 관리한다. Confluent Platform과 AWS MSK(Managed Streaming for Kafka)로 완전 관리형 Kafka 서비스가 주류가 됐다.

📢 섹션 요약 비유: Kafka는 도시의 중앙 우편 허브다. 모든 발신자(Producer)는 허브에 편지를 맡기고, 모든 수신자(Consumer Group)는 자신의 우편함에서 필요한 편지를 가져간다. 허브는 편지를 일정 기간 보관해 분실 방지와 재배달을 지원한다. 특급(Exactly-once)과 일반(At-least-once) 서비스를 용도에 맞게 선택한다.

📌 관련 개념 맵

개념	설명	연관 키워드
토픽 (Topic)	이벤트 분류 논리 채널	파티션, 소비자 그룹
파티션 (Partition)	토픽의 병렬 처리 물리 단위	순서 보장, 병렬성
오프셋 (Offset)	파티션 내 메시지 순번	재처리, 위치 추적
컨슈머 그룹	독립적 토픽 소비 그룹	병렬 소비, 독립성
Exactly-once	중복·유실 없는 정확한 1회 전달	금융, 결제, Idempotent
이벤트 소싱	상태 변경을 이벤트 로그로 관리	CQRS, 감사 로그
Kafka Connect	소스/싱크 시스템 표준 연결 프레임워크	CDC, Debezium
Schema Registry	이벤트 스키마 중앙 관리	Avro, 호환성 관리

👶 어린이를 위한 3줄 비유 설명

Kafka는 여러 채널이 있는 유튜브 같아. 방송국(Producer)은 각 채널(토픽)에 영상(이벤트)을 올리고, 구독자(Consumer Group)는 원하는 채널을 구독해서 각자 시청해. 영상은 일정 기간 삭제되지 않아서 나중에 다시 볼 수 있어(오프셋 재처리).
파티션은 고속도로 차선이야. 차선이 많을수록(파티션 수 증가) 더 많은 차(이벤트)가 동시에 달릴 수 있어. 각 차선 안에서는 순서가 지켜져(파티션 내 순서 보장).
Exactly-once는 편의점 결제할 때 "카드가 딱 한 번만 청구"되는 것과 같아. 통신 오류로 두 번 청구되거나(중복), 아예 안 빠져나가는(유실) 상황 없이 정확히 한 번만 처리되는 거야.