1. CQRS 아키텍처

• 최범균님의 "CQRS 아는 척하기"를 참고하여 작성했습니다

명령 역할을 수행하는 구성 요소와 쿼리 역할을 수행하는 구성 요소를 나누는 아키텍처

• Command : 명령
  • 시스템 데이터 변경
  • ex) 주문 생성, 수정, 취소
• Query : 조회
  • 시스템 데이터 조회
  • ex) 주문 조회
• Responsibility : 책임
  • 구성 요소의 역할
  • 구성 요소 ex) 클래스, 함수, 모듈, 패키지, 웹서버, DB 등
• Segregation : 역할에 따라 구성 요소 나누기

---

2. 단일 모델의 단점

명령과 쿼리를 구분해 피할 수 있는 문제들

• 기능 추가에 따라 코드의 책임이 모호해지고, 기능마다 다른 테이블에 의존하게 된다

• 명령은 한 영역의 데이터를 다루는데 반해 쿼리는 여러 영역의 데이터를 사용한다

• 명령과 쿼리는 코드 변경 빈도와 사용자가 다르다. 서로 다른 이유로 모델의 코드가 바뀐다는 것은 책임의 분리가 적절하지 않다는 것이다.

• 기능마다 요구 성능이 다르다. 단일 모델은 기능에 맞는 다양한 성능 향상 기법 적용이 어렵다

  • ex) 명령 : 사용자 주문 기능, 쿼리 : 백오피스 주문 목록 조회

---

3. CQRS의 구현

3-1. 같은 프로세스, 같은 DBMS

• 코드 수준에서만 명령과 쿼리가 분리된다

• 데이터의 동일성이 보장된다

3-2. 같은 프로세스, 같은 DBMS, 다른 테이블

• 쿼리 전용 테이블을 사용한다

• 코드 수준, 데이터 수준에서 명령과 쿼리가 분리된다

• 명령이 데이터를 변경할때, 쿼리 전용 테이블도 수정해야한다

3-3. 같은 프로세스, 다른 DBMS

• Redis를 캐시로 하고 쿼리 DB로 사용하는 경우를 생각해볼 수 있다

3-4. 다른 프로세스, 다른 DBMS

• MSA를 생각해볼 수 있다

---

4. 3가지 변경 전파 전략

CQRS 아키텍처에서 여러 DBMS를 사용하게 된다면 변경 전파 전략도 수립해야한다

4-1. 명령이 쿼리 DBMS를 수정

• 구현이 단순하다

• 쿼리 DB 장애시 데이터 유실 가능성이 있다

• 명령 기능이 쿼리 DB까지 접근하기 때문에 명령 기능의 에러 가능성이 높다

4-2. 변경 내용 기록후, 전파기 사용

• 명령 DB에 변경 내용 테이블을 관리해야한다

• 데이터 변경과 변경 내용을 하나의 트랜잭션으로 처리할 수 있어 데이터 유실 방지가 가능하다

• 전파기를 구현해야한다

4-3. DB가 제공하는 CDC 사용

• CDC : 데이터베이스에 있는 데이터의 변경을 파악하고 추적하는 소프트웨어 프로세스

• 명령 DB 바이너리 로그를 읽어 변경을 파악하고, 쿼리 DB에 전달할 수 있다

• 명령 코드가 변경 내용을 관리할 필요가 없다