CQRS 아는 척하기 - 최범균

https://www.youtube.com/watch?v=xf0kXMTFJm8 

 

최범균님의 CQRS 아는 척하기 1~2편을 요약한 글입니다.

 

 

CQRS란?

Command Query Responsibility Segregation 번역하면 명령과 쿼리 책임 분리입니다.

 

명령은 Create, Update, Delete를 뜻하며 시스템 데이터 변경을 합니다.

쿼리는 Select를 뜻하며 시스템 데이터 조회를 합니다.

 

명령 역할을 수행하는 구성 요소와 쿼리 역할을 수행하는 구성요소를 나누는 것이 CQRS입니다.

 

이렇게 명령과 쿼리를 나누면 어떤 장점이 있을까요?

명령과 조회에 단일 모델을 사용하면 요구사항에 따라 점점 Entity의 덩치가 커지게 됩니다.

이에 따라 책임과 역할이 애매해집니다.

 

• Read와 Create, Update, Delete 각각에 더 최적화된 DB 구성을 통해 성능을 더 향상할 수 있습니다.
• Read와 CUD에서 필요한 데이터 형식이 다를 수 있고, 특히 Read에는 집계 함수 등의 부가적인 값들이 Entity에 필요하게 될 수 있습니다. (Read로 인해 Entity구조가 변경되는 것을 막을 수 있음) → 모델이 덜 복잡해진다
• read와 write 각각에 대한 독립적인 스케일링
• 보완 관리 용이

 

구현 : 같은 프로세스, 같은 DB

- 가장 단순

- 명령/쿼리 동일 데이터 보장

 

구현: 같은 프로세스, 같은 DB, 다른 테이블

- 쿼리 전용 테이블 사용

- 명령(Command)시 쿼리 전용 데이터 변경이 발생

 

구현: 같은 프로세스, 다른 DB

-명령은 MySQL, 쿼리는 Redis를 사용하는 느낌

- DB간 변경내용을 전파하는 방법이 필요

 

구현: 다른 프로세스, 다른 DB

- 명령이 데이터를 변경하면 변경 내용을 쿼리에 전파해야 합니다.

- MSA 구현 시 이 방식으로 구현하게 됩니다.

 

다른 DB로 변경 내용 전파 방식

 

카프카와 같은 메시징 수단을 사용하거나, 사용하지 않고 Command DB, QueryDB에 전파

메시징이나 Query DB에 문제가 생기면 데이터가 유실될 수 있습니다.

또는 명령을 수행하는 기능이 Query DB, 메시징 때문에 에러가 발생하여 동작하지 않을 수 있습니다.

변경 내용을 기록하고 별도의 전파 기를 사용하여 Query DB에 전달합니다.

변경 내역을 별도 테이블에 기록합니다.

이 과정은 한 트랜잭션으로 일어나서 변경내역이 유실되지 않습니다.

중간에 메시징을 두는 활용을 할 수 있습니다.

 

DB가 제공하는 CDC를 사용하는 방식입니다.

2번째 방법과 유사하지만 명령 코드 쪽에서 명령 내역을 따로 저장하기 않아도 됩니다.

따라서 코드가 단순해지는 장점이 있습니다.

 

 

주의 사항

- 데이터 유실

- 명령의 변경내역이 얼마나 빠르게 쿼리에 전파되어야 하는가

- 네트워크 장애 등으로 재 전달하더라도 쿼리 쪽 데이터가 중복 전달을 받지 않도록 해야 함