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

이벤트 스트림 처리(ESP)의 핵심 기능인 이벤트 스트리밍은 이벤트나 변경 사항이 발생하는 즉시 데이터를 처리하여 IT 인프라가 대규모의 연속적인 이벤트 스트림을 처리할 수 있도록 지원합니다. 이벤트 스트리밍과 스트림 처리는 서로 다른 개념입니다. 이벤트 스트리밍은 이벤트를 전송하고 저장하는 데 필요한 인프라를 제공합니다. 반면 스트림 처리는 이러한 이벤트에 필터링, 집계 또는 데이터 보강 작업을 수행할 수 있습니다.

이벤트 스트리밍은 대규모의 정적 데이터세트, 즉 "저장 데이터"를 처리하는 배치 처리와 상호 보완적으로 사용되는 경우가 많습니다. 하지만 이벤트 스트리밍은 범위가 정해진 데이터를 일괄적으로 처리하는 대신, 지속적으로 유입되는 데이터를 양의 제한 없이 처리할 수 있습니다. 이러한 방식으로 아키텍처 내의 소프트웨어는 "이동 중인 데이터"인 데이터 스트림을 실시간으로 해석하고 대응할 수 있습니다.

고성능 이벤트 스트리밍 서비스는 주가나 제품 가격이 변동할 때 알림을 보내는 간단한 기능부터 복잡한 워크로드까지 다양한 작업을 지원할 수 있습니다. 또한 의심스러운 사용자 활동을 탐지하는 인공지능(AI) 및 실시간 머신러닝 모델도 지원할 수 있습니다.

일괄 처리의 경우에도 이벤트 스트리밍은 이벤트를 각각의 타임스탬프와 연결하여 데이터 분석에 깊이를 더할 수 있습니다. 그리고 과거 추세를 파악하여 시간이 흐를 수록 귀중한 인사이트를 얻을 수도 있습니다.

이벤트 스트리밍의 핵심은 "이벤트"라고 하는 데이터 레코드가 제한 없이 지속적으로 흐르는 것입니다. 이벤트는 시스템이나 환경에서 발생하는 모든 상황을 기록하는 기본 데이터 구조입니다. 이벤트는 주문 접수나 결제 승인과 같이 특정 상황이 발생했다는 사실을 기록한 변경 불가능한 레코드입니다. "스트림"은 데이터 스트림 또는 스트리밍 데이터라고도 하며, 이러한 이벤트가 지속적으로 전달되는 것을 의미합니다.

각 이벤트는 일반적으로 이벤트 자체나 이벤트와 관련된 엔티티를 식별하는 키와 실제 이벤트 데이터를 담고 있는 값으로 구성됩니다. 또한 이벤트가 발생하거나 기록된 시간을 나타내는 타임스탬프가 포함되며, 경우에 따라 데이터 소스, 스키마 버전 또는 기타 속성에 관한 메타데이터도 포함됩니다.

전용 스트림 처리 엔진을 사용하면 스트림 내의 이벤트에 다양한 처리 작업을 수행할 수 있습니다. "집계"는 평균, 합계, 표준편차 등의 데이터 계산을 수행합니다. "수집"은 스트리밍 데이터를 데이터베이스에 추가하는 작업입니다. 분석 처리는 스트리밍 데이터에서 발견한 패턴을 활용해 향후 이벤트를 예측하며, 데이터 보강 처리는 데이터 포인트를 다른 데이터 소스와 결합해 맥락을 제공하고 의미를 부여합니다.

조직에서 대량의 이벤트 데이터가 생성됨에 따라 실시간 분석을 활용하면 패턴, 이상 징후, 추세가 나타나는 즉시 이를 파악할 수 있습니다. AI는 이러한 실시간 인사이트를 바탕으로 이벤트 스트림 내의 복잡한 관계를 파악하고, 예측 결과를 생성하며, 필요한 조치를 추천합니다.

