CQRS

CQRS란?

CQRS는 Command Query Responsibility Segregation(명령과 조회의 책임 분리)의 약자

명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것

 

CQRS는 초기 CQS에서 시작되어 확장,

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

CQRS에서 명령은 상태를 변경하는 작업을 의미하며 조회는 상태를 반환하는 작업을 의미

 

마이크로서비스의 핵심은 서비스별 데이터 저장소를 각기 다르게 채택한다는 점

 

이때 서비스 성능 향상을 위해서 인스턴스를 스케일 아웃하여 여러 개로 실행할 경우 빈번한 명령과 조회 작업으로 리소스 교착상태가 발생할 수 있음

뿐만 아니라, 통상적으로 명령보다 조회 요청이 훨씬 많이 사용되기 때문에, 하나의 서비스 내에 이러한 모든 기능을 넣어두면, 조회 요청 빈도가 증가함에 따라 명령기능도 함께 확장해야 하기 때문에 도메인의 복잡도가 높아짐

 

이러한 문제점을 해결하기 위한 방법

 

1. CQRS 패턴

 > 기존에 하나의 데이터 저장소에 CRUD 작업을 모두 처리했다면, CQRS는 요청을 크게 명령(Create, Update, Delete)과 조회(Read)로 나누어 처리

 

먼저 단순히 모델을 나누는 형태로 명령과 조회를 분리할 수 있음

하지만 하나의 데이터 저장소를 사용한다는 면에서 완벽하게 마이크로서비스 설계 철학과 부합하는 것은 아님

 

[출처] 코드스테이츠

 

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

 

[출처] 코드스테이츠

 

CQRS 패턴은 이벤트 소싱 패턴과 함께 사용되기도 함. 

메시지 브로커를 이용한 이벤트 주도의 아키텍처의 경우, 이벤트로 인해 상태가 변경된 경우, 이를 데이터 모델로 처리하고 최종값을 반영하는 형태를 의미.

하지만 이벤트 소싱 패턴의 경우, 이를 데이터로 저장하는 것이 아니라 상태 변경 이벤트 자체를 저장하는 기법을 의미

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

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

 

[츌처] 코드스테이츠