이벤트 기반 아키텍처란?

이를 통해 팀은 시스템 이벤트(기본적으로 시스템 내에서 발생하는 모든 변경 또는 작업)를 식별하고 이에 실시간(또는 거의 실시간)으로 응답하고 대응할 수 있습니다.

클라우드 네이티브 환경 전반에 걸친 EDA의 확산은 기존 컴퓨팅 아키텍처(서비스 지향 아키텍처처럼 데이터 레이크와 같은 저장소에 정적 데이터를 비축하는 데 중점)에서 벗어나, 아키텍처를 가로지르면서 데이터를 추적하는 동적 접근 방식으로 중대한 전환이 이루어졌음을 나타냅니다. 이벤트 기반 시스템에서 데이터는 여전히 중요하지만, EDA는 시간이 지날 수록 이벤트의 가치가 감소할 수 있음을 인정하며 이벤트에 대한 시기적절한 대응을 강조합니다.

EDA 프레임워크에서 이벤트 생산자(예: 마이크로서비스, API, IoT 장치)는 이벤트 소비자에게 실시간 이벤트 알림을 전송해서 특정 처리 루틴을 활성화합니다. 예를 들어 넷플릭스에서 새 오리지널 시리즈를 출시하면 여러 EDA 서비스가 출시 알림을 대기하고 있다가 연쇄적으로 업데이트를 트리거하여 사용자에게 알립니다.

이벤트 기반 아키텍처의 주된 장점 중 하나는 프론트엔드 구성 요소와 백엔드 구성 요소 간의 관계가 분리되어 있는 것입니다. 덕분에 시스템들이 서로에 대해 알지 못하는 상태에서 정보를 공유할 수 있습니다. 생산자는 어느 소비자가 이벤트를 수신할지 모르는 상태에서 이벤트를 보내고, 소비자는 생산자에게 요청을 보내지 않고도 이벤트를 수신할 수 있습니다. 다시 말해 EDA를 사용하면 시스템을 개별적으로 가동하고 이벤트를 비동기식으로 처리할 수 있습니다.

현대 사회의 미래 지향적인 기업들은 방대한 디지털 발자국을 보유하고 있으며 이벤트 기반 시스템의 실시간 기능을 통해 유휴 시간 없이 운영 준비 상태를 유지하고 이벤트 브로드캐스트에 신속하게 대응합니다. 이렇게 해서 EDA는 기업이 공급망 최적화부터 품질 문제 선제 파악에 이르기까지 다양한 조직 프로세스를 자동화하고 궁극적으로 매출과 수익을 모두 개선하는 데 도움을 줍니다.

이벤트 스트리밍은 시스템 또는 환경에서 발생하거나 수정되는 모든 상황을 기록하는 기본 데이터 구조인 '이벤트'라고 하는 데이터 레코드의 무제한, 순차적 실시간 흐름을 중심으로 이루어집니다. 수정의 예로는 사용자가 전자 상거래 사이트 장바구니에 상품을 담는 것, 비밀번호 재설정이나 애플리케이션 상태 변경을 요청하는 것이 있습니다. 이는 본질적으로 시스템의 모든 데이터 포인트를 가리키는 용어입니다. 그리고 '스트림'(데이터 스트림 또는 스트리밍 데이터라고도 함)은 이러한 이벤트의 지속적인 전송을 의미합니다.

각 이벤트는 일반적으로 이벤트 또는 이벤트와 관련된 엔티티를 식별하는 키, 이벤트의 실제 데이터를 보유하는 값, 이벤트가 발생하거나 기록된 시기를 나타내는 타임스탬프, 때로는 이벤트 소스, 스키마 버전 또는 기타 속성에 대한 메타데이터로 구성됩니다. 이들은 상태 데이터(예: 구매한 품목, 가격, 배송 주소)를 전달하거나 식별자(배송 알림) 역할을 할 수 있습니다.

