CQRS 에 관해서 정리

CQRS

 

Command Query Responsibility Segregation 의 약자로 

명령과 쿼리의 책임을 분리하라는 의미를 가지고 있다.

 

예를 들어, 영화를 예매 하거나 예매를 취소하는 것은 Command(명령)이고 영화 예매 내역을 조회하는 것은 Query(조회)이다.

 

이를 분리하는 이유는 변경시점의 차이, 요구하는 성능의 차이 때문이다.

 

두 작업이 분리되지 않으면 명령처리를 한 후 데이터를 조회해서 보여줘야할 때, 즉시 데이터를 조회한다.

이는 데이터베이스에서 동시에 읽기와 쓰기가 발생하게 되면서 명령 처리로 인한 데이터 베이스의 락(lock) 이나 트랙잭션 처리로 인해 조회 성능이 저하될 수 있다. 또한, 이렇게 동기화된 상태에서 조회를 처리하면 각각의 요구 사항에 맞는 최적화 모델을 사용할 수 없다.

명령은 데이터가 정확하고 일관성 있게 처리는 것을 요구하고, 조회는 빠른 응답과 효율성을 요구한다. 따라서 각각 요구상항에 맞는 최적화를 원한다면 CQRS 패턴을 적용해야한다.

 

 

CQRS 의 범위

 

1. 단일 Data Store에 Command와 Query Model을 분리된 계층으로 나누는 방식

 

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

 

2. Command용 Database와 Query용 Database를 분리하고 별도의 Broker를 통해서 이 둘 간의 Data를 동기화 처리 하는 방식

이 경우 각각의 Model에 맞게 저장소(RDBMS, NoSql, Cache)를 튜닝하여 사용할 수 있다는 이점이 있다.

 

3. 이벤트 소싱(EventSourcing)을 적용한 구조이다.

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

이벤트 소싱을 구현하려면 여러 기술 스택을 결합해야 하며, 데이터 저장소, 이벤트 처리, 메시징 시스템, CQRS, 이벤트 스냅샷 관리 등을 포함하는 기술들이 필요하다.

 

 

참고 |

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

https://devpoong.tistory.com/145

https://insanelysimple.tistory.com/387