목차
1 스트리밍 데이터 처리의 필요성
1.1 이벤트 스트리밍 개념
1.1.1 이벤트 스트리밍이란?
이벤트 스트리밍은 데이터베이스, 센서 및 모바일 장치와 같은 이벤트 소스에서 발생하는 실시간 데이터를 이벤트 스트림 형태로 캡처하고 저장/처리하는 방법이다. 또한 이벤트 스트림을 실시간으로 조작하고 처리하여 필요에 따라 이벤트 스트림을 다른 곳으로 라우팅한다.
즉, 다양한 비즈니스 로직에서 발생하는 이벤트 데이터를 적합한 곳에 실시간으로 전달하는 기술을 이벤트 스트리밍이라고 한다.
1.1.2 이벤트 스트리밍 사용 사례
이벤트 스트리밍은 다양한 곳에서 사용되고 있다.
•
증권 거래소, 은행, 보험 등에서 실시간으로 결제 및 금융 거래를 처리하기 위해
•
물류 및 자동차 산업 등에서 자동차, 트럭, 함대 및 선적을 실시간으로 추적하고 모니터링하기 위해
•
공장 및 풍력 단지 등에서 IoT 장치 또는 기타 장비의 센서 데이터를 지속적으로 캡처하고 분석하기 위해
•
소매, 호텔 및 여행 산업, 모바일 애플리케이션 등에서 고객 상호 작용 및 주문을 수집하고 즉시 반응하기 위해
•
병원 치료 중인 환자를 모니터링하고 상태 변화를 예측하여 응급 상황에서 적기에 치료하기 위해
•
회사의 여러 부서에서 생성된 데이터를 연결, 저장 및 사용 가능하게 만들기 위해
•
데이터 플랫폼, 이벤트 중심 아키텍처 및 마이크로서비스의 기반을 제공하기 위해
1.1.3 스트리밍 데이터 처리 시스템의 필요성
사실상 모든 일상, 비즈니스의 서비스가 온라인화 되고 있다. 실세 대면 서비스에서 응답이 즉각적으로 이루어 지듯이, internet scale 에의 온라인 서비스에서 실시간으로 데이터를 처리하는 것의 필요성과 중요성 모두 커지고 있다.
스트리밍 데이터 처리 시스템은 대량의 random 데이터에 대해서 low latency, high scale, high throughput, persistent, flexibility, easy to implement/operate 문제를 해결하는데 초점을 맞추고 있다.
2 Event Driven Architecture
2.1 Event Driven Architecture 사례
예를 들어 쇼핑몰에서 상품 주문을 했다고 해보자. 전통적인 Transactional Service 관점에서 보았을 때, 주문이 완료 되기 이전에 재고확인, 잔고 확인, 정산 가능 여부확인, 판매자에게 알림, 결제가 모두 완료된 이후에 주문이 가능했다.
하지만 이 방법은 주문 과정에서 필요한 것 뿐만 아니라 주문 이후에 필요한 과정들 까지 모두 상태 확인이되어야 주문이 완료된다는 점에서 현실성이 떨어진다.
이렇게 구현한 주문 작업은 중간 과정이 많아질 수록 실패할 가능성이 높아지고, 사용자 경험을 해쳐서 주문율이 떨어질 수 있다. 뿐만 아니라 주문 이후의 작업까지 포함되므로 실제 판매자는 주문이 완료되지 않아도 알림메세지를 받게 되어서 workflow 도 비정상적이다.
Event Driven Architecture 에서는 주문이벤트가 발생하면, 그에 따르는 후속작업들 정산연동, 판매자에게 알림, 결제 연동, 심지어는 잔고 확인도 주문 이후에 이루어진다. 각 작업은 주문 으로부터 파생되지만, 주문 이후에는 서로에게 독립적인 작업이다.
실제 현실에서의 협업 모델에도 이 방식은 자연스럽고 적합하다. Event Driven Architecture 의 시스템적인 구현을 위해서는 메세지 기반 아키텍처 위에서 설계되는 경우가 잦다. 때문에 Event Driven Architecture = “메세징도구(예: Kafka) 를 사용” 으로 치환해서 생각하는 경우가 있는데 이것은 오해의 소지가 있다.
2.2 Publisher-Subscriber model
Event Driven Architecture 패턴은 느슨하게 결합된 소프트웨어 구성요소들과 서비스들 사이에서 이벤트들을 전송하는 애플리케이션들과 시스템들의 설계와 구현에 의해 적용될 수 있다.
이벤트 구동 시스템은 일반적으로 Publisher-Subscriber 모델(이하 pub-sub)을 따른다. pub-sub은 publisher(또는 agent, producer, emitter), 이벤트 subscriber(또는 sinks, consumer) 및 이벤트 채널로 구성된다.
publisher는 이벤트를 감지, 수집 및 전송할 책임이 있다. 이벤트 발생기는 이벤트의 subscriber를 알지 못하며, subscriber가 존재하는지조차 알지 못하며, 존재하는 경우 이벤트가 어떻게 사용되거나 추가로 처리되는지도 알지 못한다.
subscriber는 사건이 발생하는 즉시 반응을 적용할 책임이 있다. 반응은 subscriber 자체에 의해 완전히 제공되거나 제공되지 않을 수 있다. 예를 들어, subscriber는 이벤트를 필터링, 변환 및 다른 구성요소로 전달할 책임이 있거나 그러한 이벤트에 대한 자체적인 반응을 제공할 수 있다.
이벤트 채널은 이벤트가 이벤트 publisher로부터 이벤트 subscriber에게 전송되는 도관이다. 이벤트의 정확한 분포에 대한 지식은 이벤트 채널 내에 서만 존재한다. 이벤트 채널의 물리적 구현은 messeage oriented middleware 또는 point to point communication과 같은 전통적인 구성 요소를 기반으로 할 수 있다. Java 에서는 JMS 를 기반으로 사용했다. 최근에는 특정 언어에 종속되지 않고 Kafka 와 같은 분산 메세징 브로커를 이용한다.
2.3 Event Driven Architecture 의 장점
1.
Event 의 발생과 처리 로직을 분리할 수 있다.
2.
Pub-Sub model 로 하나의 이벤트에 여러 작업을 decoupling 된 상태로 확장할 수 있다.
3.
Event 자체는 stateless 해서 버그 발생과 디버깅이 줄어든다.
4.
인프라와 서비스의 유연성, 확장성, 장애 복원력을 강화시킬 수 있다.
5.
위와 같은 이유로 큰 규모의 서비스/조직/제품을 만들 때 시스템 완결성을 높이고 생산성을 향상 시킬 수 있다.
2.4 Event Driven Architecture 의 단점
Event Driven Architecture 의 구현을 위해서는 기본적으로 Event channel 이 되는 메세징 시스템을 동반하게 된다. 단순한 로직이고 사용자나 서버의 규모가 크지 않을 때는, Event Driven archiecture로 구현한다면 오히려 개발 시간이나 인프라 비용이 늘어날 수 있다.
단, 근래에는 메세지 건수 기반으로 비용이 발생하는 cloud 형 단순한 messeging 시스템(AWS SQS 등)을 이용하면 Event Driven Architecture 의 초기 비용을 낮추며 시작할 수 있다.
3 분산 메세지 큐
3.1 메세지 큐
위의 Event Driven Architecture 의 구현을 위해서는, 기존의 JMS처럼 단일 어플리케이션
수준에서의 pub-sub 모델로는 충분하지 않았다. Event channel 이 특정 어플리케이션이나
서버에 종속되기 때문이다. 따라서 Event Channel(broker) 역할을 해줄 전용 시스템이 만
들어졌다. message queue 서버를 별도로 두고 application은 message queue 서버에 대
한 client 로서 pub-sub 모델로 데이터를 읽고 쓰는 방식으로 활용한다.
3.2 단일 Message Queue 의 한계
RabbitMQ 로 대표되는 단일 서버의 Message Queue 로 message(event) broker 역할을 수행할 수 있었다.
다만, 단일 message queue 로는 다음과 같은 한계가 있다.
1.
단일 머신의 capacity의 한계가 있다.
2.
Scale-Up 으로 늘어나는 트래픽, 데이터, Client 에 대응 해야한다.
3.
HA, 고장 감내성 수준이 떨어진다.
3.3 분산 메세지 큐
Apache Kafka 로 대표되는 분산 메세지 큐는, 여러개의 브로커 서버가 클러스터를 이루어서 HA, Fault Tolerance를 제공함과 동시에 여러개의 분산된 큐로 scale-out 으로 늘어나는 트래픽, 데이터, client에 대응할 수 있도록 만들어졌다.
다만, queue 가 분산되어있기 때문에 순서 보장이 단일 message queue 수준으로 할 수 없는 제약사항이 있다.
분산 메세지 큐의 등장으로 대량에 데이터에 대해서도 Pub-Sub 모델의 구현이 가능해지자, 스트리밍 처리 기술에서도 대량의 데이터를 실시간으로 신뢰도 높게 처리할 수 있게 되었다.