CQRS
CQRS (Command Query Responsibility Segregation)
흔히 CRUD (생성, 조회, 업데이트, 삭제) 라고 불리우는 기본적인 4가지 기능들을 상태 변경 명령(CUD), 조회 쿼리(R) 이 두 가지로 나누어 관리하는 방법이다. 명령 모델 (CUD) 와 조회 모델 (R) 을 각각 설계한다.
탄생 배경
기존의 CRUD 아키텍처는 데이터베이스에 쿼리를 하고 업데이트를 하는데에 동일한 Domain Model을 사용합니다. 예를들어 주문 시스템의 Domain Model 은 주문(order)입니다. 주문을 할때에는 배송정보도 필요하고, 상품정보도 필요하고, 추천상품 정보, 고객정보 등 다양한 정보들이 필요합니다. 최초 설계에는 주문만 처리하려고 만들었지만, 유지보수 및 신규 서비스가 생겨나면서 점점 초기 설계와는 다르게 변질이 되어갑니다. 이는 UX 가 발전하고, 사용자의 요구사항이 늘어나고, 비지니스가 복잡해 지는 상황에서는 생기게 되는 문제입니다.
이러한 상황들을 관찰해 보니, 비지니스 로직은 대부분 데이터 변경 (CUD) 에서 처리되고, 조회(Read) 은 단순 데이터 조회가 대부분이 되는것을 볼 수 있었습니다. 이것을 하나의 Domain Model 에서 처리하게 되니, 필요치 않은 외부 속성들과의 연계등의 복잡도가 증가하게 되는 원인을 발견 하였습니다.
이러한 문제를 해결하기 위하여 명령과 조회를 분리하는 방법을 고안하였고 이렇게 나온 방법이 CQRS 입니다. DDD(Domain-driven design) 에서 Object Model 방법론을 해결하기 위하여 CQRS 가 사용되었습니다.
- MSA School
설계 형태
- 쿼리 수준에서만 명령과 조회를 구분하나 데이터베이스는 동일하게 사용.
- 하나의 데이터베이스 안에서 테이블을 각각 설계.
- 서로 다른 데이터베이스로 설계.
장점
- 유연한 모델링
- 명령 모델(Command Model)과 쿼리 모델(Query Model)을 분리함으로써, 각각의 요구 사항에 맞게 모델링 및 로직을 최적화할 수 있다.
- 성능 최적화
- 명령과 쿼리에 대한 부하가 다를 경우, 각각에 대한 확장을 독립적으로 고려할 수 있습니다. 이를 통해 시스템의 성능을 최적화할 수 있다.
- 응답성 향상
- 비동기적으로 처리되는 명령 모델과 미리 계산된 결과를 사용하는 쿼리 모델을 통해 응답 속도를 향상시킬 수 있다.
단점
- 추가적인 복잡성
- 명령과 쿼리를 분리하면서 두 개의 모델을 유지해야 하므로 개발 및 유지보수에 대한 복잡성이 증가할 수 있다.
- 일관성 관리 어려움
- 명령과 쿼리 모델이 독립적으로 유지되기 때문에 데이터 일관성을 유지하기 위해 추가적인 노력이 필요할 수 있다.
- 학습 곡선
- CQRS는 전통적인 CRUD 기반의 아키텍처와 다른 접근 방식을 채택하므로, 팀 내의 학습 곡선이 존재할 수 있다.
참고자료.
https://github.com/microsoftarchive/cqrs-journey
https://www.msaschool.io/operation/integration/integration-six/