이러한 기능은 AI 시스템의 필수 요건으로 자리 잡고 있습니다. IDC에 따르면 에이전틱 AI 사용 사례의 80%에는 실시간으로 제공되고 맥락 정보가 포함되어 있으며 폭넓게 액세스할 수 있는 데이터가 필요합니다. 분석, AI, 자동화된 워크플로 중 무엇을 지원하든 이러한 시스템은 조직 전반의 활동을 나타내는 이벤트가 지속적으로 전달되는 데 의존합니다.

이벤트는 비즈니스 운영이나 사용자의 서비스 이용 과정과 관련되어 있으며, 일반적으로 다른 작업이나 프로세스 또는 일련의 이벤트를 트리거합니다. 온라인 뱅킹을 예로 들어보겠습니다. 사용자가 한 은행 계좌에서 다른 계좌로 돈을 보내기 위해 "이체"를 클릭하면 송금인의 계좌에서 해당 금액이 출금되고 수취인의 계좌에 입금됩니다. 이후 송금인이나 수취인 또는 양쪽 모두에게 이메일이나 SMS 알림이 전송되며, 필요한 경우 보안 및 사기 방지 프로토콜이 실행됩니다.

이벤트는 이벤트 스트리밍의 핵심 구성 요소입니다. 그러나 스트리밍 서비스는 다른 구성 요소 세트를 통해 이벤트를 빠르고 효과적으로 처리할 수 있습니다. 다른 중요한 구성 요소는 다음과 같습니다.

브로커는 생산자로부터 이벤트를 수신해 정리하고 저장한 다음, 소비자가 이를 이용할 수 있도록 제공합니다. 브로커는 중개자 역할을 하므로 생산자와 소비자가 직접 연결되지 않고도 통신할 수 있으며, 각각 독립적으로 운영하고 확장할 수 있습니다. 

분산 이벤트 스트리밍 시스템에서 브로커는 여러 노드에 이벤트를 복제하여 짧은 지연 시간과 고가용성을 보장합니다. 브로커는 클러스터를 구성할 수도 있습니다. 클러스터는 여러 브로커가 함께 작동하는 구조로, 부하 분산과 확장성을 더욱 쉽게 구현할 수 있습니다.

토픽은 이벤트가 게시되는 카테고리 또는 피드 이름으로, 플랫폼 내에서 이벤트를 정리하고 필터링할 수 있는 방법을 제공합니다. 이는 이벤트의 '주제' 역할을 하여 소비자가 토픽을 구독하고 관련 이벤트만 수신할 수 있도록 합니다.

토픽을 파티션으로 더 나눌 수 있으므로 여러 사용자가 각 파티션의 순서를 방해하지 않고 동시에 하나의 토픽을 읽을 수 있습니다.

오프셋은 파티션 내의 각 이벤트에 대한 고유 식별자로, 시퀀스 내에서 이벤트의 위치를 표시합니다. 소비자는 오프셋을 사용하여 처리한 이벤트를 구성합니다. 예를 들어 소비자가 이벤트에서 연결을 끊었다가 나중에 다시 연결하면 마지막으로 알려진 오프셋부터 처리를 재개할 수 있습니다.

데이터 급증과 그에 따른 데이터 트래픽 급증으로 인해 이벤트 스트리밍은 최신 데이터 아키텍처의 필수 구성 요소가 되었습니다. 이는 빠른 의사 결정 기능이 필요한 환경이나 의사 결정 책임을 자동화하려는 조직에 중요합니다.

이벤트 스트리밍 서비스가 이벤트 데이터를 관리하는 방법은 다음과 같습니다.

