[Architecture] Event Sourcing
2025. 4. 24. 13:34ㆍTIL/Database
이벤트 소싱(Event Sourcing)이란?
- 이벤트 소싱(Event Sourcing)은 애플리케이션의 상태를 단순히 현재 상태로 저장하지 않고, 상태 변경을 일으킨 이벤트의 순서대로 저장하여 전체 상태를 재구성하는 아키텍처 패턴이다.
- 각 이벤트는 “무엇이 언제 일어났는가”에 대한 정보를 담고 있으며, 이 흐름을 통해 현재 상태를 유추할 수 있다.
- 전통적인 CRUD 방식은 데이터의 최종 상태만 저장하지만, 이벤트 소싱은 모든 변경 이력을 남기기 때문에 시간의 흐름에 따른 변화 과정을 추적할 수 있다.
이벤트 소싱의 예시
- 자막 편집 시스템을 예시로 들 수 있다.
- 사용자가 자막을 추가, 수정, 삭제할 때마다 각각 하나의 이벤트로 저장된다.
- 자막_추가됨(내용="Hello", 시작=00:00:01, 끝=00:00:03)
- 자막_수정됨(ID=1, 내용="Hello world")
- 자막_삭제됨(ID=1)
- 이러한 이벤트들을 시간 순으로 적용하면 자막의 최종 상태를 복원할 수 있으며, 중간에 어떤 변화가 있었는지도 정확히 파악할 수 있다.
이벤트 소싱의 장점
- 변경 이력 추적 용이: 모든 상태 변경이 기록되므로, 감사 로그나 변경 히스토리를 자연스럽게 확보할 수 있다.
- 상태 복원 가능: 특정 시점으로 되돌리려는 경우 이벤트 스트림을 재생하여 이전 상태로 복원할 수 있다.
- 비동기 처리 및 확장성 확보: 이벤트는 비동기적으로 처리하기 쉬우며, 마이크로서비스나 이벤트 기반 아키텍처와 잘 통합된다.
- CQRS와의 궁합이 좋음: 읽기/쓰기 모델을 분리하는 CQRS 패턴과 함께 사용할 경우 복잡한 요구사항을 효과적으로 관리할 수 있다.
이벤트 소싱의 단점
- 설계 복잡성 증가: 기존의 단순한 CRUD 방식보다 설계와 구현이 복잡하며, 모든 상태 변경을 의미 있는 이벤트로 정의해야 한다.
- 정합성 유지 필요: 이벤트의 순서나 누락 등에 민감하기 때문에 신중하게 관리해야 한다.
- 저장소 관리 필요: 이벤트 수가 많아질수록 저장 공간과 검색 성능에 대한 고려가 필요하며, 이를 위해 스냅샷 기능을 함께 사용하는 경우가 많다.
- 디버깅 어려움: 오류 발생 시 원인을 추적하려면 이벤트 로그 전체를 살펴보아야 하는 경우도 있다.
이벤트 소싱 사용 효과
- 변경 이력의 명확한 추적 가능: 누가 언제 어떤 자막을 수정하거나 삭제했는지를 명확하게 파악할 수 있다.
- 버전 관리 및 롤백 가능: 실수로 잘못 수정하거나 삭제했을 경우 과거 이벤트를 기준으로 원래 상태를 복원할 수 있다.
- 협업에 유리: 여러 사용자가 동시에 작업하는 환경에서 이벤트 단위로 충돌을 관리하거나 병합 전략을 세우기 수월하다.
- 재생 기능 제공 가능(replay): 데이터 생성 과정을 시간 순으로 재생할 수 있으므로, 교육적 또는 분석적 목적에 활용하기 유용하다.
'TIL > Database' 카테고리의 다른 글
[Architecture] CQRS 패턴 (0) | 2025.04.24 |
---|---|
[Metabase] 데이터 모니터링 툴 (0) | 2025.03.28 |
[MySQL] DBeaver 연결 시 Public Key Retrieval is not allowed 문제 (0) | 2024.06.03 |
[MySQL] INT(11)과 DATETIME(6)의 비밀 (0) | 2023.04.11 |
[MySQL] Soft delete와 unique constraint (0) | 2023.01.12 |