상태 기반 모델링 vs 이벤트 기반 모델링(이벤트 소싱)
상태: 저량
이벤트: 유량. 상태의 변화를 만들어 냄.
소프트웨어 시스템과 현실 세계를 매칭시킬 때 데이터 모델링이 필요한데, 크게 상태 기반 모델링과 이벤트 기반 모델링이 있음
두 방법 중 상황을 표현하고 관리하는 것이 더 쉬운 방법이 있을 수 있음
일반적으로 다음의 상황에서 이벤트 기반 모델링이 적합함
- 시간이 지남에 따라 무언가가 진화하는 형태
- 대규모 시스템: 더 많은 수의 개별 부품을 포함하며 진화함
- 상태 변화에 대한 히스토리를 알아야할 때
이벤트 소싱: 데이터를 이벤트로 저장하기
데이터를 이벤트로 저장하는 방법
-
단순히, 이벤트 저장소만 두는 방법
-
어플리케이션에서 캐쉬 계층의 reduction 결과를 보존하기도 함
CRUD 중 CR 만 제공 -
UD 요청도 이벤트로써 영구히 저장됨
이벤트 소싱의 장점
트레이싱
이벤트 로그를 통해 과거에 어떤 일이 왜, 어떻게 이루어졌는지 파악 가능
디버깅에 활용 가능
복구 가능성(재생 가능성)
로직에 버그가 있는 경우, 쉽게 복구 가능함
- 로직을 수정하고, 버그가 나타나기 이전 지점부터 되감고 이벤트를 재생하면 됨
통찰력
분석 시스템에서 유용하게 사용 가능 → 이벤트 데이터 기반의 분석을 통해 의사 결정에 도움이 될만한 정보를 얻을 수 있음
- 예를 들어, 사람들이 특정 시간 또는 특정 카테고리 내에서 매장에서 많이 구매하지 않는 이유를 파악할 수 있다고 함...
CQRS(Command and Query Responsibility Segregation)
이벤트 소싱의 문제점: 상태 읽기 비용(or Large Reduction)
- 현재 상태를 만들기 위해 이벤트를 읽어와서 축소(Reduce) 연산 시행한 후, 상태를 만들어야 함
- 이벤트 데이터가 너무 많다면, Reduce 연산 및 State-View를 만드는 데 너무 오랜 시간이 걸릴 수 있음
해결책: 읽기가 아닌 쓰기에 계산하기
- command: state 를 바꾸는 명령어(C,R,D)
- query: read
- CQRS는 데이터를 읽기가 아닌 쓰기 때, 계산을 수행하는 방식을 채택
- CQRS가 이벤트 소싱 문제점의 해결책이 될 수 있으며, 실제로도 이벤트 소싱 구현 시에 가장 일반적으로 사용되는 방법
CQRS를 이용한 이벤트 소싱 구현
- 쓰기 모델과 읽기 모델을 구분함
- 쓰기 모델은 이벤트 기반 모델링
- 읽기 모델은 상태 기반 모델링
- 쓰기 단계에서 Reducing 및 Translation 연산이 이루어져, 기존의 이벤트 소싱의 문제점을 해결
CQRS의 장점
- 이벤트 소싱을 구현하여 이벤트 소싱의 장점을 얻을 수 있음
쓰기 및 읽기 역할의 분리로 더 높은 성능
CQRS의 단점
- 최종적 일관성을 보장하므로 쓰기 직후에 읽기 작업이 불가능할 수 있음
- 시스템 복잡성의 증가
- 쓰기 모델과 읽기 모델이 서로 다른 저장소를 사용하고 있다면, 중간에 Kafka와 같은 스트림을 사용해야 함
- 시간이 흐름에 따라 Kafka의 토픽을 지나는 이벤트의 스키마가 다양해질 수 있으며, 이 때 마다 파싱 코드를 추가해주어야 함
CDC와 아웃박스 패턴
CDC
CDC 는 이벤트 소싱의 또 다른 방법
- 이벤트 소싱의 장점을 취할 수 있음
CDC의 단점
- 이벤트 소싱의 장점 중 복구 가능성은 구현하기 어려움 → 아웃박스 패턴으로 해결 가능
아웃박스 패턴
- CDC 이벤트를 저장하는 테이블을 DB에 구축함 → 이 테이블을 통해 재생이 가능해짐
- 기존 테이블의 변경 → CDC 이벤트 테이블 변경 트리거 → CDC 이벤트 발행
