[CQRS] CQRS(Command and Query Responsibility Segregation)란?

CQRS란?

CQRS란 Command and Query Responsibility Segregation의 줄임말로, Command(Create, Update, Delete)와 Query(Read)의 책임을 분리하자는 패턴입니다. 

대부분 DB 트랜잭션은 DB로부터 데이터를 읽어 들여 화면에 뿌려주는 것입니다. 이 과정에서 DB에서 데이터를 읽는 시점과 화면에 렌더링 되는 시점은 반드시 차이가 생기기 마련입니다. 즉, 렌더링 하는 데이터는 이미 실제 데이터와 차이가 생기게 되는 것입니다. CQRS 패턴은 이 점을 인지하고, 굳이 하나의 DB안에서 CRUD의 Read 기능과 나머지 CUD(Create, Update, Delete) 기능을 공존시키는 거의 의미가 없다고 말합니다.  어차피 Read의 결과물은 정도의 차이가 있을 뿐 실제 데이터와 다르기 때문에 캐시와 같은 DB로 돌려서 더욱 빠르게 사용자들이 읽어 들일 수 있도록 하고, CUD 기능은 메시지 큐를 통해 실제 데이터를 변경시키고 변경이 일어나는 시점에 이벤트를 발생시켜 캐시를 업데이트하는 방식으로 진행하자는 것입니다.

 

<기존 방식>

<CQRS 방식>

어떻게 등장했는가?

CQRS 패턴의 등장은 DDD(Domain Driven Development)로부터였습니다. DDD의 Object Model 방법론 적용 시 나타났던 여러 문제점들을 해결하기 위해 등장하였으나 DDD에만 국한된 기법은 아닙니다.
전통적인 CRUD 기반의 어플리케이션을 개발하고 운영하다 보면, Domain Model의 복잡도는 증가되기 마련이고, 유지보수 비용은 증가합니다. 시도 때도 없이 달라지는 요구사항을 충족하는 모델을 만드는 것은 어려운 일이며, 이런 복잡한 모델로 업무를 처리하게 되면 부하는 더욱 커집니다. 

이러한 문제를 해결하기 위해 고민한 결과, 어플리케이션에서 실제 비즈니스 로직의 대부분은 데이터 변경 작업에서 수행되며, 데이터 조회 작업의 경우 단순 데이터 조회가 대부분이라는 것을 알게 됩니다. 이러한 두 업무를 동일한 Domain Model로 처리하다 보니, 각 업무 영역에서 필요로 하지 않는 Domain 속성들로 인해 복잡도가 증가하고, 설계 의도와 다른 방향으로 변질되게 되는 것입니다. 

그래서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하여  이러한 문제를 해결해 보자는 생각에서 CQRS가 등장하게 되었습니다. 명령과 쿼리에서 분리된 모델을 사용하면, 기존의 단일 데이터 모델에 비해 디자인과 구현이 간단해지고, 성능, 확장성, 보안을 최대화할 수 있습니다. 

물론, 모든 연산이 Command와 Query로 쉽게 양분되지는 않습니다. 개념적으로 더 어려울 수도 있고, 동시성 문제와 같은 기술적인 문제가 발생할 수도 있기 때문입니다. 따라서 CQRS를 도입했을 때 확실한 이점이 존재하는 경우에만 이 패턴을 적용하여야 합니다. 

 

 

[ References ]

CQS

Command–query separation - Wikipedia

Bounded Context

bliki: BoundedContext

Cutting Edge - CQRS for Common Application

Cutting Edge - CQRS for the Common Application