CQRS(Command and Query Responsibility Segregation) 명령-질의 책임분리란?

CQRS는 Command and Query Responsibility Segregation(명령과 조회의 책임 분리)을 나타냅니다. 이름처럼 시스템에서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다. 이제 명령과 조회에 대해 정의할 필요가 있습니다. CQRS에서 명령은 시스템의 상태를 변경하는 작업을 의미하며 조회는 시스템의 상태를 반환하는 작업을 의미합니다. 정리하면, CQRS는 시스템의 상태를 변경하는 작업과 시스템의 상태를 반환하는 작업의 책임을 분리하는 것입니다.

 

모든 연산이 명령과 조회로 쉽게 양분되지 않는다. 개념적으로 어려운 경우도 있고 동시성 등 기술적인 문제도 있다. Martin Fowler는 스택 자료구조의 pop() 연산을 예로 들었다.

 

너무 단순하다고 생각될지 모르겠지만 이것이 전부입니다. 어쩌면 CQRS에 대한 오해는 CQRS가 생각보다 복잡하지 않기 때문일지도 모릅니다. 이 단순한 규칙이 몇 가지 응용기술과 조합되어 시스템에 적용되면 그 모습은 무척이나 다양합니다. 그만큼 CQRS를 설명하는 정보들이 표현하는 구현체의 모습이 제각각이고 여기서 혼란이 시작될 가능성이 있습니다. CQRS를 설명할 때 명령 처리기 패턴(Command Processor Pattern)을 얘기하기도 하고 다른 경우는 다계층 아키텍처(Multitier Architecture)나 이벤트 소싱(Event Sourcing)을 다룹니다. 이것들 모두와 DDD(Domain-Driven Design)를 조합하기도 합니다.

CQRS를 처음으로 소개한 Greg Young은 CQRS는 아주 단순한 패턴(“CQRS is a very simple pattern”)이라고 말했습니다. 물론 Greg Young은 DDD의 고통을 해결하기 위해 CQRS를 사용했다고 하지만 DDD에 국한된 기법은 아닙니다. 이 글에서는 CQRS의 적용 예를 설명하기 위해 다계층 아키텍처를 사용하지만 이것은 단지 하나의 예시일 뿐 CQRS는 아키텍처 독립적입니다. 다시 강조하지만 CQRS 자체는 복잡하거나 거대하지 않습니다. 지금 당장 시스템에 적용해 볼 수 있으며 경우에 따라 이미 실천하고 있을지도 모릅니다.

 

CQRS는 CQS(Command and Query Separation) 원리에 기원한다. 사실 CQRS는 처음에 CQS의 확장으로 얘기되었다. 하지만 CQS는 명령과 조회를 연산 수준에서 분리하는 반면 CQRS는 개체나 시스템 수준에서 분리한다.

 

도메인의 구조(ORM)

상태를 변경할 때와 조회할 때 단일 도메인을 사용하기 때문에 아래와 같은 문제가 발생한다

• ORM은 도메인의 상태 변경을 구현하는 데 적합하지만, 여러 집계(복잡한 조회)에서 데이터를 가져와 출력하는 기능을 구현하다보면 도메인 복잡도가 높아지는 문제가 발생할 수 있다. 여러 도메인이 조인이 걸려있고 다수의 조인 쿼리가 발생하면 그만큼 DB에 부하는 커지게 되며, 도메인 객체의 디자인 자체도 점점 복잡해진다.

즉, 상태를 변경하는 기능과 상태 정보를 조회하는 기능을 분리하여 도메인을 구성하는 것이다.

 

도메인 모델 관점에서 상태 변경 기능은 주로 한 집계의 상태를 변경한다.

• 주문 취소 기능과 배송지 정보 변경 기능은 한 개의 Order 집계에서 진행한다.

조회 기능은 하나의 집계로 조회할 수 있지만, 두개 이상의 집계에서 데이터를 조회할 수 있다.

• 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다.

 

<단일 DB 구조>

 

 

DB를 공유하고 Model을 Command와 Query Model로 분리하여 적용하였다. 쉽고 단순하게 적용할 수 있지만, 같은 Database를 사용하기 때문에 성능에 대한 문제점은 해결하기 힘든 구조이다.(도메인 분리에 따른 복잡도를 낮춰주는 효과는 있다.)

 

<다중 DB 구조>

 

 

Command 도메인 DB와 Query 도메인의 DB를 분리하고 Message broke(Kafka,RabbitMQ)를 이용해 Data 동기화를 처리 하는 방식이다. 각각의 Model에 적합한 구조를 사용할 수 있는 장점이 있다. 하지만 동기화 처리를 위한 Message Broker의 고가용성과 메시지의 신뢰성에 대한 보장을 관리해주어야하는 관리포인트가 생긴다.

 

위의 두개 말고도 Event Sourcing 구조를 이용하여 CQRS를 설계할 수 있다. 그렇다면 CQRS를 적용함으로써 생기는 장단점은 무엇이 있을까?

 

CQRS 장점/단점

 

장점	단점
각각의 도메인 목적에 맞게 집중하여 개발할 수 있다.	구현해야할 코드가 더 많아진다.
명령과 쿼리 파이프라인을 원하는대로 최적화하면서 다른 요소가 깨질 위험은 거의 없다.	더 많은 구현 기술이 필요해진다.
	유지 비용이 증가한다.

 

<참고>

DDD - CQRS

 

CQRS란 무엇인가?