이벤트 기반 아키텍처는 이벤트 발행, 캡처, 처리, 저장(지속성)을 중심으로 하는 통합 모델입니다. 애플리케이션이나 서비스에서 어떤 작업이나 변경을 수행하는데 다른 애플리케이션이나 서비스에서 이를 알아야 하는 경우, 이벤트를 발행합니다. 이벤트는 해당 작업 또는 변경에 관한 기록이며, 다른 애플리케이션이나 서비스에서 그에 대한 작업을 수행하기 위해 소비하고 처리합니다.

이벤트 기반 아키텍처는 서로 연결된 애플리케이션과 서비스 간의 느슨한 결합을 지원합니다. 즉, 이벤트를 발행하고 소비하는 방법으로 상호 통신이 가능합니다. 이벤트 형식 이외에 상대방에 관해 아무 것도 알 필요 없습니다. 아 모델은 어떤 애플리케이션/서비스에서 다른 특정 애플리케이션/서비스에 특정 정보를 요청해야 하는 요청/응답 아키텍처(통합 모델)보다 여러모로 장점이 많습니다.

이벤트 기반 아키텍처는 클라우드 네이티브 애플리케이션의 잠재력을 극대화합니다. 그리고 실시간 분석, 의사결정 지원과 같은 강력한 애플리케이션 기술도 지원합니다.

이벤트 기반 아키텍처에서는 애플리케이션이 이벤트 생산자, 이벤트 소비자, 또는 (종종) 두 역할 모두 수행합니다.

이벤트 생산자는 이벤트를 메시지의 형태로 브로커 또는 다른 형태의 이벤트 라우터에 전송합니다. 여기서는 이벤트를 시간순으로 유지 관리합니다. 이벤트 소비자는 메시지를 수집합니다. (메시지가 생성되는 즉시) 실시간으로 수집하거나, 원하는 다른 시간에 수집한 다음 메시지 처리 과정을 거쳐 다른 작업, 워크플로우, 또는 자신의 이벤트를 트리거합니다.

단순한 예를 들자면, 뱅킹 서비스에서 '예치' 이벤트를 전송할 수 있습니다. 은행의 다른 서비스에서 이 이벤트를 소비하고, 고객의 명세서에 예치 항목을 작성하는 방식으로 응답합니다. 그러나 이벤트 기반 통합이 방대한 데이터에 대한 복잡한 분석을 토대로 실시간 응답을 트리거할 수도 있습니다. 예컨대 고객이 전자 상거래 사이트에서 어떤 제품을 클릭하는 '이벤트'가 일어나면, 다른 고객의 구매 내역을 바탕으로 즉각적인 제품 추천이 생성됩니다.

이벤트 기반 아키텍처에서 이벤트를 전송하는 데에는 2가지 기본 모델이 있습니다.

이벤트 메시징, 즉 발행/구독

이벤트 메시징, 즉 발행/구독 모델에서는 이벤트 소비자가 어떤 클래스, 즉 이벤트 생산자에 의해 발행된 메시지의 클래스를 구독합니다. 이벤트 생산자가 이벤트를 발행하면, 이를 소비하려는 모든 구독자에게 곧바로 메시지가 전송됩니다.

일반적으로 메시지 브로커가 발행자와 구독자 간의 이벤트 메시지 전송을 처리합니다. 브로커는 각 이벤트 메시지를 수신하고, 필요하다면 변환합니다. 메시지 간의 순서를 유지하면서 구독자가 소비할 수 있게 제공합니다. 그리고 소비된 메시지는 (다시 소비되는 일이 없도록) 삭제합니다.

이벤트 스트리밍

이벤트 스트리밍 모델에서는 이벤트 발행자가 브로커에 이벤트의 스트림을 발행합니다. 이벤트 소비자는 스트림을 구독합니다. 그러면 각 이벤트가 발행되는 대로 수신하고 소비하는 게 아니라, 소비자가 각 스트림에서 임의의 지점에 진입하여 소비하고 싶은 이벤트만 소비할 수 있습니다. 여기서는 소비자가 이벤트를 수신한 후에도 브로커가 이벤트를 보존한다는 것이 핵심적인 차이점입니다.

Apache Kafka와 같은 데이터 스트리밍 플랫폼에서는 방대한 이벤트 볼륨의 로깅 및 전송을 강력한 성능으로 관리합니다. 말 그대로 매일 수조 건의 이벤트 레코드를 성능 저하 없이 실시간으로 처리합니다. 스트리밍 플랫폼은 메시지 브로커와 다른 특징이 있습니다.

