11장 CQRS

11.1 단일 모델의 단점

조회 화면 특성상 조회 속도가 빠를수록 좋은데 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야 한다.

이런 구현 복잡도를 낮추는 간단한 방법이 있는데 그것은 바로 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것이다.

 

11.2 CQRS

시스템이 제공하는 기능은 크게 두 가지로 나눌 수 있다.

1. 상태를 변경하는 기능

2. 사용자 입장에서 상태 정보를 조회하는 기능.

 

도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다.

상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않기 때문에 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다. 단일 모델을 사용할 때 발생하는 복잡도를 해결하기 위해 사용하는 방법이 있는데 바로 CQRS다.

 

CQRS는 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

 

 예를 들어 명령 모델은 객체 지향에 기반해서 도메인 모델을 구현하기에 적당한 JPA를 사용해서 구현하고, 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 떄 좋은 마이바티스를 사용해서 구현하면 된다.

 

물론 같은 구현 기술을 사용할 수도 있다.

 

다른 데이터 저장소를 사용할 수도 있는데, 명령 모델은 트랜잭션을 지원하는 RDBMS를 사용하고, 조회 모델은 조회 성능이 좋은 메모리 기반 NoSQL을 사용할 수 있을 것이다.

두 테이터 저장소 간 데이터 동기화는 10장에서 배운 이벤트를 활용해서 처리한다.

 

일반적인 웹 서비스는 상태를 변경하는 요청보다는 상태를 조회하는 요청이 많다.

조회 성능을 높이기 위해 다양한 기법을 사용하는 것은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만든다. 메모리 캐싱하는 데이터는 DB에 보관된 데이터를 그대로 저장하기 보다는 화면에 맞는 모양으로 변환된 데이터를 캐싱 할 때 성능에 유리하다. 즉, 조회 전용 모델을 캐시 하는 것이다.

대규모 트래픽이 발생하는 웹 서비스는 알게 모르게 CQRS를 적용하게 된다. 단지 명시적으로 구분하지 않을 뿐이다.

 

CQRS 패턴을 적용할 때 얻을 수 있는

장점

 - 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 점.

 - 조회 성능을 향상시키는 데 유리하다.

단점

 - 구현해야 할 코드가 더 많다는 점.

 - 구현 비용

 - 더 많은 구현 기술이 필요.

 

도메인이 복잡하지 않은데 CQRS를 도입하면 두 모델을 유지하는 비용만 높아지고 얻을 수 있는 이점은 없다.

반면에 트래픽이 높은 서비스인데 단일 모델을 고집하면 유지 보수 비용이 오히려 높아질 수 있으므로 CQRS 도입을 고려하자.