[Kafka] 스트리밍 데이터 처리와 Event-Driven Architecture 이해하기

 

현대의 디지털 서비스는 점점 더 실시간 응답을 요구하고 있습니다. 사용자의 행동, 장비의 센서 데이터, 시스템 로그 등 수많은 정보가 끊임없이 생성되고 있으며, 이를 즉시 처리하고 반응해야만 경쟁력을 유지할 수 있습니다. 이러한 요구를 충족시키기 위해 등장한 것이 이벤트 스트리밍(event streaming)과 이벤트 기반 아키텍처(Event-Driven Architecture)입니다.

 

이번 글에서는 이벤트 스트리밍의 개념부터, Event-Driven Architecture, 그리고 분산 메시지 큐에 이르기까지 핵심 개념을 정리해 보겠습니다.

 

 

1. 스트리밍 데이터 처리의 필요성

1.1 이벤트 스트리밍이란?

이벤트 스트리밍(event streaming)은 데이터베이스, 센서, 모바일 장치 등에서 발생하는 실시간 데이터를 이벤트 스트림 형태로 캡처하고 저장/처리하는 기술입니다. 이벤트는 비즈니스 시스템의 상태 변화이며, 이를 적절한 소비자에게 실시간으로 전달함으로써 빠른 의사결정을 가능하게 합니다.

 

1.2 이벤트 스트리밍의 사용 사례

이벤트 스트리밍은 아래와 같은 다양한 산업에서 널리 활용되고 있습니다:

• 금융: 증권 거래소, 은행, 보험에서 실시간 결제 및 거래 처리
• 물류/운송: 차량, 선박, 물류 시스템의 위치 추적 및 상태 모니터링
• 제조/에너지: IoT 센서를 통한 실시간 설비 상태 분석
• 헬스케어: 환자의 바이탈 사인 모니터링 및 응급 반응
• 전자상거래/여행/모바일 앱: 고객 상호작용과 주문 처리
• 데이터 파이프라인: 조직 내 여러 시스템을 연결하여 실시간 데이터 흐름 구성

 

1.3 스트리밍 시스템이 필요한 이유

우리는 모든 것을 온라인으로 처리하는 시대에 살고 있습니다. 사용자와의 인터랙션도 더 이상 느긋하게 기다릴 수 없습니다. 스트리밍 데이터 처리 시스템은 다음과 같은 특성을 만족해야 합니다:

• 낮은 지연 시간 (Low latency)
• 높은 처리량 (High throughput)
• 확장성 (Scalability)
• 내구성 (Persistence)
• 운영 용이성 (Operability)

 

 

2. Event-Driven Architecture (이벤트 기반 아키텍처)

2.1 이벤트 기반 아키텍처란?

기존의 전통적인 서비스 구조에서는 하나의 트랜잭션 안에서 모든 작업을 순차적으로 처리해야 했습니다. 예를 들어 쇼핑몰 주문 처리의 경우, 재고 확인 > 잔고 확인 > 결제 > 알림 발송 등 모든 과정이 순차적이며 tightly coupled(강하게 결합 = 긴밀하게 의존)되어 있었습니다.

하지만 Event-Driven Architecture에서는 주문이라는 이벤트 발생 후에 필요한 작업들이 독립적이고 비동기적으로 처리됩니다. 이 구조는 실제 현실 세계의 협업 방식과 유사하며, 확장성과 복원력도 뛰어납니다.

 

2.2 Publisher-Subscriber 모델

이벤트 기반 시스템은 일반적으로 Pub/Sub(Publisher-Subscriber) 모델을 따릅니다.

• Publisher: 이벤트를 발생시키는 주체 (예: 주문 시스템)
• Subscriber: 해당 이벤트에 반응하는 컴포넌트 (예: 재고 시스템, 결제 시스템)
• Event Channel: 이벤트가 전달되는 경로 (예: Kafka, RabbitMQ)

Publisher는 Subscriber의 존재 여부를 몰라도 되고, Subscriber는 필요한 이벤트에 대해서만 반응할 수 있습니다. 이는 시스템을 느슨하게 결합(loose coupling = decoupling)시켜줍니다.

 

2.3 장점

1. 처리 로직 분리: 각 기능은 독립적으로 작동 (SoC = 관심사의 분리)
2. 확장성: 하나의 이벤트에 여러 구독자를 decoupling된 상태로 확장할 수 있음
3. 디버깅 용이: 이벤트는 상태가 없기 때문(stateless)에 버그 발생이 줄고 추적이 쉬워진다.
   (상태를 관리하게 되면 선후 시스템에 결합이 생기고 운영 난이도가 올라간다.)
4. 복원력 및 유연성: 장애 복구와 확장이 수월함
5. 생산성 향상: 위와 같은 이유로 대규모 시스템에서 효율적

 

2.4 단점

• 복잡성 증가: 단순한 서비스에 오히려 과도할 수 있음 (최소 서버 3종류 필요하며 각 서버마다 관리 필요)
• 초기 인프라 비용: 메시징 시스템 도입 필요
• 단, AWS SQS 등 클라우드 기반 서비스로 초기 비용 절감 가능

 

 

3. 분산 메시지 큐 (Distributed Message Queue)

3.1 메시지 큐란?

이벤트 기반 아키텍처의 핵심 구성요소 중 하나는 메시지 큐 시스템입니다. 단일 애플리케이션 내부의 메시지 큐 (예: JMS)로는 충분하지 않기 때문에, 독립적인 메시지 브로커 시스템(Event Channel)을 통해 pub-sub 구조를 확장하게 됩니다.

 

3.2 단일 메시지 큐의 한계

RabbitMQ로 대표되는 단일 서버의 message Queue로 message(event) broker 역할을 수행할 수 있습니다. 다만, 단일 message queue로는 다음과 같은 한계가 있습니다.

• 단일 서버의 용량 한계
• 트래픽 급증 시 대응 부족
• 장애 복원력(HA) 부족

 

3.3 분산 메시지 큐의 등장

이러한 한계를 극복하기 위해 등장한 것이 분산 메시지 큐입니다. 대표적인 예로 Apache Kafka가 있습니다.

• 여러 대의 브로커 서버로 클러스터 구성
• 수평 확장(Scale-out) 으로 늘어나는 트래픽, 데이터 등의 대응 가능
• 고가용성(HA) 및 장애 복구(Fault Tolerance) 지원
• 단, 순서 보장에는 제한이 있음

분산 메시지 큐의 도입으로 인해, 대용량의 이벤트 데이터를 빠르게 처리할 수 있는 스트리밍 플랫폼 구축이 가능해졌습니다.

 

 

마무리

스트리밍 데이터와 이벤트 기반 아키텍처는 단순한 기술 트렌드를 넘어, 현대 서비스 아키텍처의 필수 요소가 되었습니다. 실시간성과 유연성을 확보하기 위해 많은 기업들이 Kafka와 같은 분산 메시지 시스템을 도입하고 있으며, 비즈니스 민첩성과 시스템 확장성 모두를 잡기 위한 핵심 전략으로 자리 잡고 있습니다.

 

다음 포스팅에서는 대표적인 분산 메시지 큐 서비스인 Kafka에 대해 본격적으로 알아보겠습니다.