이벤트 스트리밍이란

실시간으로 쏟아지는 데이터(결제, 센서, 주문, 로그 같은 것들)를 그때그때 받아서 보관하고, 필요할 때 다시 꺼내 읽고, 흐르는 동안 바로 처리하거나 나중에 되돌려 볼 수 있게 해 주는 방식이 바로 이벤트 스트리밍이에요. Apache Kafka는 이런 이벤트 스트리밍을 한 플랫폼에서 처음부터 끝까지 구현할 수 있게 해 주는 분산 시스템입니다.

출처: Apache Kafka — Introduction

이벤트 스트리밍은 어떤 문제를 푸나요

이벤트 스트리밍은 "항상 켜져 있는(always-on)" 세상의 기반이 되는 기술이에요. 데이터베이스, 센서, 모바일 기기, 클라우드 서비스, 애플리케이션 같은 이벤트 소스에서 실시간으로 데이터를 잡아내고, 이 이벤트 흐름(stream)을 나중에 다시 꺼낼 수 있게 오래 보관하고, 실시간으로도 과거 기준으로도 가공·처리·반응하고, 필요에 따라 다른 기술로 흘려보내는 것까지 전부 포함해요. 목표는 늘 같은 것, "올바른 정보가 올바른 곳에 올바른 시점에 있게" 하는 겁니다.

이걸 어디에 쓰는지 보면 이해가 빨라져요. 주식 거래소 같은 곳에서 결제·금융 거래를 실시간으로 처리하고, 물류·자동차 업계에서 차량과 화물 위치를 실시간으로 추적하고, 공장·풍력발전소에서 IoT 센서 데이터를 계속 수집해 분석하고, 리테일에서 고객의 주문과 상호작용에 바로 반응하는 식이에요. 병원에서 환자 상태를 모니터링해 응급 대응을 돕고, 회사 여러 부서에서 만든 데이터를 한곳에 모아 연결하는 역할도 하죠. 이렇게 보면 데이터 플랫폼, 이벤트 기반 아키텍처, 마이크로서비스의 토대가 되는 이유가 납득돼요.

Kafka 세 가지 핵심 역량

Kafka는 이벤트 스트리밍을 세 가지 능력으로 정리해요.

발행(publish)과 구독(subscribe) — 이벤트 흐름을 쓰고 읽는 기능. 다른 시스템에서 데이터를 계속 가져오거나 내보내는 것도 포함해요.
저장(store) — 이벤트 흐름을 원하는 만큼 오래, 안정적으로 보관.
처리(process) — 이벤트가 발생하는 순간에, 혹은 나중에 되돌려 처리.

이 모든 기능이 분산·고확장·탄력적·내결함·보안적으로 제공돼요. 베어메탈, 가상머신, 컨테이너, 온프레미스, 클라우드 어디든 배포할 수 있고, 직접 운영할 수도 있고 여러 벤더의 완전관리 서비스를 쓸 수도 있어요.

클러스터와 클라이언트 구조

Kafka는 서버와 클라이언트로 나뉘고, 이 둘이 고성능 TCP 네트워크 프로토콜로 통신해요.

서버: 하나 이상의 서버가 클러스터를 이루고 여러 데이터센터나 클라우드 리전에 걸칠 수 있어요. 저장 역할을 하는 브로커(broker)가 핵심이고, Kafka Connect를 운영해 관계형 데이터베이스 같은 기존 시스템과 이벤트 흐름을 주고받게 만들기도 해요. 서버 하나가 죽으면 나머지가 그 일을 넘겨받아 데이터 손실 없이 계속 돌아가는 게 설계 목표예요.
클라이언트: 이벤트 흐름을 병렬로, 대규모로, 내결함적으로 읽고 쓰고 처리하는 분산 애플리케이션·마이크로서비스를 만들 수 있게 해 줘요. Java·Scala(고수준 라이브러리 Kafka Streams 포함), Go, Python, C/C++ 등 여러 언어와 REST API 클라이언트가 있어요.

핵심 개념과 용어

**이벤트(event)**는 "세상에서 무언가 일어났다"는 사실을 기록한 것이에요. 문서에서는 record나 message라고도 불러요. 개념적으로 이벤트는 키(key), 값(value), 타임스탬프(timestamp), 그리고 선택적인 메타데이터 헤더(headers)를 가져요. 예를 들면 이런 식이에요.

이벤트 키: "Alice"
이벤트 값: "Bob에게 200달러를 결제했습니다"
이벤트 타임스탬프: "2020년 6월 25일 오후 2시 6분"

