CQRS - Command Query Responsibility Segregation

 

 

CQRS

• DB를 읽기 및 쓰기 작업 분리
  • 비효율적인 조인이나 복잡한 쿼리를 피하기 위해 사용
• Command
  • 데이터 상태를 애플리케이션에 반영/변경
• Query
  • 복잡한 조인 작업 처리, 결과 반환
• 애플리케이션 성능 개선
  • CQRS
  • 이벤트 소싱 패턴

 

CQRS Level

단계	분리 수준	장점	단점	Usecase
1단계	Controller 및 Service 만 분리	간단한 구조, 구현 난이도 낮음	성능상 큰 장점 없음, 확장성 제한적	소규모, 프로토타입, MVP 프로젝트
2단계	Controller, Service, 데이터 모델 (DB Schema)	읽기 모델을 조회 최적화하여 성능 향상 가능	구현 및 관리 복잡성 증가	중간 규모 프로젝트 (조회 성능 중요)
3단계	Controller, Service, 데이터 모델 (DB Schema), 물리적 DB 분리	읽기/쓰기 성능 및 확장성 극대화	복잡성, 비용, 관리 난이도 증가	대규모, 고성능, 고확장성 필요 프로젝트

 

 

Event Sourcing Pattern

 

• Application -> 엔티티의 상태 + 데이터 저장
• 빈번한 DB 업데이트 작업
  • 데이터베이스 성능, 응답성 및 확장성 한계에 부정적인 영향으로 인해 상태관리를 별도 처리
• Event Sourcing Pattern
  • 데이터의 변경 이력(상태 변화)을 DB(Event Store) 저장
  • 상태를 직접 저장하지 않고, 발생한 이벤트들을 저장
  • 저장된 이벤트를 재생(Replay)해서 상태 복원
  • 최신 데이터 상태만 DB에 저장 X
  • 모든 이벤트를 순차적으로 DB에 저장 O
• Event Store
  • 이벤트 데이터베이스 -> 이벤트 저장소
• 데이터가 변경될 때마다 새 레코드 생성
  • 발생한 이벤트의 순차적 기록
  • 기록(저장) 된 이벤트를 재생(Replay)하여 현재 상태 복원
  • Replay Events -> 데이터의 최신 상태로 빌드 가능
• 순차적 이벤트 목록
  • Materialized View 생성
  • 쿼리를 수행하기 위한 데이터의 최종 상태 사용
  • 이벤트를 통한 상태 관리와 복원
• 이벤트 저장소
  • Read DB로 변환
  • 메시지 브로커 시스템의 Pub/Sub 패턴 사용

 

Reference
마이크로서비스 디자인 패턴 완벽 가이드
https://www.inflearn.com/course/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-msa