Chapter 11. CQRS

단일 모델의 단점

주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 한다.

예를 들면 Order에서 주문 정보를 가져와야 하고, Product에서 상품 이름을 가져와야 하고, Member에서 회원 이름과 ID를 가져와야 한다.

 

조회 시 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야 한다.

식별자를 이용해 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 JPA의 쿼리 관련 최적화 기능을 사용할 수 없다.

애그리거트 간 연관을 식별자가 아닌 직접 참조하는 방식으로 구현해도 고민이 생긴다.

같은 연관도 즉시 로딩이나 지연 로딩으로 처리해야하기 때문이다.

 

이런 고민이 발생하는 이유는 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문이다.

ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와

출력하는 기능을 구현하기에는 고려할 게 많아서 구현을 복잡하게 만드는 원인이 된다.

 

이러한 구현 복잡도를 낮추는 방법에는, 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것이다.

 

CQRS

CQRS는 Command Query Responsibility Segregation의 약자로, 

상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

 

CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.

예를 들어 명령 모델은 객체 지향에 기반해서 도메인 모델을 구현하기에 적당한 JPA를 사용하고

조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 사용하는 마이바티스나 queryDSL을 고민해볼 수 있다.

 

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

조회 기능 요청 비율이 월등히 높은 서비스를 만드는 개발팀은 조회 성능을 높이기 위해 다양한 기법을 사용한다.

쿼리를 최적화해서 쿼리 실행 속도 자체를 높이거나, 메모리에 조회 데이터를 캐싱 해서 응답 속도를 높이기도 한다.

 

이렇게 조회 성능을 높이기 위해 다양한 기법을 사용하는 것은 결과적으로 CQRS를 적용하는 것과 같은 효과를 만든다.

메모리에 캐싱 하는 데이터는 DB에 보관된 데이터를 그대로 저장하기보다는 화면에 맞는 모양으로 변환한 데이터를 캐싱할 때 성능에 더 유리하다.

 

이러한 CQRS는 장점이 많아보이지만, 단점도 분명히 존재한다.

우선 구현해야할 코드가 많다. 단일 모델을 사용할 때 발생하는 복잡함 때문에 발생하는 구현 비용과 조회 전용 모델을 만들 때 발생하는 구현 비용을 따져봐야 한다.

도메인이 복잡하거나 대규모 트래픽이 발생하는 서비스라면 조회 전용 모델을 만드는 것이 향후 유지 보수에 유리하다.

반면에 도메인이 단순하거나 트래픽이 많지 않은 서비스라면 조회 전용 모델을 따로 만들 때 얻을 이점이 있는지 고려해봐야 한다.

 

또 더 많은 구현 기술이 필요하다.
단순히 JPA만 쓰던 사람이 조회 전용 기술을 위한 다른 기술들도 적용해야하기 때문이다.