CQRS

CQRS란?

CQRS는 Command and Query Responsibility Segregation, "명령과 조회의 책임 분리"를 의미합니다. 이는 프로그램 상에서 명령을 처리하는 책임과 조회를 처리하는 책임이 분리되어야 한다는 것을 의미합니다. 이는 쉽게 말하면 시스템 데이터 변경과 시스템 데이터 조회를 별개로 수행할 수 있게끔 구축하는 것을 의미합니다.

 

이와 유사한 개념으로 CQS (Command and Query Separation)이 있습니다. 보시다시피 매우 유사한 개념이지만, CQS는 명령과 조회의 책임 분리를 연산 단계에서만 분리하는 것을 의미하며, CQRS는 객체(object) 또는 시스템 레벨에서 분리하는 것을 의미합니다. 이를 쉽게 말하면 시스템 데이터에 변경을 가하는 코드와 시스템 데이터를 조회만 하는 코드를 따로 만드는 것이라고 할 수 있습니다.

 

CQRS를 하는 이유

우리가 익히 알고 있는 CRUD를 기반으로 이해해보자면, 명령은 추가,수정,삭제를 의미하고 쿼리는 조회를 의미합니다. 이를 곰곰히 생각해보면, 명령은 한 영역의 데이터를 다루지만, 쿼리는 여러 영역의 데이터를 사용하는 경우가 일반적입니다. 아울러 어플리케이션에서 실제 비즈니스 로직의 대부분은 데이터 변경 작업에서 수행되며, 데이터 조회 작업의 경우 단순 데이터 조회가 대부분이라는 것을 알게 됩니다. 이러한 두 업무를 동일한 Domain Model로 처리하다 보니, 각 업무 영역에서 필요로 하지 않는 Domain 속성들로 인해 복잡도가 증가하고, 설계 의도와 다른 방향으로 변질되게 되는 것입니다.

 

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

 

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

CQRS 적용

구조 차원에서 CQRS를 구현하려면 DB를 분리하거나 프로세스를 분리해야 합니다.

구현 방식에 따라서 이는 프로세스를 나누기도 하고, DB를 나누기도 한다고 합니다. 만약 로직 레벨에서만 명령과 쿼리가 분리된다면 이는 CQS에 가깝습니다.

 

단순하게 생각해보면 책임이 공존하는 이유는 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문입니다. 따라서 CQRS를 구현하는 가장 단순한 방법은 기존의 단일 테이블을 명령 전용 테이블과 쿼리 전용 테이블로 분리하는 것입니다.

 

그렇다면 동일 프로세스를 공유하지만 DB를 구분하는 방법은 어떨까요? 쿼리 모델은 조회 쿼리를 성능이 좋은 메모리 기반 NoSQL(Redis 등)을 사용하고, 명령 모델을 트랜잭션을 지원하는 RDBMS를 사용할 수 있습니다. 이 경우에는 Redis에 저장된 변경 내용들이 쿼리 DB에 늦지 않게 반영되어야 한다는 점을 유의해야 합니다. 이것은 메시지 큐를 통해 실제 데이터 변경이 일어나는 시점에 이벤트를 발생시켜 캐시를 업데이트하는 방식으로 진행할 수 있습니다.(출처: https://jaehoney.tistory.com/254)

그리고 다른 프로세스와 다른 DB를 사용하여 명령과 쿼리를 구분하는 전략은 MSA에 적용됩니다. 명령을 수행하는 별도의 프로세스가 별도의 DB에 있고, 쿼리 수행 프로세스는 또 다른 별도의 DB를 이용하게 됩니다. 물론 이 경우에도 위와 같은 방식으로 변경 내용들이 쿼리 DB에 늦지 않게 동기화 되어야 합니다.

 

 

참고:

CQRS란 무엇인가?

 

[CQRS 아는 척하기] CQRS의 기본 개념

 

CQRS란?

 

CQRS 패턴에 대한 오해 풀기

 

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