🧠 개념 요약
CQRS : 명령, 쿼리 책임 분리 패턴
읽기, 쓰기 라는 명령을 분리하기 위해 데이터를 서로 다른 위치에 접근하게 만듦으로써 개선의 여지가 많아진다.
- 독립적인 최적화가 가능
- 성능
- 확장성
- 보안성
전통적인 아키텍처에서 read, writer 모든 명령을 한곳에서 처리하여 다소 이러한 문제가 생긴다
- 쓰기 작업으로 인해 데이터 불일치가 생길 수 있다.
- 튜닝을 위해 설계가 복잡해진다.
- 일부 집약적인 데이터는 사용하는게 다 다르다.
- 쓰기는 극히 일부만 수정될 수 있고, 오히려 읽기도 그 전체 또는 일부만을 사용한다.
- 쓰기와 읽기 자체에서는 서로다른 최적화를 위해 요구사항이 다르다.
- 잠금 으로인해 성능이 다소 좋지 못함
- 보안성에도 문제
- 부득이하게 서로 감쳐야 하는 부분이 서로 상충되어 의도치 않게 은닉 하지 못 할 수 있다
장점
- 독립적인 확장성 가질 수 있다.
- 각 최적화된 스키마도 가질 수 있고 쿼리도 간단해진다
- 보안성도 좋아지고
- 관심사 분리로 코드 가독성이 올라간다
🔍 구현 방법
읽기, 쓰기 연산에 대한 명령을 위한 데이터 엑세스를 서로 다른 위치에서 하도록 한다
- 물리적으로 DB를 다른걸 사용하거나
- 하나의 db에서 서로다른 테이블 관계를 갖거나
single database 일때,
Multiple Instace 일때,
🕢 사용시점
협업 환경일떄
- 코드 통합시 conflict 가 자주 일어나지 않게된다.
- 코드가 분리되어 운영되어 가독성이 좋아져
- 휴먼에러 발생 가능성이 줄어든다
성능향상(튜닝)이 필요할때
관심사 분리 개발을 해야할떄
마이그레이션 할때
- 새로운 버전 향상을 위해서 안정적 점진적으로 안정적으로 버전 향상이 가능
- 부분적으로 read쪽만 버접업을 먼저 실시하고 시간적 여유를 두고 write연산을 중대하게 처리하며 다소 작업이 간단해짐
적합하지 않을때,
- 간단할때는 굳이 이렇게 어렵게 안가도 된다
- 단순 CRUD 일때
🚨 고려해야될 부분
복잡도 증가
- 이벤트 소싱 패턴과 결합되어 다소 복잡도가 올라갈 수 있다
메시징 시스템의 예외적인 부분
- 메시지 실패, 중복, 재시도. 이런 메시지 전송을 확실히 보장해야한다
이벤트 실시간 일관성 다소 떨어짐
- 최근 변화를 즉시적으로 반영하지 못하고 약간의 딜레이가 생길 수 있다.
- 오래된 데이터가 보여 작업할 수 있음.
📝 한 줄 정리
읽기, 쓰기 명령을 위해 데이터를 서로 다른 위치로 접근하도록 하는 패턴
