CQRS 란?

CQRS는 Command Query Responsibility Segregation (명령과 조회의 책임 분리) 의 약자로 이름처럼 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS 의 핵심 ❗️

CQRS는 초기 CQS에서 시작되어 확장되었다.
CQS는 Command Query Separation의 약자로 시스템에서 처리되는 명령과 조회, 이 두 작업을 정의하는 핵심 개념이자, 이 둘을 분리 시키는 디자인 패턴이다.

그렇다면 명령과 조회에 대해서 정의를 내릴 필요가 있다.
CQRS에서 명령은 상태를 변경하는 작업 을 의미하며 조회는 상태를 반환하는 작업을 의미 한다.

CQRS 패턴을 마이크로서비스에 적용하여 살펴보면 마이크로서비스의 핵심은 CQRS는 서비스별 데이터 저장소를 각기 다르게 채택 한다는 점이다.

이때 서비스 성능 향상을 위해서 인스턴스를 스케일 아웃하여 여러 개로 실행할 경우 빈번한 명령과 조회 작업으로 리소스 교착상태가 발생할 수 있고 뿐만 아니라, 통상적으로 명령보다 조회 요청이 훨씬 많이 사용되기 때문에, 하나의 서비스 내에 이러한 모든 기능을 넣어두면, 조회 요청 빈도가 증가함에 따라 명령기능도 함께 확장해야 하기 때문에 도메인의 복잡도가 높아진다.

이러한 문제점을 해결하기 위한 방법 중 하나로, CQRS 패턴을 사용한다. 기존에 하나의 데이터 저장소에 CRUD 작업을 모두 처리 했다면, CQRS는 요청을 크게 명령(Create, Update, Delete)과 조회(Read)로 나누어 처리한다.

도식으로 살펴보면, 먼저 단순히 모델을 나누는 형태로 명령과 조회를 분리할 수 있다. 하지만 하나의 데이터 저장소를 사용한다는 면에서 완벽하게 마이크로서비스 설계 철학과 부합하는 것은 아니다.

또는 아예 물리적으로 명령 작업과 조회 작업을 위한 저장소를 따로 준비 할 수 있다. 이처럼 명령과 조회를 각각 분리 하면 명령(쓰기) 요청의 부하를 줄이고, 조회 대기 시간을 줄이는 등 다양한 이점을 누릴 수 있다.

CQRS 패턴은 이벤트 소싱 패턴과 함께 사용되기도 한다. 기본적으로 앞서 살펴본 메세지 브로커를 이용한 이벤트 주도의 아키텍처의 경우, 이벤트로 인해 상태가 변경된 경우, 이를 데이터 모델로 처리 하고 최종값을 반영하는 형태 를 의미한다. 하지만 이벤트 소싱 패턴의 경우, 이를 데이터로 저장하는 것이 아니라 상태 변경 이벤트 자체를 저장하는 기법 을 의미한다.

이렇게 하면 메세지 브로커와 데이터 저장소를 분리 하지 않아도 될 뿐만 아니라, 데이터로 변경하는 복잡한 과정이 없어 쓰기 속도도 빠르고, 이벤트에 따른 CRUD를 전부 처리할 필요 없이, 이벤트 발생/조회만 처리하면 되어 서비스 확장을 조금 더 용이하게 할 수 있다.

다시 말해, 이벤트는 한 번 발생한 후에 수정되지 않고 업데이트나 삭제 없이 입력만 되는 개념이기 때문에 저장소에 이러한 이벤트를 저장(쓰기)해두고, 필요한 데이터가 생기는 시점에 축적된 이벤트를 조회(읽기) 하기만 하면 되는 형태로, CQRS와 같은 맥락의 패턴을 가진다. 따라서 이벤트 소싱과 CQRS는 함께 사용하기 좋은 패턴이다.