**프로듀서(producer)**는 이벤트를 Kafka에 발행(쓰는) 클라이언트이고, **컨슈머(consumer)**는 그 이벤트를 구독해 읽고 처리하는 클라이언트예요. Kafka에서 프로듀서와 컨슈머는 완전히 분리되어 서로를 몰라요. 프로듀서가 컨슈머를 기다릴 필요가 전혀 없다는 게 높은 확장성의 핵심 설계 요소예요. 정확히-한-번(exactly-once) 처리를 포함한 다양한 보장도 제공해요.

토픽과 파티션

이벤트는 **토픽(topic)**에 모여 오래 보관돼요. 아주 단순하게 비유하면 토픽은 파일시스템의 폴더, 이벤트는 그 폴더 안의 파일과 비슷해요. 토픽 이름은 payments 같은 게 될 수 있어요. 토픽은 항상 다중 프로듀서·다중 구독자가 가능해요 — 이벤트를 쓰는 프로듀서도 여러 명, 구독하는 컨슈머도 여러 명일 수 있죠. 토픽의 이벤트는 필요할 때 몇 번이든 다시 읽을 수 있어요. 전통적인 메시징 시스템과 달리 소비했다고 삭제되지 않거든요. 대신 토픽별 설정으로 이벤트를 얼마나 오래 보관할지를 정하고, 지난 이벤트는 그 뒤 폐기돼요. Kafka의 성능은 데이터 크기에 대해 실질적으로 일정해서 오래 저장해도 전혀 부담이 없어요.

토픽은 **파티션(partition)**으로 나뉘어요. 파티션은 서로 다른 브로커에 흩어져 있는 "버킷" 같은 거예요. 데이터를 여러 브로커에 분산 배치하는 건 클라이언트가 동시에 여러 브로커에서 읽고 쓸 수 있게 해 주는 확장성의 핵심이에요. 새 이벤트가 토픽에 발행되면 실제로는 그 토픽의 파티션 하나에 추가(append)돼요. 같은 키(예: 고객 ID나 차량 ID)를 가진 이벤트는 같은 파티션에 쓰이고, Kafka는 어떤 컨슈머든 특정 토픽-파티션의 이벤트를 쓰인 순서 그대로 읽는다는 점을 보장해요.

예컨대 토픽에 파티션 P1~P4 네 개가 있다고 해 봐요. 두 프로듀서가 각자 독립적으로 이 토픽에 이벤트를 쓰고, 같은 키(그림에서는 색으로 표시)의 이벤트는 같은 파티션으로 들어가요. 적절하다면 두 프로듀서가 같은 파티션에 쓸 수도 있어요.

복제와 가용성

내결함성과 고가용성을 위해 모든 토픽은 **복제(replicate)**될 수 있어요. 리전이나 데이터센터를 넘어서도 복제해서, 브로커 하나가 문제가 나거나 유지보수를 해도 데이터 사본이 항상 여럿 남게 하는 거죠. 흔한 운영 설정은 복제 팩터 3, 즉 데이터 사본이 항상 세 개 있는 상태예요. 복제는 토픽-파티션 단위로 이뤄져요.

Kafka 코어 API

관리·운영용 커맨드라인 도구 외에 Kafka는 Java·Scala용으로 다섯 가지 코어 API가 있어요.

Admin API — 토픽, 브로커, 기타 Kafka 객체를 관리하고 조사.
Producer API — 하나 이상의 토픽에 이벤트 흐름을 발행(쓰기).
Consumer API — 하나 이상의 토픽을 구독해(읽어) 그 흐름을 처리.
Kafka Streams API — 스트림 처리 애플리케이션·마이크로서비스 구현. 변환, 집계·조인 같은 상태 저장 연산, 윈도잉, 이벤트-시간 기반 처리 등 고수준 함수를 제공. 입력 토픽을 읽어 출력 토픽을 만드는 식으로 입력 스트림을 출력 스트림으로 변환해요.
Kafka Connect API — 외부 시스템과 Kafka 사이에서 이벤트 흐름을 가져오고 내보내는 재사용 가능한 커넥터를 만들고 운영. 실제로는 커뮤니티가 이미 수백 개 커넥터를 만들어 두어서 직접 만들 일이 거의 없어요.

더 알아보기

실제 체험은 Quickstart를 따라 해 보세요.
더 깊이 이해하려면 Documentation을 보세요.
사용 사례에서 전 세계 커뮤니티가 Kafka를 어떻게 활용하는지 확인할 수 있어요.