스트리밍 데이터 처리
이벤트 스트리밍
- 데이터베이스, 센서 및 모바일 장치와 같은 이벤트 소스에서 발생하는 실시간 데이터를 이벤트 스트림 형태로 캡처하고 저장 및 처리하는 방법
- ex) 상품 선택, 구매 클릭 등
- 다양한 비즈니스 로직에서 발생하는 이벤트 데이터를 적합한 곳에 실시간으로 전달하는 기술
사례
- 은행, 증권 거래소 등에서 실시간으로 결제 및 금융 거래 처리
- 물류 시스템에서 실시간으로 추적 및 모니터링
- 데이터 플랫폼, 이벤트 중심 아키텍처 및 MSA 기반을 제공하기 위해
Event Driven Architecture
전통적인 Transactional Service 관점에서는 하나의 처리가 모두 완료되어야 상태 확인이 가능하다. 그리고 중간 과정이 많아질수록 실패할 가능성이 높아지고 사용자 경험에 좋지못한 영향을 준다.
반대로 Event Driven Architecture는 서로 독립적인 작업이 일어나면서 현실의 협업 모델에 자연스럽고 적합하다.
Publisher-Subscriber model
위의 Event Driven Architecture 패턴은 느슨하게 결합된 구성요소들과 서비스 사이에서, 이벤트들을 전송하는 애플리케이션과 시스템들의 설계와 구현에 의해 적용된다.
그래서 일반적으로 Publisher-Subscriber 모델(pub-sub)을 따른다.
카프카 이전에 pub-sub 모델도 있었지만, 특정 언어에 종속되는 경우가 많았다.
장점
- SoC(관심사의 분리), 이벤트 발생과 처리 로직을 분리할 수 있다.
- 하나의 이벤트에 여러 작업을 decoupling 상태로 확장할 수 있다.
- 이벤트 자체는 stateless → 버그발생과 디버깅이 줄어든다.
- 인프라와 서비스 유연성, 확장성, 장애 복원력 상승
- 큰 규모의 서비스를 만들때 시스템 완결성과 생산성을 향상시킬 수 있다.
단점
- 기본적으로 이벤트 채널이 되는 메세징 시스템이 필요하게 된다.
- 굳이 필요하지 않을 경우에 event driven archiecture로 구현하면 개발 시간이나 인프라 비용이 늘어난다.
분산 메세지 큐
메세지 큐
단이 애플리케이션 수준에서의 pub-sub 모델로 하게되면 특정 애플리케이션이나 서버에 종속되어버린다. 이상적이 이벤트 드라이븐 아키텍처는 pub과 sub이 완전히 독립적인 것이 좋다.
그래서 Event Channel(broker)역할을 해줄 전용 시스템이 필요하다. 대표적인 서비스로 RabbitMQ(단일 Message Queue)가 있다. 하지만 여러 한계가 존재한다.
- 단일 머신의 capacity 한계
- ⇒ Scale up으로 대응할 수 밖에 없다. (Scale-out 안됨) 그래서 HA가 떨어진다.
분산 메세지 큐
- 대표적인 서비스로 Apache Kafka가 있다.
- 여러 개의 브로커 서버가 클러스터를 이루어 HA, Fault Tolerance를 제공함과 동시에 여러 개의 분산된 큐로 scale-out으로 늘어나는 트래픽, 데이터, client에 대응할 수 있도록 만들어졌다.
- 기본적으로 순서 보장이 단일 메세지 큐 수준으로는 할 수 없는 제약사항이 존재한다.