1. 이벤트 생성. 이벤트 스트리밍은 생산자(예: 마이크로서비스 백엔드 시스템, IoT 에코시스템 또는 이벤트 기반 API)가 이벤트 스트리밍 플랫폼에 이벤트를 전송하면서 시작됩니다.
   
   
2. 이벤트 게시. 프로듀서는 클라이언트 라이브러리를 사용하여 플랫폼 내의 특정 토픽에 이벤트를 게시하고, 이때 소비자(토픽을 구독하는 앱 및 서비스)는 이벤트를 사용할 수 있습니다.
   
   
3. 이벤트 저장. 플랫폼은 이벤트를 미리 정해진 기간 동안 저장하며, 브로커는 이벤트의 저장 및 검색 프로세스를 관리합니다.
   
   
4. 이벤트 사용. 소비자는 이벤트 데이터를 처리하여 다른 이벤트를 시작합니다. 목적이나 구성에 따라 이벤트가 도착하는 즉시 조치를 취하거나(실시간 처리), 나중에 처리할 수 있도록 저장하거나, 일괄 처리를 위해 컴파일할 수 있습니다. 또한 소비자는 오프셋을 사용하여 데이터 파이프라인에서 자신의 위치를 추적하므로 장애가 발생하거나 다시 시작될 경우 중단한 부분부터 처리를 재개할 수 있습니다.
   
   
5. 이벤트 전달. 이벤트 브로커는 소비자가 이벤트를 이용할 수 있도록 제공합니다. 브로커는 "최소 1회" 전달 시맨틱을 통해 이벤트 전달을 보장할 수 있습니다. 이 방식은 이벤트가 중복되더라도 모든 이벤트가 목적지에 도달하도록 보장합니다. 또한 각 이벤트가 정확히 한 번만 전달되도록 보장하는 "정확히 1회" 전달 방식이나 다른 유형의 시맨틱을 사용할 수도 있습니다.
   
   
6. 이벤트 처리. 초기 이벤트가 소비되고 전달되면 데이터 변환, 집계, 복합 이벤트 처리(CEP) 워크플로 트리거 등 여러 후속 작업을 위해 이벤트 데이터가 처리됩니다. 조직은 일반적으로 Apache Flink, Apache Spark Structured Streaming, Kafka Streams 등의 스트림 처리 기술을 사용해 분산 이벤트 기반 시스템 전반에서 이러한 작업을 실시간으로 수행합니다. 이렇게 생성된 실시간 데이터 스트림은 AI 시스템이 실시간 의사결정을 지원하는 데 필요한 데이터를 지속적으로 제공할 수도 있습니다.

이벤트 스트리밍은 일반적으로 여러 시스템에서 지속적으로 생성되는 이벤트 데이터 스트림을 수집, 저장, 처리, 배포하도록 설계된 분산 아키텍처로 구현됩니다. 이벤트 스트리밍 아키텍처는 직접적인 지점 간 연결에 의존하는 대신, 공유 인프라를 통해 데이터 생산자와 소비자를 분리합니다. 이를 통해 애플리케이션을 독립적으로 확장하고 실시간으로 정보를 교환할 수 있습니다. 이러한 프레임워크를 구현하는 데는 다음과 같은 핵심 아키텍처 구성 요소가 필요합니다.

대부분의 이벤트 스트리밍 아키텍처에서 핵심 구성 요소는 이벤트 브로커입니다. 이벤트 브로커는 이벤트 데이터를 처리하기 위한 내구성과 확장성을 갖춘 기반 역할을 합니다. 이벤트는 분산 로그 내의 토픽에 기록되며, 수신된 순서대로 저장되어 나중에도 소비할 수 있도록 유지됩니다.

이 아키텍처에서는 여러 애플리케이션이 데이터를 생성한 시스템과 직접 통합하지 않고도 동일한 이벤트 스트림에 독립적으로 액세스할 수 있습니다. 이러한 기능은 일반적으로 Apache Kafka, Amazon Kinesis, Apache Pulsar 등의 기술을 통해 제공됩니다.

대규모 워크로드를 지원하기 위해 이벤트 스트림은 일반적으로 토픽으로 구성되며, 여러 서버에 분산할 수 있는 파티션으로 나뉩니다. 파티셔닝은 병렬 처리를 지원하고 처리량을 높이며, 복제는 여러 노드에 데이터 사본을 생성하여 개별 구성 요소에 장애가 발생하더라도 내결함성과 가용성을 높입니다.