• 이벤트 지속성: 소비자가 이벤트 발행 후 임의의 시점에 이벤트를 소비할 수 있으므로, 이벤트 스트리밍 레코드는 지속적입니다. 구성 가능한 기간 동안 유지되는데, 1초 미만부터 무기한까지 가능합니다. 따라서 이벤트 스트림 애플리케이션에서는 과거의 데이터와 실시간 데이터를 모두 처리할 수 있습니다.
  
  
• 복잡한 이벤트 처리: 이벤트 메시징처럼 이벤트 스트리밍은 단순한 이벤트 처리에, 즉 발행된 이벤트 각각에 의해 전송이 일어나고 하나 이상의 특정 소비자가 이벤트를 처리하는 데 쓰일 수 있습니다. 그리고 복잡한 이벤트 처리에도 사용 가능합니다. 즉, 이벤트 소비자가 일련의 이벤트 전체를 처리하고, 그 결과에 따라 작업을 수행하는 것입니다.

이벤트 기반 아키텍처는 요청/응답 애플리케이션 아키텍처와 달리 몇 가지 측면에서 개발자 및 조직에 장점과 기회를 제공합니다.

강력한 실시간 응답과 분석: 이벤트 스트리밍에서는 애플리케이션이 비즈니스 상황이 바뀌면 그에 맞게 대응할 수 있습니다. 그리고 사용 가능한 모든 현재 및 과거의 데이터를 토대로 실시간 예측 및 의사결정이 가능합니다. 따라서 각종 IoT 디바이스에서 생성하는 데이터의 스트림을 처리하고, 보안 위협을 예측하여 즉시 제거하고, 공급망을 자동화하여 효율성을 극대화하는 등 무궁무진한 이점을 누릴 수 있게 됩니다.

느슨한 결합에 의한 내장애성, 확장성, 유지 보수 간소화, 다기능성, 기타 이점: 이벤트 기반 아키텍처의 애플리케이션과 컴포넌트는 다른 애플리케이션과 컴포넌트의 가용성에 의존하지 않습니다. 서비스 중단 없이 독립적으로 업데이트, 테스트, 배치할 수 있으며, 어떤 컴포넌트가 중단되더라도 백업 버전을 실행하면 됩니다. 이벤트 지속성 덕분에 과거의 이벤트를 '다시 실행'할 수 있습니다. 그러면 이벤트 소비자에 장애가 발생하더라도 데이터나 기능을 복구하는 것이 가능합니다. 각 컴포넌트는 네트워크의 전 범위에서 상호 독립적으로, 손쉽게 확장할 수 있습니다. 개발자는 이벤트 생성자와 소비자를 추가하고 제거하는 방식으로 애플리케이션과 시스템을 수정하거나 보완할 수 있습니다.

비동기식 메시징: 이벤트 기반 아키텍처에서는 컴포넌트끼리 비동기식 통신이 가능합니다. 생산자는 각자의 스케줄에 따라 이벤트 메시지를 발행합니다. 소비자가 수신할 때까지 기다리지 않습니다. 심지어 소비자의 수신 여부도 알 필요 없습니다. 그러면 통합이 간소화될 뿐만 아니라 사용자의 애플리케이션 경험이 향상됩니다. 사용자가 어떤 컴포넌트에서 어떤 태스크를 완료한 다음 기다리지 않고 다음 태스크로 진행할 수 있습니다. 해당 컴포넌트와 시스템의 다른 컴포넌트 간에 어떤 다운스트림 통합이 일어나더라도 상관없습니다.

기본적인 클라우드 네이티브 애플리케이션 아키텍처인 마이크로서비스에서는 느슨하게 결합된, 독립적으로 배치 가능한 서비스를 조합하여 애플리케이션을 만듭니다. 마이크로서비스의 주요 이점은 사실상 느슨한 결합에서 비롯됩니다. 편리한 유지 보수, 유연한 배치, 독립적인 확장성, 내장애성 등입니다.

당연하게도 이벤트 기반 아키텍처는 마이크로서비스 구현의 베스트 프랙티스로 널리 인정받고 있습니다. 마이크로서비스끼리 REST API를 사용하여 상호 통신할 수 있습니다. 그러나 요청/응답 통합 모델인 REST에서는 느슨하게 결합된 마이크로서비스 아키텍처의 여러 이점이 약화됩니다. 마이크로서비스 간에 강력하게 결합된 동기식 통합을 강제하기 때문입니다.