CQRS아는척하기
명령(시스템 데이터 변경) 역할을 수행하는 구성 요소와
쿼리(시스템 데이터 조회) 역할을 수행하는 구성 요소를
나누는 것이 CQRS
명령과 조회에 단일 모델을 사용하면?
=> 이도 저도 아닌 잡탕
1. 코드 역할/ 책임 모호
2. 의미/가독성 등 나빠짐
3. 유지보수성이 떨어짐
명령과 쿼리는 다루는 데이터가 다름
1. 명령 -> 한 영역의 데이터
2. 쿼리 -> 여러 영역의 데이터
명령과 쿼리는 코드 변경 빈도, 사용자 다름
=> ex) 백오피스의 주문 목록 조회 기능,
사용자의 주문 기능
=> 변경 빈도가 다른 기능이 한 코드에 있으면
1. 서로 다른 이유로 코드가 바뀌고
2. 이는 곧 책임의 크기가 적당하지 않다는 것
기능마다 성능 요구가 다름
=> 기능마다 트래픽 패턴, 성능 요구 다름
1. 사용자의 상품 목록 조회, 상품 상세 조회
2. 사용자의 댓글 등록
3. 사용자의 주문
4. 백오피스의 판매 수치
=> 기능마다 서로 다른 성능 향상 방법 필요
1. 단일 모델로는 다양한 성능 향상 기법 적용이 어려울 수 있음
그래서 명령과 쿼리를 구분
예를 들어 쿼리 캐시 명령 비동기 사용하여 성능향상
구현: 같은 프로세스, 같은 DB(코드 수준에서 분리, 데이터 분리X)
=> 가장 단순
=> 명령/쿼리 동일 데이터 보장
구현: 같은 프로세스, 같은 DB, 다른 테이블(코드 수준에서 분리, 데이터도 분리)
=> 쿼리 전용 테이블 사용 ex) 최근 조회수 많은 글 목록
=> 명령이 쿼리 전용 데이터 변경 유발
구현: 같은 프로세스, 다른 DB
다른 DB에 변경 전파 필요
구현: 다른 프로세스, 다른 DB
마이크로서비스....
다른 DB로 변경 전파
1. 명령이 직접 쿼리 DB변경하는 방법
- 카프카와 같은 메시징 큐 사용하는 것도 포함
=> 구현 단순, but 데이터 유실 가능(쿼리 DB나 메시징문제, 명령까지 문제 발생 가능)
- 변경내역 기록(테이블 구성), 별도 전파기 이용해서 변경내역 전달
=> 한 트랜잭션에서 처리가 가능하므로 데이터 유실 X, but 전파기 구현 - DB가 제공하는 CDC사용
DB binary로그를 읽어 변경 데이터를 확인하고 변경된 데이터를 쿼리쪽에 전달
다른 DB 사용시 주의 사항
1. 데이터 유실
=> 유실 허용 여부에 따라 DB 트랜잭션 범위 중요
2. 허용 가능 지연 시간
3. 중복 전달