특수 스트림 처리 엔진의 도움으로 이벤트는 스트림 내에서 몇 가지 다른 프로세스를 거칠 수 있습니다. '집계'는 평균, 합계 및 표준 편차와 같은 데이터 계산을 수행합니다. '수집'은 데이터베이스에 스트리밍 데이터를 추가합니다. 분석 처리는 스트리밍 데이터의 패턴을 사용하여 향후 이벤트를 예측하고, 보강 처리는 데이터 포인트를 다른 데이터 소스와 결합하여 컨텍스트를 제공하고 의미를 생성합니다.

이벤트는 비즈니스 운영 또는 사용자 탐색 프로세스와 연결되는 경우가 많으며 일반적으로 다른 작업, 프로세스 또는 일련의 이벤트를 트리거합니다. 온라인 뱅킹을 한 가지 예로 들어보겠습니다. 사용자가 한 은행 계좌에서 다른 은행 계좌로 돈을 보내기 위해 '이체'를 클릭하면, 송금인의 계좌에서 자금이 인출되어 수취인의 은행 계좌에 추가되고, 이메일 또는 SMS 알림이 한쪽(또는 양쪽) 당사자에게 전송되며, 필요한 경우 보안 및 사기 방지 프로토콜이 배포됩니다.

이벤트 외에도 EDA는 세 가지 기본 구성 요소를 사용하여 아키텍처를 통해 이벤트 데이터를 이동합니다.

• 이벤트 생산자(또는 게시자): 생산자는 이벤트의 원천입니다. 이벤트를 생성하여 시스템의 나머지 부분으로 보냅니다. 생산자는 사용자 인터페이스, 센서, 서비스, 그 밖에 시스템의 다른 부분에 대한 관심 상태 변경을 감지하거나 생성하는 시스템일 수 있습니다. 생산자는 이벤트 생성을 담당하지만 이벤트 처리 기능은 없습니다.

• 이벤트 소비자(또는 구독자): 소비자가 EDA에서 이벤트 처리 작업을 처리합니다. 이들은 이벤트 채널을 듣고 있다가 관심 있는 이벤트가 게시되면 반응합니다. 이 반응은 데이터베이스 업데이트, 다운스트림 프로세스 트리거, 단순 로깅 등 다양한 형태를 취할 수 있습니다.

• 이벤트 라우터 (또는 이벤트 오케스트레이터): 라우터 또는 오케스트레이터는 프런트 엔드 이벤트 생산자를 백엔드 이벤트 소비자로부터 분리하는 브로커로, 이벤트가 전달되는 통로 역할을 하므로 개체 간에 직접 연결할 필요 없이 전송이 보장됩니다. 라우터는 기존 구성 요소(예: SaaS와 같은 메시지 지향 미들웨어)를 기반으로 할 수 있으며 다양한 메시징 시스템(메시지 대기열, 구독하기/게시 모델, 이벤트 스트림 등)에서 유용하게 사용할 수 있습니다.

EDA에서 이벤트 기반 애플리케이션은 생산자 또는 소비자(때로는 둘 다)로 동작합니다.

앱이나 서비스는 다른 앱이나 서비스가 알고 싶어할 수도 있는 작업을 수행할 때 새로운 이벤트(해당 작업이나 변경 내용 기록)를 게시합니다. 그러면 다른 서비스가 다른 작업을 수행할 때 이 이벤트를 소비하고 처리할 수 있습니다.

그런 다음 이벤트 생산자는 이벤트 형식을 브로커 또는 다른 유형의 이벤트 라우터로 전송하여, 해당 이벤트가 다른 이벤트들과 연관되어 있는 시간 순서를 유지합니다. 이벤트 소비자는 메시지를 실시간으로(발생 즉시), 또는 이후의 관련된 인스턴스에서 수집하고 메시지를 처리하여 다른 작업이나 워크플로, 자체 이벤트를 트리거합니다.

간단한 예로 은행 서비스는 다른 은행 서비스가 고객의 명세서에 예금을 작성하여 소비하고 응답하는 '예금' 이벤트를 전송할 수 있습니다.

한편 이벤트 기반 통합은 고객이 온라인 쇼핑몰에서 제품을 클릭할 때 시스템이 다른 고객들의 구매 내역을 기반으로 즉각적인 제품 추천을 생성하는 것과 같이, 방대한 양의 데이터에 대한 복잡한 분석을 기반으로 실시간 응답을 트리거할 수도 있습니다.