이벤트 스트리밍 아키텍처는 데이터를 생성하는 시스템과 데이터를 사용하는 시스템을 분리합니다. 생산자는 토픽에 이벤트를 게시하고, 소비자는 해당 토픽을 구독하여 이벤트를 독립적으로 처리합니다. 이러한 분리형 설계 덕분에 데이터를 생성하는 시스템을 수정하지 않고도 새로운 애플리케이션과 서비스를 추가할 수 있습니다.

많은 이벤트 스트리밍 아키텍처에는 이벤트가 시스템을 통과하는 동안 이를 분석하고 변환하는 스트림 처리 계층이 포함되어 있습니다. 대표적인 스트림 처리 기술로는 Apache Flink, Kafka Streams, ksqlDB, Apache Spark Structured Streaming 등이 있습니다. 이러한 기술은 지속적으로 유입되는 데이터에 대한 필터링, 데이터 보강, 조인, 집계 등의 작업을 지원합니다.

일부 스트리밍 워크로드에서는 애플리케이션이 과거 이벤트에 관한 정보를 유지해야 합니다. 예를 들어 전자상거래 플랫폼은 지난 한 시간 동안 발생한 모든 구매 내역을 분석하여 인기 상품을 파악하고 추천 상품을 거의 실시간으로 업데이트할 수 있습니다. 상태 관리를 통해 시스템은 이러한 정보를 지속적으로 보관하고 업데이트할 수 있으며, 윈도잉은 연속적인 데이터 스트림을 시간 또는 이벤트 기준의 구간으로 나누어 분석할 수 있도록 합니다.

이벤트 스트리밍 아키텍처에는 일반적으로 데이터 손실을 방지하고 장애 복구를 지원하는 메커니즘이 포함되어 있습니다. 애플리케이션 요구사항에 따라 시스템은 최대 1회, 최소 1회 또는 정확히 1회 처리를 보장할 수 있습니다. 체크포인팅, 복제, 소비자 오프셋 추적은 서비스 중단이나 시스템 재시작 시 데이터 일관성을 유지하는 데 도움이 됩니다.

처리된 이벤트는 일반적으로 데이터베이스, 데이터 웨어하우스, 데이터 레이크, 검색 인덱스, 머신러닝 시스템 또는 다른 이벤트 스트림과 같은 다운스트림 대상으로 전달됩니다. 이러한 통합을 통해 이벤트 데이터를 실시간 분석, 운영 애플리케이션, 자동화 워크플로, AI 애플리케이션에 활용할 수 있습니다.

Amazon Kinesis, Google Cloud Pub/Sub, Azure Event Hubs, IBM® Event Automation 등의 이벤트 스트리밍 플랫폼은 기본적인 스트리밍 및 처리 외에도 기능을 강화하는 다양한 스트리밍 방식을 지원합니다. 특히 IBM Event Automation은 오픈 소스 Apache Kafka 플랫폼의 처리 성능을 활용해 이벤트 기반 워크플로를 최적화합니다. 이러한 기능은 조직이 분석 및 AI 시스템에 필요한 실시간 데이터 파이프라인을 구축하고 제공하는 데도 도움이 됩니다.

정확히 1회 처리는 스트림의 각 이벤트를 정확히 한 번만 처리하는 방식으로, 이벤트가 중복 처리되거나 누락되는 것을 방지하는 데 필수적인 기능입니다. 대부분의 이벤트 스트리밍 시스템에는 시스템의 다른 부분에서 장애가 발생하더라도 정확히 1회 처리 시맨틱을 보장하는 메커니즘이 포함되어 있습니다.

