TIL

Chqpter11 CQRS

11.1 단일 모델의 단점

• 조회 기능을 구현할 때 여러 애그리거트에서 데이터를 가져와야 하는 경우가 있다.
  • 조회 기능 특성상 성능이 빠를수록 좋은데 여러 애그리거트가 필요하다면 구현 방법을 고민해야 한다.
  • 식별자를 이용해 다른 애그리거트를 참조하는 방식을 사용하면 조인 최적화를 사용할 수 없다.
  • 직접 참조를 이용한다해도 보통은 지연 로딩을 사용하기에 조회하는 경우에만 즉시 로딩을 하는 등의 복잡한 설계가 필요해진다.
• 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문에 이런 고민이 발생하게 된다.
• 상태 변경을 위한 모델과 조회 모델을 분리하면 이런 구현 복잡도를 낮출 수 있다.

11.2 CQRS

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

• CQRS는 복잡한 도메인에 적합하다.
  • 도메인이 복잡할 때 명령과 조회를 단일 모델로 사용하면 구현이 필요 이상으로 복잡해진다.
• CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다.
  • ex) 명령 모델은 객체지향 기반의 JPA를, 조회 모델엔 마이바티스를 사용
• 명령 모델과 조회 모델이 같은 기술을 사용할 수도 있지만 서로 다른 데이터 저장소를 사용할 수도 있다.
  • ex) 명령 모델은 RDBMS, 조회 모델은 NoSQL
  • 두 저장소 간 데이터 동기화는 이벤트를 활용해서 처리할 수 있다.
  • 글로벌 트랜잭션을 사용해 실시간 동기화를 할 수도 있지만 전반적인 성능이 떨어진다.
  • 특정 시간 안에만 동기화해도 된다면 비동기로 데이터를 전송하면 된다.
    • 통계 데이터는 1시간 단위로 최근 데이터를 반영해도 문제되지 않을 때가 많다.

11.2.1 웹과 CQRS

• 일반적인 웹 서비스는 상태 변경 요청보다 조회 요청이 많다.
• 조회 비율이 월등히 높은 서비스를 만드는 개발팀은 조회 성능을 위해 다양한 기법을 사용한다.
  • 쿼리 최적화, 데이터 캐싱, 조회 전용 저장소 사용

11.2.2 CQRS 장단점

• 장점
  • 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다.
  • 조회 성능을 향상시키는 데 유리하다.
• 단점
  • 구현해야 할 코드가 더 많다.
  • 더 많은 구현 기술이 필요하다.
• 도메인이 복잡하지 않은데 CQRS를 도입하면 두 모델을 유지하는 비용만 높아진다.
• 트래픽이 높은 서비스인데 단일 모델을 고집하면 유지 보수 비용이 오히려 더 높아질 수 있다.