이벤트 기반 아키텍처는 클라우드 네이티브 애플리케이션의 잠재력을 극대화하고 실시간 분석 및 의사 결정 지원과 같은 강력한 앱 기술을 지원합니다. 전반적으로 한 앱이 다른 앱에서 특정 정보를 요청하고 다음 작업으로 이동하기 전에 응답을 기다려야 하는 기존의 '요청/응답' 아키텍처를 대체합니다.

그러나 'EDA'는 여러 아키텍처 패턴을 포괄하는 용어이며 모두 다양한 목적에 맞춰 사용할 수 있습니다.

게시/구독 모델은 객체들 간의 일대다 종속성과 게시자(이벤트 생산자)와 소비자 간의 분리된 비동기 관계로 정의됩니다. 이 모델에서 게시자는 구독자에 대해 알 필요가 없이, 개별 구독자가 실시간으로 이벤트를 듣고 반응하는 공유 이벤트 채널에 이벤트를 게시합니다.

일반적으로 메시지 브로커(라우터)는 게시자와 구독자 간의 이벤트 메시지 전송을 처리합니다. 브로커는 이벤트 메시지 각각을 수신해서 필요에 따라 변환하고, 다른 메시지들과의 순서를 유지하고, 구독자가 사용할 수 있게 만든 다음 한 번 소비되면 삭제합니다(다시 사용할 수 없게 만듦).

게시/구독 메시징 패턴은 대규모 코드베이스가 있는 기업과 여러 소비자에게 정보를 방송하는 데 이상적입니다(예: 알림 시스템 및 실시간 데이터 피드).

게시/구독과 마찬가지로 이벤트 스트리밍은 발행자와 소비자를 분리하여 비동기 통신을 구현합니다. 그러나 이벤트 스트리밍 모델에서 이벤트 소비자는 스트림을 구독하지 않아도 됩니다. 오히려 생산자가 이벤트 스트림을 브로커 로그에 게시하고, 소비자는 언제든 각 스트림에 진입해서 원하는 이벤트만 소비할 수 있습니다(게시되는 이벤트를 전부 수신하고 소비하지 않음).

그러나 이벤트 스트리밍 브로커는 게시/구독과 달리, 소비자가 이미 수신한 이벤트도 유지합니다.

소비자는 게시된 이벤트를 언제든 처리할 수 있기 때문에 이벤트 스트리밍 레코드가 영구적으로, 다시 말해 구성 가능한 시간(몇 초~영원히) 동안 유지됩니다. 소비자는 언제든 스트림에 접속해서 최근 메시지를 읽거나, 마지막 스트림 접속 시점 이후로 받은 메시지들을 일괄 처리하거나, 최근 받은 관련 메시지를 참고할 수 있습니다.

이벤트 스트리밍 기술(예: Apache Kafka, Amazon Web Services (AWS) Kinesis, IBM® Event Automation)은 풀 모델(소비자가 이벤트에 열려 있다고 표시할 때만 브로커가 소비자 데이터를 전송)과 푸시 모델(브로커의 비즈니스 로직에 따라 이벤트를 수신할 소비자가 지정됨)로 구성됩니다.

이벤트 스트리밍 패턴은 실시간 이벤트 업데이트와 과거 이벤트에 대한 액세스가 모두 필요한 앱(예: 금융 기관의 사기 탐지 시스템)에 가장 유용합니다.

두 가지 기본 EDA 아키텍처 패턴과 더불어 구독자에게 도착한 이벤트가 처리되는 방식을 제어하는 세 가지 디자인 패턴이 있습니다.

• 단순 이벤트 처리: 소비자가 게시자에게서 받은 이벤트를 정확하게 처리하여 즉각적인 조치를 트리거합니다.

• 이벤트 스트림 처리(ESP): 데이터 스트리밍 플랫폼이 이벤트를 수집하고 스트림 프로세서를 위한 파이프라인을 구축한 다음 스트림을 처리하고 변환합니다.
  
  
• 복잡한 이벤트 처리(CEP): 소비자가 일련의 이벤트를 처리하여 데이터의 추세와 패턴을 식별합니다.