다운스트림 구성 요소가 유입되는 이벤트의 속도를 따라가지 못할 때 백프레셔는 스트림으로 인해 시스템에 과부하가 발생하는 것을 방지합니다. 데이터 흐름 제어 메커니즘인 백프레셔를 통해 소비자는 데이터 처리 부담이 너무 크거나 유입되는 이벤트를 처리하는 속도가 따라가지 못할 경우 생산자에게 데이터 생성 속도를 줄이거나 생성을 중단하도록 신호를 보낼 수 있습니다.

이 프로세스를 통해 시스템은 전체 시스템의 운영을 중단하는 대신 유입되는 이벤트를 버퍼링하거나 삭제하여 워크로드를 원활하게 처리할 수 있으며, 워크로드가 변동하더라도 이벤트 처리를 안정적으로 유지할 수 있습니다.

이벤트 소비자는 이벤트 소비 속도를 높이기 위해 소비자 그룹의 일원으로 작동하는 경우가 많습니다. 소비자 그룹의 각 소비자에게는 파티션의 일부가 할당되므로 병렬로 이벤트를 소비하여 효율성을 높일 수 있습니다. 그룹 내 소비자 중 하나에 장애가 발생하거나 소비자를 추가 또는 제거해야 하는 경우, 플랫폼은 파티션을 동적으로 재할당하여 부하 균형과 내결함성을 유지할 수 있습니다.

이벤트 스트리밍에서는 데이터를 적시에 처리하는 것이 중요한 경우가 많습니다. 워터마크는 이벤트 시간이 얼마나 진행되었는지에 대한 시스템의 추정값입니다. 워터마킹은 시스템이 이벤트 데이터의 처리가 완료되었다고 판단할 수 있는 시점을 나타내는 완료 기준을 적용합니다. 또한 시간 기반 처리의 정확성을 보장하고 순서가 뒤바뀐 이벤트를 조정하는 데도 유용합니다.

대부분의 이벤트 스트리밍 플랫폼은 개발자가 이벤트를 소비할 수 있는 기간을 제어할 수 있는 사용자 지정 가능한 데이터 보존 정책을 제공합니다. 그러나 데이터 압축은 토픽에서 중복되거나 더 이상 사용되지 않는 데이터를 제거하여 필수 데이터는 보존하면서 스토리지 공간을 최소화하는 프로세스입니다.

다시 한번 강조하자면, 표준 스트리밍 아키텍처는 일반적으로 이벤트 생산자, 이벤트 브로커, 소비자를 분리하여 각 구성 요소를 독립적으로 확장하고 유지 관리할 수 있도록 합니다. 이러한 유연성을 바탕으로 기업은 실시간 분석, AI 기반 의사결정, 자동화된 워크플로를 비롯한 다양한 다운스트림 애플리케이션을 지원할 수 있습니다. 이러한 유연성을 바탕으로 기업은 실시간 분석, AI 기반 의사결정, 자동화된 워크플로를 비롯한 다양한 다운스트림 애플리케이션을 지원할 수 있습니다.

이벤트 스트리밍과 배치 처리의 차이점은 이벤트 스트리밍은 이벤트가 발생하는 즉시 데이터를 지속적으로 처리하는 반면, 배치 처리는 누적된 데이터를 주기적으로 또는 특정 조건이 충족되었을 때 처리한다는 것입니다.

이벤트 스트리밍과 배치 처리는 모두 데이터를 이동하고 처리하지만, 데이터를 처리하는 시점과 방식에서 주로 차이가 있습니다. 이벤트 스트리밍은 애플리케이션, 데이터베이스, IoT 디바이스 등의 소스에서 이벤트가 발생하는 즉시 이를 지속적으로 수집하고 전송합니다. 시스템은 전체 데이터세트가 완성될 때까지 기다리지 않고 개별 이벤트나 소규모 이벤트 그룹이 유입되는 즉시 처리하므로 지연 시간이 짧은 분석과 대응이 가능합니다.

