[DE] Event Streaming

Event Streaming Platform

1. 이벤트 스트리밍이란?

​ 이벤트 스트리밍이란 다양한 소스에서 발생하는 실시간 데이터를 이벤스 스트림 형태로 캡쳐하고 저장/처리하는 방법입니다. 증권거래소,은행 등의 결 제 정보 및 금융정보, 물류 산업에서 실시간 추적 및 모니터링과 같이 실시간 데이터 처리가 중요한 작업에 사용됩니다.

2. 이벤트 스트리밍의 필요성

• 운영적 측면 : 일상의 많은 서비스가 온라인화 되면서 오프라인 서비스의 즉각적인 반응을 온라인에서도 얻길 원하는 사용자들이 많아지고 있습니다. 이에 따라 온라인에서도 오프라인과 같은 즉각적인 반응을 구현하기 위해 많이 사용됩니다.
• 기술적 측면 : 전통적으로 널리 사용되던 배치처리 시스템은 실시간 반영이 어렵습니다. 예컨데 일단위 배치 처리 시스템이 있다고 가정한다면, 데이터가 변경되어도 배치 시간이 되지 않는다면 반영되지 않을 것 입니다. 실시간성 분석 역시 불가능합니다. 이러한 점을 극복하기 위해 이벤트 스트리밍의 사용이 많아지는 추세입니다.

Event Driven Architecture

Event Driven Architecture(EDA)는 알아보기 전에 주문 시스템 API 개발의 예시를 통해 기존의 시스템과 어떻게 다른지 확인해보겠습니다.

전통적인 Transactional Service 관점에서는 주문 API 개발시 거치는 로직의 수가 상당히 많았습니다. 각 로직별로 DB I/O 작업도 필요하고 외부 시스템 연동이 필요한 경우도 있어 응답시간이 느려집니다. 결정적으로 각 로직간 coupling이 강해집니다. 이로 인해 시스템이 복잡해지고 변경에 대한 부담이 가중됩니다. 데이터 파이프라인 관점에서 본다면 우수한 아키텍처의 기준이 되는 유연한 결정, 되돌릴 수 있는 결정이 어려워 지는 것입니다.

EDA는 전통적인 서비스 개발의 문제점을 개선하고자 고안되었습니다. 동일한 예시를 기준으로 봤을 때, 주문 이벤트가 발생하면 이벤트에서 작업들이 파생됩니다. 이때 각 작업은 독립적이게 됩니다. 이전 서비스의 문제점이었던 로직간 coupling이 해결되는 것 입니다. 더하여 주문 이벤트의 발생과 파생 작업들 간 로직의 분리로 인해 SoC를 보장할 수 있게 됩니다.

EDA의 장/단점

장점
1.event 발생과 처리의 로직 분리
2.pub/sub모델을 통해 여러 작업을 decoupling
3.event는 stateless 하기 때문에 버그 발생이 적고 디버깅 용이
4.인프라,서비스의 유연성 및 확장성 확보 가능

단점
1.관리 포인트 증가
2.소규모일때는 개발시간,비용이 늘어난다

Pub/Sub Model

pub/sub 모델은 EDA를 구현하기 위해 널리 사용되는 모델입니다. pub/sub은 비동기 메시지 통신 방식으로 producer와 consumer를 느슨하게 결합시켜주는 모델입니다. 이를 통해 서비스간 의존성이 감소하고 확장성이 좋아집니다. 

분산 메시지 큐

EDA의 구현을 위해서는 기존 JMS처럼 단일 App 수준의 pub/sub으로는 불충분했습니다. event 채널이 특정 App에 종속되기 때문입니다. 따라서 event 채널 역할의 전용시스템이 필요했습니다. 내부에 message queue를 두고 App은 시스템의 client로 작동하게 되는 것 입니다. 이렇게 탄생한 것이 대표적인 메시지 큐 RabbitMQ입니다.

단일 메시지 큐

RabbitMQ는 대표적인 단일 서버 로써 message broker 역할을 수행하게 됩니다. 하지만 한계가 뚜렷합니다. 1.단일 머신의 capacity 한계 2.scale up으로만 부하 대응 가능 3.HA어려움 이러한 한계로 인해 대규모 데이터 시스템에서는 분산 메시지 큐를 사용하게 됩니다.

RabbitMQ의 HA

RabbitMQ의 HA는 완전 구현 불가능한 것은 아닙니다. 백업 서버를 두고 따로 스트리밍 하여 Active/StanBy 형태로 HA를 구축할 순 있습니다. 하지만 분산 메시지 큐의 경우처럼 완전한 ZeroDownTime을 실현하는 것은 어렵습니다.

분산 메시지 큐

Kafka로 대표되는 분산 message queue는 다수의 broker 서버가 cluster를 이뤄서 HA,내결함성을 제공합니다. 또 부하 증가시 scale out을 통해 장애 대응이 가능한 장점이 있습니다. 하지만 순서 보장면에서 약점을 보입니다. 메시지가 각 서버에 분산 저장되다 보니 동일 서버 내에서는 순서 보장이 가능하지만 타 서버의 메시지와의 순서 보장은 100%라고 할 수 없습니다. 결국 순서보장이 되긴 하지만 단일 message queue 수준의 보장은 어렵습니다.