CQRS 기본 스텝

 

CQRS

CQRS는 Command Query Responsibility Segregation 의 약자이며,

Command(명령)과 Query(쿼리)의 책임 분리라는 의미를 가지고 있다.

 

Query는 SQL Query를 의미하는 게 아니다. 그럼, Command와 Query는 각각 무엇을 의미할까?

• Command (명령)
  • 애플리케이션의 데이터를 변경 ( 예약, 예약취소)
• Query (쿼리)
  • 애플리케이션의 데이터를 조회 (예약내역 조회)

 

따라서, CQRS를 다시 설명하자면

1. 애플리케이션 데이터를 변경하는 명령 역할을 수행하는 구성 요소
2. 애플리케이션 데이터를 조회하는 쿼리 역할을 수행하는 구성 요소

이 두 가지를 분리하는 것을 의미한다.

 

다루는 코드 영역의 차이

Command와 Query는 다루는 데이터의 영역의 크기가 다르다.

아래 그림은 Command와 Query가 다루는 데이터의 영역을 예시로 나타낸 것이다.

예약 취소라는 Command의 경우 Reservation, ReservationItem, Item 정도의 한 영역의 데이터만 다루지만,
예약내역 조회라는 Query의 경우 Reservation, ReservationItem, Item, Member 등 여러 영역의 데이터를 다루게 된다.

 

 

변경하는 시점의 차이

🤔 Command와 Query는 코드를 변경해야 하는 시점도 다르다.

만약, 1️⃣백오피스 개발팀에서 예약 내역 조회 기능을 수정해야 하고, 2️⃣예약 팀에서 예약 기능을 수정해야 한다고 했을 때,

Command와 Query 모델이 분리되어 있지 않다면 서로 다른 이유로 코드가 바뀌게 되고 책임의 크기가 적절하지 않다는 결론이 나오게 된다.

 

 

요구하는 성능의 차이

서비스에서 제공하는 Feature마다 요구하는 TPS나 성능이 다르다.

만약, 사용자가 예약 상품을 조회하는 메인페이지의 조회 속도가 느리다면 전체적인 서비스의 가치가 떨어지기 때문에 TPS가 높아야한다.

반면에, 백오피스팀에서 일일 예약 내역 수치 조회는 TPS가 조금 떨어지더라도 아무런 문제가 없을 것이다. 

 

 

CQRS의 범위

CQRS는 구현 방식이나 규모에 따라서, 명령 코드와 조회 코드를 따로 구현하는 것도 CQRS라고 말할 수 있다.

또한, DB 자체를 나누는 것도 CQRS라고 할 수 있다.

 

여러 케이스로 CQRS를 나누어보자.
Command와 Query가 동일한 프로세스인지? 그리고 동일한 DB를 사용하는지? 에 따라서 여러 케이스로 나뉘게 된다.

• 1️⃣ 동일한 프로세스이고, 동일한 DB를 사용하는 경우
  
  • 가장 단순하게 코드 수준에서 분리가 된다.
  • Command와 Query 데이터의 정합성을 보장한다.
• 2️⃣ 동일한 프로세스, 동일한 DB, 서로 다른 테이블을 사용하는 경우
  • 코드와 데이터 수준으로 분리된다. 
  • Query를 위한 전용 테이블을 사용한다.
  • Command 작업이 Query 전용 테이블을 함께 변경하게 된다.
  • ex) 예약 수 Top 10 숙박 업소 리스트
• 3️⃣ 동일한 프로세스, 다른 DB를 사용하는 경우
  • DB 자체가 분리된다.
  • Command 작업 이후 Query용 DB에 변경을 전파한다.
  • ex) Query용 Redis DB를 사용하고, Command 작업 이후 Cache 데이터 수정
• 4️⃣ 다른 프로세스, 다른 DB를 사용하는 경우
  • Command와 Query가 아예 다른 프로세스인 상태로, 3번 방식과 동일하게 변경 전파를 해야 한다.

 

 

DB 변경 전파 방법

Command 작업 이후 분리되어 있는 Query용 DB에 변경을 전파하는 방법은 여러 가지가 있다.🤔 

• 1️⃣ Command가 직접 Query용 DB 수정
  • 가장 단순.
• 2️⃣ Command 작업 이후 MQ를 이용하여 Query용 DB 수정
  • 데이터 유실 가능성이 있음.
• 3️⃣ Command 작업 이후 변경 내역을 별도 테이블에 기록하고 별도의 전파기를 통해 Query용 DB 수정
  • 변경 내역이 유실되지 않지만, 전파기를 구현해야 한다는 단점이 있다.
  • MQ를 함께 사용할 수 있다.
• 4️⃣ Command 작업 이후, DB가 제공하는 CDC를 이용하여 Query용 DB 수정
  • DB의 Binary Log를 읽어서 변경된 데이터를 확인하고, Query용 DB 수정
  • Command DB에서 변경 내역을 따로 저장하지 않아도 되어 명령 코드가 단순해진다.
  • MQ를 함께 사용할 수 있다.

 

+) 추가로

이렇게, 서로 다른 DB에 변경 전파를 해야 하는 경우 주의해야 할 점이 있다.

데이터 유실에 대해서 얼마나 허용할 것인지에 따라 DB 트랜잭션 범위가 달라질 것이며,
데이터 변경 전파의 허용 가능한 Delay 시간에 따라 구현 방법이 달라질 것이다.
또한, 변경된 데이터를 중복으로 전달하는 상황이 발생하더라도 Query용 DB 데이터가 이상해 지지 않도록 방어 코드를 구현해야 한다.

 

이 글에서는 CQRS에 대해서 간단하게 설명했고, DB를 분리한다는 것은 상당히 많은 Side Effect가 발생할 수 있음을 알아야 한다는 점을 언급하며 마무리한다.