세 가지 처리 패턴 모두 (특히) 게시/구독과 이벤트 스트리밍 아키텍처 패턴에 모두 사용할 수 있지만 ESP는 (단연) 이벤트 스트리밍 아키텍처 패턴에서 가장 일반적입니다.

EDA는 다양한 영역의 기업에 유용할 수 있지만 크고 복잡한 IT 환경을 갖춘 기업에 특히 유용합니다.

예를 들어 서로 다른 기술 스택에서 실행되는 시스템들을 통합할 때 이벤트 기반 아키텍처의 분리 기능을 사용하면 시스템에 구애받지 않고 이벤트 데이터의 상호 운용성을 향상시킬 수 있습니다. 다국적 기업은 EDA를 사용하여 계정과 지역 간에 시스템을 조정하고 아키텍처의 여러 부분을 개별적으로 확장할 수 있습니다. 또한 이벤트의 서로 다른 부분을 처리하는 시스템을 실행한다면 EDA의 팬아웃 기능을 사용해 시스템 전체에서 병렬 처리를 위한 새 코드 없이도 소비자 각각에게 이벤트를 푸시할 수 있습니다.

전자 상거래에서 이벤트 기반 아키텍처는 실시간으로 이벤트를 필터링하고 라우팅하여 데이터에 관심이 있는 구독자에게만 전달되게 할 수 있습니다. 신규 구매는 주문 처리 소비자에게 직접 전달되고, 주문 문제는 고객 서비스 채널로 직접 라우팅됩니다.

이벤트 기반 아키텍처는 현대 사회의 기업이 시장에 발맞추고 미래로 나아가는 데 필수 요건이 되고 있습니다. 실제로 조직의 26%가 비즈니스 요건을 충족하기 위해 EDA를 채택할 계획이며, 이미 채택한 조직도 37%에 육박합니다.¹ 그리고 EDA 소프트웨어 산업은 2027년까지 매출을 두 배로 끌어올리며 165억 달러 이상으로 성장할 것으로 예상됩니다.²

매일 수천 개의 비즈니스 이벤트가 조직의 모든 부분을 통과하며, 이러한 이벤트는 비즈니스 전반에서 일어나는 일에 대해 풍부한 정보를 제공합니다. 그러나 적절한 기술이 없어 이 데이터를 처리하고 사용하여 고객, 제품, 사업에 관련해 근거 있는 판단을 내리지 못하는 기업이 많습니다.

EDA 플랫폼은 처리량이 크고 지연 시간이 짧게 자동화를 할 수 있고, 다음과 같이 다양한 사용 사례에 고급 도구를 제공한다는 점에서 매우 중요합니다.

이벤트 기반 아키텍처는 사용자가 새로운 상황을 감지하고, 실시간으로 행동하고, 의사를 결정하고, 수익 잠재력을 극대화할 수 있게 해서 비즈니스 이벤트를 작동시킵니다. EDA는 다음과 같은 기능을 통해 기업이 성장을 지속하고 가속화할 수 있도록 지원하기도 합니다.

EDA를 사용하면 서비스 인스턴스를 더 많이 추가해서 늘어난 워크로드를 처리하며 시스템을 확장할 수 있습니다.

EDA를 사용하면 구성 요소가 비동기식으로 통신할 수 있습니다. 생산자는 소비자가 이벤트 메시지를 받을 때까지 기다리지 않고(또는 소비자가 메시지를 받았는지 알지 않고) 자체 일정에 따라 이벤트 메시지를 게시하여 통합과 사용자 경험을 모두 단순화합니다.

서비스를 개별적으로 추가, 제거, 수정할 수 있어 개발과 배포를 민첩하게 할 수 있습니다.

EDA는 시간과 동기화 내에서 분리됩니다. 그래서 이벤트 생산자와 소비자가 직접 API 호출이 아닌 이벤트를 통해 상호 작용하여 종속성을 줄이고 전반적인 시스템 복원력이 높아집니다.

EDA는 본질적으로 실시간 처리 및 대응을 위해 설계되어 있어, 팀이 보다 선제적으로 대응하고 보다 스마트한 조치와 자동화를 촉진할 수 있도록 합니다.