Reference
이벤트 스트리밍
이벤트 스트리밍이란?
event stream is a sequence if business events ordered by time
•
DB, 센서, 모바일 장치 등의 이벤트 소스에서 발생하는 실시간 데이터(이벤트)를 이벤트 스트림 형태로 캡쳐, 저장, 처리하는 방법
◦
이벤트 스트림: 주문 (이벤트) → 결제 (이벤트) → 재고 수정 (이벤트)
•
이벤트 스트림을 실시간으로 처리하고, 필요에 따라 다른 곳으로 라우팅
•
결국, 이벤트 스트리밍 = 다양한 비즈니스 로직에서 발생하는 이벤트 데이터를 적합한 곳으로 전달하는 기술이벤트 스트리밍 사용 사례
예시 보기
스트리밍 데이터 처리 시스템의 필요성
모든 일상, 비즈니스의 서비스가 온라인화 되고 있고, 실제 대면 서비스에서 응답이 즉각적으로 이루어 지듯, 온라인 서비스에서 실시간으로 데이터를 처리하는 것의 필요성, 중요성 모두 커지고 있다.
스트리밍 데이터 처리 시스템의 요구 조건
대량의 random data에 대해 여러가지 요구사항 만족해야
Event Driven Architecture
전통적인 Transactional Service
주문 → 재고 확인 → 잔고 확인 →정산 가능 여부 확인 → 실제 주문 → 정산 → 판매자 알림 → 재고 업데이트 → 구매자 알림 → 기타 등등
Event Driven Architecture 예시
주문 → 재고 확인 → 잔고 확인 → 정산 가능 여부 확인 → 실제 주문
Event Queue를 통한 병렬 처리
•
실제 주문 → 정산
•
실제 주문 → 판매자 알림
•
실제 주문 → 재고 업데이트
•
실제 주문 → 구매자 알림
장점
•
후속 작업이 독립적이라는 점에서 논리적이다.
•
Decoupling을 통해 Flexible해진다.
Publisher-Subscriber model
Publisher
Subscriber
이벤트 채널
Event Driven Architecture의 장점
1.
Event의 발생과 처리 로직을 분리 (관심사의 분리)
2.
Pub-Sub model로 하나의 이벤트에 여러 작업을 decouple된 상태로 확장 가능
3.
Event 자체는 statless하기 때문에 버그 발생이 줄어든다
4.
인프라와 서비스의 유연성, 확장성, 장애 복원력을 강화할 수 있다
5.
큰 규모의 서비스, 조직, 제품을 만들 때 시스템 완결성을 높이고 생산성을 향상시킬 수 있다
Event Driven Architecture의 단점
•
시스템 규모에 상관 없이 Event Channel이 되는 메세징 시스템이 동반된다
•
로직이 단순하고 사용자나 서버의 규모가 크지 않을 때는 Over Engineering → 개발 시간과 인프라 비용 증가
•
단, 최근에는 메세지 건수 기반으로 비용이 발생하는 cloud형 단순 메세징 시스템 (AWS SQS 등)을 이용하여 초기 비용을 낮출 수 있다
분산 메세지 큐
메세지 큐
Event Channel (Broker) 역할을 해 줄 전용 시스템 → MQ 서버
단일 Message Queue의 한계
ex) RabbitMQ
•
단일 머신의 capacity 한계
•
Scale-up으로 대응 (Scale Out 한계)
•
HA, 고장 감내성 수준이 떨어진다
분산 메세지 큐
ex) Apache Kafka
•
여러개의 브로커 서버가 클러스터를 이룸
•
HA, Fault Tolerance 제공
•
Scale-out으로 늘어나는 트래픽, 데이터, client에 대응
•
다만, queue가 분산되어 단일 MQ 수준으로 순서보장을 하기에는 제약사항이 있다•
분산 메세지 큐의 등장으로 대량의 데이터에 대해서도 Pub-Sub 모델의 구현이 가능해졌다
•
스트리밍 처리 기술에서도 대량의 데이터를 실시간으로 신뢰도 높게 처리할 수 있게 되었다