Kafka

이벤트 스트리밍이란 무엇인가

공식 문서는 이벤트 스트리밍을 '인체의 중추신경계에 해당하는 디지털 기술'이라 표현한다. 소프트웨어가 소프트웨어를 사용하는 '항상 켜져 있는(always-on)' 환경을 뒷받침하는 기술 기반이라는 뜻이다.

좀 더 기술적으로 풀면, 이벤트 스트리밍은 데이터베이스·센서·모바일 기기·클라우드 서비스·소프트웨어 애플리케이션 같은 이벤트 소스로부터 데이터를 실시간으로 이벤트 스트림 형태로 캡처하고, 이 스트림을 나중에 조회할 수 있도록 durable하게 저장하며, 실시간이든 사후든 필요에 따라 스트림을 조작·처리·반응시키고, 필요한 목적지 기술로 라우팅하는 일련의 실천이다. 즉 적절한 정보가 적절한 장소에, 적절한 시점에 있도록 데이터의 연속적인 흐름과 해석을 보장하는 것이 목표다.

이런 특성 덕분에 이벤트 스트리밍은 금융 거래 실시간 처리(주식 거래소, 은행, 보험), 물류·차량·화물 추적, IoT/공장/풍력발전 센서 데이터 수집, 소매·호텔·여행업의 고객 상호작용/주문 처리, 병원 환자 모니터링, 조직 내 여러 부서가 만드는 데이터의 연결·저장·공유, 그리고 데이터 플랫폼·이벤트 기반 아키텍처·마이크로서비스의 기반 기술까지 매우 폭넓은 영역에 쓰인다.

Kafka가 결합하는 3가지 핵심 기능

공식 문서는 Apache Kafka를 '이벤트 스트리밍 플랫폼'으로 정의하며, 이 플랫폼이 하나의 검증된 솔루션 안에 세 가지 핵심 기능을 결합한다고 설명한다.

첫째, 이벤트 스트림을 게시(publish, 쓰기)하고 구독(subscribe, 읽기)하는 기능이다. 여기에는 다른 시스템으로부터 데이터를 지속적으로 import/export하는 것도 포함된다. 둘째, 이벤트 스트림을 원하는 기간만큼 durable하고 신뢰성 있게 저장(store)하는 기능이다. 셋째, 이벤트 스트림이 발생하는 즉시 또는 나중에 소급해서 처리(process)하는 기능이다.

이 세 기능 모두 분산(distributed)되고, 고도로 확장 가능(highly scalable)하며, 탄력적(elastic)이고, 장애에 강하며(fault-tolerant), 보안이 적용된 방식으로 제공된다. Kafka는 베어메탈 하드웨어, 가상머신, 컨테이너 위에, 그리고 온프레미스는 물론 클라우드 환경에도 배포할 수 있다. 직접 운영(self-managing)할 수도 있고, 다양한 벤더가 제공하는 완전관리형(fully managed) 서비스를 이용할 수도 있다.

핵심 개념: 이벤트, 프로듀서와 컨슈머, 토픽

Kafka가 동작하는 방식의 밑바탕에는 '서버'와 '클라이언트'라는 구도가 있다. 서버들이 클러스터를 이루어 여러 데이터센터·클라우드 리전에 걸쳐 실행될 수 있는데, 이 중 저장 계층을 이루는 서버를 브로커(broker)라 부르고, 별도로 Kafka Connect를 실행하는 서버들이 외부 시스템(예: 관계형 데이터베이스)과 데이터를 지속적으로 주고받는다. 클러스터는 서버 중 하나가 장애를 일으켜도 나머지가 그 작업을 넘겨받아 데이터 손실 없이 계속 동작하도록 고가용성을 갖춘다. 클라이언트는 이런 서버들과 통신하며 이벤트 스트림을 병렬로, 대규모로, 네트워크 문제나 장비 장애에도 견고하게 읽고 쓰고 처리하는 분산 애플리케이션·마이크로서비스를 만들 수 있게 해준다. Java/Scala용 클라이언트(고수준 Kafka Streams 라이브러리 포함) 외에도 Go, Python, C/C++ 등 다양한 언어와 REST API로 된 커뮤니티 클라이언트가 제공된다.

가장 작은 데이터 단위는 이벤트(event)다. 문서/레코드/메시지라고도 부르며, 개념적으로 키(key)·값(value)·타임스탬프·선택적 메타데이터 헤더로 구성된다. 예를 들어 키가 "Alice", 값이 "Made a payment of $200 to Bob", 타임스탬프가 특정 일시인 이벤트를 생각할 수 있다.

