Kafka 활용 사례 (Use Cases)
Apache Kafka Official Documentation — Getting Started (v4.3) — Apache Software Foundation Getting Started 공식문서 — 2. Use Cases (pp.6-7)
이 모듈을 다 읽으면
- Kafka의 대표 활용 사례(메시징, 활동 추적, 메트릭, 로그 수집, 스트림 처리, 이벤트 소싱, 커밋 로그)를 구분해 설명할 수 있다
- 각 사례에서 Kafka가 기존 대안(전통 메시지 브로커, Scribe/Flume 등) 대비 갖는 차별점을 설명할 수 있다
공식 문서가 소개하는 Apache Kafka의 대표 활용 사례들을 정리한다. 전통적인 메시지 브로커의 대체재로서의 메시징부터, Kafka의 원래 탄생 배경인 웹사이트 활동 추적, 운영 메트릭 수집, 로그 수집, 스트림 처리, 이벤트 소싱, 분산 시스템의 커밋 로그까지 각 사례별로 Kafka가 기존 대안 대비 갖는 장점을 짚는다.
메시징 (Messaging)
Kafka는 전통적인 메시지 브로커를 대체하는 용도로도 잘 동작한다. 메시지 브로커는 흔히 처리 로직을 데이터 생산자로부터 분리(decouple)하거나, 아직 처리되지 않은 메시지를 버퍼링하는 등의 목적으로 쓰인다. 기존 메시징 시스템 대부분과 비교했을 때 Kafka는 더 나은 처리량, 내장된 파티셔닝, 복제, 내결함성을 갖추고 있어 대규모 메시지 처리 애플리케이션에 적합한 해법이 된다.
공식 문서는 메시징 용도가 상대적으로 처리량은 낮지만 종단간 지연(latency)이 낮아야 하고 Kafka가 제공하는 강한 durability 보장에 의존하는 경우가 많다는 경험을 밝히고 있다. 이런 영역에서 Kafka는 ActiveMQ나 RabbitMQ 같은 전통적인 메시징 시스템과 비교되는 위치에 있다.
핵심 포인트
- 메시지 브로커는 처리와 생산자를 분리하고 미처리 메시지를 버퍼링하는 데 쓰인다
- Kafka는 기존 메시징 시스템 대비 높은 처리량 + 내장 파티셔닝/복제/내결함성이 강점
- 메시징 용도는 낮은 종단간 지연과 강한 durability 보장이 중요한 경우가 많다 (비교 대상: ActiveMQ, RabbitMQ)
웹사이트 활동 추적과 메트릭
Kafka의 원래 사용 사례는 사용자 활동 추적 파이프라인을 일련의 실시간 publish-subscribe 피드로 재구축하는 것이었다. 즉 페이지뷰, 검색, 그 외 사용자 행동 같은 사이트 활동을 활동 유형별로 하나씩 중앙 토픽에 게시한다. 이 피드들은 실시간 처리, 실시간 모니터링, 그리고 Hadoop이나 오프라인 데이터 웨어하우징 시스템으로의 적재를 포함한 다양한 용도로 구독될 수 있다. 활동 추적은 페이지뷰 하나마다 여러 활동 메시지가 생성되기 때문에 대체로 매우 높은 볼륨을 갖는다.
한편 Kafka는 운영 모니터링 데이터, 즉 메트릭 용도로도 자주 쓰인다. 분산된 애플리케이션들에서 나온 통계치를 모아 운영 데이터의 중앙화된 피드를 만드는 것이 이 사용 사례의 핵심이다.
핵심 포인트
- Kafka의 원래(original) 사용 사례는 사이트 활동(페이지뷰/검색/행동)을 활동 유형별 토픽으로 실시간 pub/sub 재구축하는 것
- 활동 추적 피드는 실시간 처리·모니터링·Hadoop/오프라인 웨어하우징 적재 등 여러 용도로 재사용된다
- 메트릭 사용 사례는 여러 분산 애플리케이션의 운영 통계를 모아 중앙화된 피드로 만드는 것
로그 수집과 스트림 처리
많은 사용자가 Kafka를 로그 수집(log aggregation) 솔루션의 대체재로 쓴다. 로그 수집은 보통 여러 서버에서 물리적인 로그 파일을 걷어 파일 서버나 HDFS 같은 중앙 장소에 모아 처리하는 작업을 뜻한다. Kafka는 파일이라는 세부사항을 추상화하고, 로그나 이벤트 데이터를 메시지의 스트림이라는 더 깔끔한 형태로 제공한다. 이는 더 낮은 지연의 처리와, 여러 데이터 소스·분산된 데이터 소비를 지원하기 더 쉽게 만들어준다. Scribe나 Flume 같은 로그 중심 시스템과 비교하면, Kafka는 대등한 성능에 복제를 통한 더 강한 durability 보장, 그리고 훨씬 낮은 종단간 지연을 제공한다.
Kafka 사용자 다수는 여러 단계로 구성된 처리 파이프라인에서 데이터를 처리한다. 원본 입력 데이터를 Kafka 토픽에서 읽어 집계·보강(enrich)하거나 다른 방식으로 변환한 뒤 새로운 토픽에 실어 추가 소비나 후속 처리에 쓴다. 예를 들어 뉴스 기사를 추천하는 파이프라인은 RSS 피드에서 기사 콘텐츠를 크롤링해 "articles" 토픽에 게시하고, 이어지는 단계가 이 콘텐츠를 정규화·중복제거해 새 토픽에 게시하며, 마지막 단계가 이 콘텐츠를 사용자에게 추천하는 식이다. 이런 처리 파이프라인은 개별 토픽을 기반으로 한 실시간 데이터 흐름 그래프를 만들어낸다. 0.10.0.0부터는 이런 처리를 위해 가볍지만 강력한 Kafka Streams 라이브러리가 Apache Kafka에 포함되어 있으며, 그 밖의 오픈소스 스트림 처리 도구로 Apache Storm과 Apache Samza가 있다.
핵심 포인트
- 로그 수집(log aggregation) 대체재로서 Kafka는 파일 세부사항을 추상화해 메시지 스트림 형태로 제공한다
- Scribe/Flume 대비 대등한 성능 + 복제 기반의 더 강한 durability + 훨씬 낮은 종단간 지연이 강점
- 다단계 처리 파이프라인(원본→집계/보강→변환)은 토픽을 잇는 실시간 데이터 흐름 그래프를 만든다
- 0.10.0.0부터 Kafka Streams 라이브러리가 포함되었으며, 대안으로 Apache Storm·Apache Samza가 있다
이벤트 소싱과 커밋 로그
이벤트 소싱(event sourcing)은 상태 변화를 시간순으로 정렬된 레코드 시퀀스로 기록하는 애플리케이션 설계 스타일이다. 매우 큰 규모의 저장된 로그 데이터를 지원하는 Kafka의 특성은 이런 스타일로 만들어진 애플리케이션의 백엔드로서 훌륭한 선택지가 되게 한다.
또한 Kafka는 분산 시스템을 위한 일종의 외부 커밋 로그(commit log) 역할도 할 수 있다. 이 로그는 노드 간 데이터 복제를 돕고, 장애가 난 노드가 데이터를 복구하기 위한 재동기화(re-syncing) 메커니즘으로 동작한다. Kafka의 로그 컴팩션(log compaction) 기능이 바로 이런 용도를 지원한다. 이 사용 사례에서 Kafka는 Apache BookKeeper 프로젝트와 유사한 위치에 있다.
핵심 포인트
- 이벤트 소싱 = 상태 변화를 시간순 레코드 시퀀스로 기록하는 설계 스타일. Kafka의 대용량 로그 저장 능력이 이 스타일의 백엔드로 적합
- Kafka는 분산 시스템의 외부 커밋 로그로도 쓰일 수 있으며, 로그 컴팩션이 노드 재동기화를 지원한다 (비교 대상: Apache BookKeeper)