[IT용어] CQRS[Command and Query Responsibility Segregation]과 이벤트 소싱[Event Sourcing]이란?

# 학습 출처

- https://www.popit.kr/cqrs-eventsourcing/

 

# CQRS (Command and Query Responsibility Segregation) 란?

CQRS는 네이밍에서 알 수 있듯이 명령과 쿼리의 역할을 구분 한다는 것이다. 즉 커맨드 ( Create - Insert, Update, Delete : 데이터를 변경) 와 쿼리 ( Select - Read : 데이터를 조회)의 책임을 분리한다는 것이다. 

즉, 기존 CRUD를 하나의 Model 또는 State로 처리하던 것을 CUD와 R로 나누어 처리하는 방법을 의미한다.

메인 비즈니스 로직은 주로 CUD 쪽에 있고, R은 거의 단순한 편에 속하는데, 한꺼번에 모아놓음으로써, 복잡성이 증가했던 문제를 해결할 수 있다.

 

# Akita 상태 관리 라이브러리의 예시

최근에 경험해 본 akita 상태 관리 라이브러리를 예로 들어보자.

상태(State)를 만들어, Store[readonly]에 저장하고, 오직 CUD와 Store ser/update는 Service에서만 수행하고, Store값을 조회할 경우에는 Query[readonly]를 사용하는 것이다.

 

 

# CQRS를 구현하는 3가지 방식

1) 일반 : 모델 상에서 Command(CUD) 책임과 Query(R) 책임을 나누어 구현한다.

이는 단일 Data Store에 Command와 Query Model을 분리된 계층으로 나누는 방식 -> Akita와 동일하다.

Database(RDBMS) 는 분리하지 않고 기존 구조 그대로 유지 시키고 Model Layer 부분만 Command와 Query Model로 분리하는 수준으로 간단하게 적용할 수 있다. 이렇게 분리된 Model은 각자의 Domain Layer에 대해서 만 모델링하고 코딩하기 때문에 훨씬 단순하게 구현/적용 할 수 있다. 하지만 동일 Database사용에 따른 성능상 문제점은 개선하지 못한다

 

2) 프리미엄 : Command만 하는 DB와 Query만 전담하는 DB를 분리하여 구현한다.[Broker라는 놈이 두 DB 사이를 연동시켜준다.]

Command용 Database와 Query용 Database를 분리하고 별도의 Broker를 통해서 이 둘 간의 Data를 동기화 처리 하는 방식이다. 이 Case는 데이터를 조회 하려는 대상 서비스(시스템)들은 각자 자신의 시스템(서비스)에 맞는 저장소를 선택 할 수 있기에 폴리글랏 저장 구조 (참고 : 다수의 Database 혼용하여 사용 하는 것을 폴리글랏 저장소 라고 함)로 구성 할 수 도 있다

 

3) 디럭스 : 이벤트 소싱 모델 

이벤트 소싱이란 Application내의 모든 Activity를 이벤트로 전환해서 이벤트 스트림(Event Stream)을 별도의 Database에 저장하는 방식을 말한다. 이벤트 스트림을 저장하는 Database에는 오직 데이터 추가만 가능하고 계속적으로 쌓인 데이터를 구체화(Materialized) 시키는 시점에서 그때 까지 구축된 데이터를 바탕으로 조회대상 데이터를 작성하는 방법을 말한다. (Application내의 상태 변경을 이력으로 관리하는 패턴이 발전된 형태로 보면 이해가 빠를것 같다.)

말그대로, history 테이블에 액션에 대한 데이터만 주기적으로 추가하고, 해당 데이터들을 가공하여, 조회대상 데이터(Stat)을 만드는 것을 의미한다.