티스토리 뷰

⑧ IT Wordbook

Event Sourcing & CQRS

와스프로 GodNR 2020. 5. 12. 12:51
728x90
SMALL

Event Sourcing은 이벤트 전체를 하나의 데이터로 저장하는 방식이다.

예를 들어 야구 티켓을 구매할 경우를 생각해 보자.

야구 티켓 예매를 위해 우리는 잔여 좌석 수와 예매 가능 수 등의 결과를 위주로 데이터를 저장한다.

잠실 야구장 LG 야구 경기 관람을 위해 티켓을 구매하려 한다.

최초 가족 모두 편안한 관람을 위해 가족석을 3매를 예매하려고 선택을 했다.

이때 딸이 우리 신나게 응원하면서 관람하자고 하여 해당 좌석을 취소하고 다시 응원석 쪽 예매를 진행하였다.

이때, 기존 애플리케이션은 다음과 같은 정보를 저장한다.

  • 응원석 x열x줄x번째 좌석 3개 예매

기존 우리는 중간에 어떠한 동작을 했던 상관없이 마지막 결과에 대한 데이터의 변화를 추적하는데 초점을 맞추고 있다.

이때 우리는 가족석에서 응원석으로 Update가 발생하였으며, 마지막 구매로 인한 Add도 발생했다.

이벤트 소싱은 이와 다르게 이벤트가 발생하기 전 이벤트가 발생하는데 어떠한 과정이 있었는지를 주목한다.

동일한 과정이 발생했을 때 이벤트 소싱은

  • 가족석 추가

  • 가족석 삭제

  • 응원석 추가

  • 응원석 구매

이 전체를 하나의 데이터로 관리한다. 이와 같은 방식은 Update, Delete가 없는 오직 Add만 가능한 방식이라 할 수 있다.

Event Sourcing은 이와 같이 데이터의 누적으로 하나의 이벤트를 하나의 데이터로 처리하다보니 수많은 데이터가 누적되게 된다. 이로 인한 문제도 발생할 수 있는데, 바로 다음과 같은 상황이다.

위 첫번째 예시의 경우 총 4개의 데이터가 저장(Add)되지만, 만약이와 같은 반복이 수백번 반복되었다고 가정해 보자.

Event Sourcing은 단순히 데이터를 순차적으로 읽어가는 역할을 하기때문에, 만약 마지막번째 데이터를 찾기 위해서는 우리는 수백번의 읽기 작업을 반복해야 할 것이다.

이와 같은 읽기 문제를 최적화 하기 위해 2가지 방법을 적용할 수 있다.

  • 스냅샷 : 첫번째는 스냅샷을 활용하는 방안이다. 데이터의 중간 중간을 스냅샷으로 저장하여 빠르게 데이터를 찾아가는 것이다. 예를 들어 1000번의 기록이 저장된 이벤트 소싱 방식의 데이터에 마지막 데이터를 찾기 위해 900번째 데이터 값을 스냅샷으로 저장한다면, 100번의 조회만으로 결과 값을 찾아 낼 수 있을 것이다.

  • CQRS 조합 : CQSR는 CUD와 R을 분리하여 조합하는 구조이다. 이벤트 소싱은 쓰기에 적합한 방식이라면, CQRS는 읽기에 보다 최적화 된 조합이라 할 수 있어 조합하여 활용하기 좋은 방식이다.

Event Sourcing과 CQRS의 조합은 다음과 같은 Process로 진행된다.

1) Command(CUD)가 발생하면 Command API에 요청이 전달된다.

2) Command를 처리하는 서비스는 Event Store에 API 처리 결과를 저장한다.

3) 이벤트가 처리된 후 이벤트 브로커로 결과가 전송된다.

4) 이벤트는 제한적이며, 이벤트 기반의 독립적인 형태로 통합된다.

5) 이 이벤트는 Queries API로 전달되며, View Store에 저장된다. 이후 Client로부터 Query(R)가 요청되면 이 View Store에 동기화 된 데이터를 조회하게 된다.

728x90
LIST
댓글
댓글쓰기 폼
250x250
Total
1,246,567
Today
93
Yesterday
2,046
«   2021/10   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
글 보관함