메모) CQRS 적용하기

 

• 적은 update & 많은 read인 경우, ux가 자주 변하는 경우, 데이터 관리와 뷰의 책임을 나눠야 할 때, 시스템의 확장성을 높이고 싶을 때
• 모델 분리하기 - 명령 모델 / 조회 모델
• DTO 사용, 엔티티 일부만 사용
• 정규화된 디비 스키마를 비정규화
• 중간에 캐시
• 명령 모델 데이터 변경 => 명령 모델 & 조회 모델 생성 및 저장 (비정규화된 데이터)
• 조회 모델을 가져올 때는 join 등의 연산 작업을 자제, 가능한 디비값 그대로 표출
• NoSQL, 도메인 별 적절한 디비 선택
• 두 저장소간의 일관성 유지 필요
• 조회 모델 생성시 부담된다면, 역할 분리 by 이벤트 소싱
  • 명령 모델 데이터 변경 => publish event => consume event, 조회 모델 생성 및 저장
  • 이벤트 내용: 변경 대상 id, 변경 감지할 property (optional), 실행 method 지정, 데이터 변경자 이름(누가, 언제)
  • 변경 모델 데이터를 모두 전송하면 오히려 복잡해질 수 있어 엔티티 id만 전송해서 변경 모델 조회 후 조회 모델 생성
  • 이벤트가 수백개일 경우 중복으로 처리하면 비효율적: 이벤트 로깅(elasticsearch) => 변경 대상 버퍼에 저장(redis) => 스케쥴러(spring) => 조회 모델 생성 및 저장
  • Amazon SNS, SQS: 계정당 TPS 제한 있음, 어플리케이션 코드 기반 이벤트 퍼블리싱, 기본적인 queue 기능
  • CDC (Change Data Capture): Kafka Connect
• 변경 감지 방법: JPA EntityListeners, Hibernate EventListener, Hibernate Interceptor, Spring AOP
• 엔티티 변경 감지의 단점: Hibernate 의존적, 쿼리 직접 실행시키는 로직에는 예외 처리 필요, 기존 엔티티에 추가 작업 필요
• 필요한 특정 도메인에만 적용 (e.g. 카탈로그)
• 데이터가 단방향으로 흐를 수 있도록 로직 정리