Event Sourcing
개요
bytebytego에서 Event Sourcing에 대한 이야기가 나와서 찾아보게 되었다.
Event Sourcing
- 데이터 저장소의 상태 변경 기준으로 데이터를 저장한다. 따라서 상태 변경에 대한 모든 이력을 관리할 수 있으며, 과거 상황에 대한 추적 및 분석에 용이하다.
- MSA에서 유기적으로 작동하여 요청을 처리할 수 있고, 이벤트를 통해 통신한다.
- 이벤트 객체를 발생 순서대로 저장하여 데이터 엔터티의 현재 상태에 대한 중요한 정보와 해당 상태에 도달하게 된 경로에 대한 정보가 제공받을 수 있다.
고려 사항
- 낙관적 동시성 제어
- 여러 사용자 또는 서비스가 동시에 동일한 데이터를 업데이트하려고 시도할 때 이벤트 충돌이 발생할 수 있다.
- 해결 방안 : 데이터 내에 타임스탬프 추가나 버전 관리를 포함하여 우선 순위를 정함
- 복잡성
- 기존의 CRUD 방식을 이벤트 기반 방식으로 변경해야하는 과정에서 오는 구현 및 시간 비용
- 최종일관성
- 명령 쿼리 책임 분리(CQRS) 패턴 또는 구체화된 뷰를 사용하여 데이터를 업데이트하는 데 따른 지연 시간때문에 이벤트에서 파생된 데이터 프로젝션에서는 결국 일관성이 유지되는데, 소비자가 이벤트 스토어의 데이터를 처리하고 게시자가 새 데이터를 보내는 경우, 데이터 프로젝션 또는 애플리케이션 객체가 현재 상태를 반영하지 않을 수 있다.
- 쿼리
- 이베트 로그에서 현재 또는 집계 데이트를 검색하는 작업은 기존 데이터베이스에 비해 더 복잡하고 느릴 수 있으며 복잡한 쿼리 및 데이터 수집성 작업은 시간이 많이 걸린다. 이러한 경우에는 CQRS가 유리할 수 있음.
- 이벤트 스토어의 크기 및 비용
- 이벤트 처리량이 많거나 보존 기간이 긴 시스템의 경우 이벤트 스토어의 크기가 기하급수적으로 커질 수 있다. 따라서 정기적으로 이벤트 데이터를 비용 대비 효율적인 스토어로 바꿔줘야한다.
- 이벤트 스토어의 확장성
- 대량의 쓰기 및 읽기 작업을 효율적으로 처리해야한다. 이벤트 스토어는 규모를 조정하기 어려울 수 있으므로, 샤드와 파티션을 제공하는 데이터 스토어를 사용하는 것이 중요하다.
- 효율성 및 최적화
- 읽기/쓰기 모두 효율적인 곳으로 이벤트 스토어를 선택하거나 설계해야한다. 예상 이벤트 볼륨 및 쿼리 패턴에 맞게 최적화되어야한다. 인덱싱을 사용하여 이벤트 검색 속도도 고려하고, 특수 이벤트 상황에 대한 데이터베이스나 라이브러리 고려하는 것도 방법
- 스냅샷
- 시간 기반 활성화를 통해 정기적으로 이벤트 로그를 백업해야한다. 가장 마지막으로 성공한 데이터를 백업하여 오류 발생시 복구할 수 있도록 하기.
- 시간 민감도
- 발생 순서대로 저장을 하기 때문에 네트워크의 신뢰성이 매우 중요하며 FIFO를 적극 활용한다.
- 이벤트 재생 성능
- 많은 수의 데이터를 활용하게 되면 시간이 많이 걸릴 수 있다. 보관된 데이터 사용시 성능을 개선하기 위한 최적화된 노력이 필요하다.
- 외부 시스템 업데이트
- 외부 시스템의 데이터 스토어를 업데이트하고 이러한 업데이트를 이벤트 객체로 사용할 수 있다.
- 외부 시스템 쿼리
- 외부 시스템의 직접적인 호출이 호출 날짜 및 시간에 민감할 경우, 수신된 데이터를 내부 데이터 스토어에 저장하여 재생 중에 사용한다.
- 이벤트 버전 관리
- 애플리케이션의 발전에 따라 이벤트의 구조가 바뀔 수 있어서, 호환성을 보장하기 위해 버전 관리 전략을 잘 수립하여야한다.
구현
명령 및 이벤트
- 상태 변경의 목적으로 서비스에 전송되는 명령 또는 요청을 나타낸다.
이벤트 스토어
- 변경 불가하고 추가만 가능하여 시간순으로 정렬된 리포지토리 또는 이벤트 스토어라는 데이터에 기록된다.
- 이벤트를 발생 순서대로 저장하여 초기 상태, 현재 상태 및 시점ㅈ 뷰가 알려진 엔터티 객체 또는 데이터 스토어를 재구성할 수 있다.
- 모든 작업 및 상태 변경에 대한 기록 역할을 하며 신뢰할 수 있는 단일 소스로서 중요한 역할을 한다.
- 저장하는 이벤트를 게시하고, 이벤트를 필터링하여 후속 작업을 위해 적절한 프로세서로 라우팅할 수 있다.
