CQRS (Command and Query Responsibility Segregation)

1. CQRS 란?

명령과 쿼리의 책임 분리라는 뜻으로 데이터베이스로부터 읽기와 변경을 분리하는 패턴이다.
명령측은 create, update, delete 요청을 담당하고, 쿼리측은 읽기 전용 복제본을 사용하여 query 부분을 담당한다.

어플리케이션의 퍼포먼스, 확장성, 보안성을 극대화할 수 있다.

여러 요청으로부터의 여러 업데이트 명령들에 대한 충돌을 방지할 수 있다.

 

2. 기존 아키텍처의 문제점

전통적인 아키텍처에서는 데이터베이스에서 조회와 업데이트를 하는데 같은 데이터 모델이 사용되었다.

간단한 CRUD에서는 문제가 없지만, 좀 더 복잡한 어플리케이션에서 이러한 방식은 유지보수를 어렵게 만들 수 있다.

하나의 데이터 모델이 많 을 로직을 수행 한다면, 너무 많은 것을 수행하는 복잡한 모델이 될 것 이다.

또한 읽기와 쓰기의 부하는 같지 않아서, 각각에 대해 다른 성능이 요구된다.

 

3. CQRS

CQRS는 명령(Command)을 통해 데이터를 쓰고, Query를 통해 데이터를 읽는다.

1. 명령은 데이터 중심적이 아니라 수행할 작업 중심이 되어야한다.
   A를 예약됨으로 변경한다가 아니라 A 예약과 같이 생성되어야 한다.
2. 명령은 비동기적으로 수행된다.
3. 쿼리는 DB를 수정하지 않는다.
   어떠한 도메인 로직도 캡슐화하지 않은 DTO만을 반환한다.

CQRS 아키텍처는 독립적으로써, DDD와 CQRS를 주로 같이 사용하기는 하지만 DDD에 국한된 기법은 아니다.

CQRS의 장점은 다음과 같다.

1. 독립적인 스케일링
   CQRS는 읽기와 쓰기 각각에 대해 독립적으로 스케일링하는 것을 가능하게 해준다.
   이는 훨씬 더 적은 Lock 경합이 발생하는 것을 가능케 한다.
2. 최적화된 데이터 스키마
   읽기 저장소는 쿼리에 최적화된 스키마를 사용할 수 있고, 쓰기 저장소는 쓰기에 최적화된 스키마를 사용할 수 있다.
3. 보안
   읽기와 쓰기를 분리함으로써, 보안 관리가 용이해진다.
4. 관심사 분리
   읽기와 쓰기에 대한 관심사 분리는, 시스템의 유지보수를 더 쉽게 해주고 유연하게 해준다.
   대부분의 복잡한 비지니스 로직은 쓰기 모델에 들어가고, 상대적으로 읽기 모델은 간단해진다.
5. 간단한 쿼리
   읽기 저장소의 materialized view를 통해, 복잡한 조인문을 사용하지 않을 수 있다.

 

4. 구현 이슈

1. 복잡성
   CQRS의 기본 아이디어는 간단하지만, 만약 이벤트 소싱 패턴을 포함할 경우에는 더 복잡해질 수 있다.
2. 메세징
   메세징이 CQRS의 필수 요소는 아니지만, 명령을 수행하고 업데이트 이벤트를 발행하는 것이 보편적인 사용 방법이다.
   이 경우 어플리케이션은 반드시 메세지 실패나 중복 메세지와 같은 것들에 대한 처리를 해야 한다.
3. 데이터 일관성
   만약 읽기/쓰기 저장소가 분리된다면, 읽기 데이터가 최신 데이터가 아닐 수 있다.
   읽기 저장소에는 쓰기 저장소의 변경 사항들이 반영되어야 하는데, 반영에 딜레이가 생기기 때문이다.