이 방식은 데이터의 최신성이 데이터의 가치를 좌우하는 사용 사례에 적합합니다. 대표적인 예로는 사기 탐지, 운영 모니터링, 실시간 추천, 최신 정보에 의존하는 AI 시스템 등이 있습니다.

배치 처리는 정해진 기간 동안 데이터를 수집한 다음, 이를 하나의 독립적인 워크로드로 묶어 처리합니다. 결과를 즉시 생성할 필요가 없으므로 배치 처리는 일일 보고서 생성, 계정 대사, 분석 대시보드 업데이트 등의 작업에 적합합니다.

또한 두 방식은 상호 배타적이지 않고 서로 보완하는 관계입니다. 예를 들어 조직은 이벤트 스트리밍을 사용해 활동이 발생하는 즉시 이를 탐지하고 대응한 다음, 배치 처리를 통해 누적된 데이터를 종합적으로 분석하여 과거 추세를 파악할 수 있습니다.

이벤트 스트리밍은 조직이 생성된 데이터를 사용하여 보다 응답성이 뛰어나고 지능적인 시스템을 만들 수 있는 강력한 개념입니다. 데이터 기반 의사 결정이 부상하면서 이벤트 스트리밍은 최신 소프트웨어 아키텍처에서 점점 더 중요한 구성 요소로 자리 잡고 있습니다.

따라서 이벤트 스트리밍 기술은 다음과 같은 비즈니스 부문 전반에 걸쳐 다양한 사용 사례를 가지고 있습니다.

이벤트 스트리밍은 특정 산업 분야뿐 아니라 다른 기술 및 아키텍처와 함께 사용할 때도 유용합니다. 예를 들어 이벤트 스트리밍은 이벤트 소싱 및 명령 쿼리 책임 분리(CQRS)와 같은 패턴과 연계되기도 합니다.

이벤트 소싱은 애플리케이션 상태의 변경 사항을 일련의 이벤트로 저장하는 아키텍처 패턴입니다. 이벤트 스트림과 함께 이벤트 소싱을 사용하면 스트리밍 시스템에서 이벤트를 재생할 수 있습니다. 이 기능을 통해 특정 시점의 엔티티 상태를 재구성하거나 시스템의 다른 구성 요소를 구동할 수 있습니다.

CQRS 아키텍처 패턴에서 시스템은 명령을 처리하는 모델(쓰기)과 쿼리를 처리하는 모델(읽기)의 두 가지 모델로 나뉩니다. 이벤트 스트리밍은 CQRS에서 쓰기 모델의 변경 사항을 읽기 모델로 실시간으로 전파하는 데 사용할 수 있으므로 둘 간의 비동기 통합이 가능합니다.

이벤트 스트리밍은 이벤트 기반 아키텍처를 구축하는 데 필요한 기반 기술이기도 합니다. 이벤트 기반 아키텍처에서는 느슨하게 결합된 구성 요소들이 이벤트를 통해 서로 통신할 수 있습니다. 이벤트 스트림을 브로커에 게시하는 대신, 다른 애플리케이션이나 서비스가 이를 받아 후속 작업을 수행할 수 있도록 특정 목적의 이벤트를 게시합니다.

이벤트 스트리밍 기능과 함께 사용되는 이벤트 기반 아키텍처의 스트림 내 처리 성능을 활용하면 기업은 이동 중인 데이터에 대응하고 현재 및 과거 데이터를 바탕으로 신속하게 의사결정을 내릴 수 있습니다. 이러한 실시간 대응 능력은 지속적으로 업데이트되는 데이터에 의존하는 분석 및 AI 애플리케이션도 지원합니다.

최근 몇 년 동안 클라우드 제공업체들은 이벤트 스트리밍의 원칙을 서비스 형태로 제공하기 시작했습니다. 서비스형 이벤트 스트리밍을 이용하면 기업은 기반 인프라 전체를 직접 관리하지 않고도 이벤트 스트리밍을 더 쉽게 도입할 수 있어 이벤트 스트리밍의 활용 범위가 더욱 확대됩니다.