이벤트를 만들어 게시(write)하는 클라이언트 애플리케이션을 프로듀서(producer)라 하고, 그 이벤트를 구독해 읽고 처리하는 쪽을 컨슈머(consumer)라 한다. Kafka에서 프로듀서와 컨슈머는 완전히 분리(decoupled)되어 서로를 전혀 알 필요가 없으며, 이것이 Kafka가 갖는 높은 확장성의 핵심 설계 요소다 — 예컨대 프로듀서는 컨슈머를 기다릴 필요가 없다. Kafka는 이벤트를 정확히 한 번(exactly-once) 처리할 수 있는 것과 같은 다양한 보장을 제공한다.

이벤트는 토픽(topic)에 조직되어 durable하게 저장된다. 아주 단순화하면 토픽은 파일시스템의 폴더와 비슷하고, 이벤트는 그 폴더 안의 파일과 같다. 토픽은 언제나 다중 프로듀서·다중 구독자를 지원한다 — 즉 프로듀서가 0개·1개·여러 개일 수 있고 구독하는 컨슈머도 0개·1개·여러 개일 수 있다. 전통적인 메시징 시스템과 달리, 이벤트는 한 번 소비되었다고 삭제되지 않고 필요한 만큼 반복해서 읽을 수 있다. 대신 토픽별 설정으로 얼마나 오래 보관할지 정의하며, 그 기간이 지나면 오래된 이벤트가 폐기된다. Kafka의 성능은 저장된 데이터 크기에 거의 영향받지 않으므로 오래 저장해도 무방하다.

파티셔닝과 복제

토픽은 파티션(partition)으로 나뉘어(partitioned) 여러 Kafka 브로커에 있는 여러 개의 '버킷'에 흩어져 저장된다. 이렇게 데이터를 분산 배치하는 것이 확장성의 핵심인데, 클라이언트 애플리케이션이 여러 브로커에서 동시에 데이터를 읽고 쓸 수 있기 때문이다. 새 이벤트가 토픽에 게시되면 실제로는 그 토픽의 파티션 중 하나에 append된다. 같은 이벤트 키(예: 고객 ID나 차량 ID)를 가진 이벤트는 같은 파티션에 기록되며, Kafka는 특정 토픽-파티션을 구독하는 컨슈머가 그 파티션의 이벤트를 항상 기록된 것과 정확히 같은 순서로 읽는다는 것을 보장한다. 문서에 실린 예시에서는 파티션이 4개(P1~P4)인 토픽에 두 프로듀서 클라이언트가 각자 독립적으로 이벤트를 게시하는데, 같은 색(=같은 키)의 이벤트는 항상 같은 파티션에 쓰이며, 두 프로듀서가 같은 파티션에 함께 쓰는 것도 가능하다는 점을 보여준다.

데이터를 장애에 강하고 고가용성 있게 만들기 위해 모든 토픽은 지역(geo-region)이나 데이터센터를 넘어서도 복제(replicated)될 수 있다. 즉 데이터가 잘못되거나, 브로커 유지보수가 필요하거나 하는 상황에 대비해 여러 브로커가 동일한 데이터의 사본을 항상 갖도록 한다. 운영 환경에서 흔한 설정은 복제 팩터(replication factor) 3, 즉 데이터 사본을 항상 3개 유지하는 것이다. 이 복제는 토픽-파티션 단위(level of topic-partitions)로 수행된다.

Kafka APIs

커맨드라인 관리·운영 도구 외에, Kafka는 Java/Scala를 위한 5가지 핵심 API를 제공한다. Admin API는 토픽·브로커 등 Kafka 객체를 관리·조회한다. Producer API는 하나 이상의 토픽으로 이벤트 스트림을 게시(쓰기)한다. Consumer API는 하나 이상의 토픽을 구독해 그 스트림을 처리한다. Kafka Streams API는 스트림 처리 애플리케이션·마이크로서비스를 구현하기 위한 고수준 API로, 변환(transformation), 집계·조인 같은 상태 유지(stateful) 연산, 윈도잉(windowing), 이벤트-타임 기반 처리 등을 제공한다 — 하나 이상의 토픽에서 입력을 읽어 하나 이상의 토픽으로 출력을 생성하는 방식으로 입력 스트림을 출력 스트림으로 변환한다. Kafka Connect API는 외부 시스템·애플리케이션과의 데이터 스트림을 읽거나 쓰는 재사용 가능한 import/export 커넥터를 만들고 실행하기 위한 API다 — 예컨대 PostgreSQL 같은 관계형 DB의 테이블 변경분을 캡처하는 커넥터를 만들 수 있지만, 실무에서는 커뮤니티가 이미 제공하는 수백 개의 즉시 사용 가능한 커넥터를 쓰는 경우가 대부분이라 직접 구현할 일은 드물다.