Event-Sourcing-Pattern

# Event-Sourcing-Pattern, 이벤트 소싱 패턴

https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/modernization-data-persistence/service-per-team.html

이벤트 소싱 패턴 - AWS 규범적 지침

0. 들어가기에 앞서 Event-Sourcing-Pattern + CQRS

Event Sourcing 패턴은 보통 CQRS 패턴과 함께 사용하는 경우가 많다.
이유는 검색을 하면 많은 자료가 나오지만 간단히 정리하자면 아래와 같다. 
CQRS란 Command and Query Responsibility Segregation의 줄임말로, Command(Create, Update, Delete)와 Query(Read)의 책임을 분리하자는 패턴이다. 

대부분의 DB 트랜잭션은 DB로부터 데이터를 읽어 화면에 뿌려주는 것이다. (Read)  
이 과정에서 DB에서 데이터를 읽는 시점과 화면에 렌더링 되는 시점은 반드시 차이가 생기게 된다.
CQRS 패턴은 이 점을 인지하고, 굳이 하나의 DB안에서 CRUD의 Read 기능과 나머지 CUD(Create, Update, Delete) 기능을  함께 구성하지 않고 기능을 분리하여 캐시와 같은 DB로 더욱 빠르게 사용자들이 읽어 들일 수 있도록 하고, CUD 기능은 메시지 큐를 통해실제 데이터를 변경시키고 변경이 일어나는 시점에 이벤트를 발생시켜 캐시를 업데이트하는 방식으로 구성하는 것을 의미 한다.
간략한 설명은 아래의 이미지를 보고 확인한다.
여기서는 이벤트 소싱 패턴에 대해서 알아보고, 추후에 이벤트 소싱 패턴과 CQRS 패턴도 함께 보도록 하자.

1. Event-Sourcing-Pattern의 개요

이벤트 소싱 패턴의 경우는 Insert 작업만 존재한다. 기존의 존재 하였던 SELECT, UPDATE, DELETE가 발생할 경우 현재 데이터를 변경하는것이 아닌 변경된 데이터를 INSERT하는 방식이라고 이해할수 있다.
테이블은 아래와 같이 모든 작업을 상태로 관리하고 저장한다. 아래의 예시를 보면 알수 잇을 것이다.
아래의 캡처 화면에서 event_type을 보면 생성과 업데이트가 존재한다. 그리고 아래의 캡처화면과 같이 time_stamp라는 컬럼에서 해당 이벤트의 시간을 Insert 하여 최종 업데이트한 이벤트를 가져올 수 있다. 

2. 사용 사례 및 장 단점

- 사용 사례
해당 이벤트에 대한 로그를 모두 수집해야 하는 경우 : 감사, 법적 대응 등
면밀히 분석을 해야하는 경우 : 해당 이벤트 등에 대해 면밀히 분석을 해야하는 경우
 
- 장점
모든 과거 데이터 확인 및 복원 가능 : 유스케이스의 경우 소급 디버깅이 존재
해당 서비스 및 시스템에 대한 분석 기능 제공
감사 로그를 기록
동시성 제어 : 읽기 데이터가 기록되는 동안 다른 프로세스에 의해 업데이트 되는 경우 예외처리
 
- 단점
아키텍처의 복잡도 상승
모델을 발전하는데 제약이 존재
해당 패턴을 활용하는 과정에서의 학습 곡선 발생
 
- 특징
데이터 삭제 : 페이로드 패턴을 통해 키를 삭제하여 해당 정보에 대한 접근 불가하도록 구성.(Key : Value 저장소)
모델의 확장이 용이 : 애그리게이트 단위로 구분되어 있기 때문에 확장이 용이하다.(저장소는 단일 저장소 사용)
Aggregate : 애그리게이트(Aggregate)는 소프트웨어 개발에서 관련된 객체들의 집합을 의미한다. 
예를 들어 고객(Customer), 계정(Account), 주문(Order), 제품(Product) 등이 있다.

3. 테스트 코드 및 FlowDiagram

- 테스트 코드는 아래의 GitHub에 업로드 되어 있다.

https://github.com/Nanninggu/Event-Sourcing-Pattern.git

GitHub - Nanninggu/Event-Sourcing-Pattern: About Event-Sourcing-Pattern

 

-  FlowDiagram은 아래와 같다.

이건 시간나면 그리자.
 
- 끝 -