CQRS란

CQRS는 Command Query Responsibility Segregation 의 약자이다!
명령 조회 책임 분리 패턴이라는 의미 그대로 받아들이면 제일 좋을 것 같다!!
잠깐, 여기서 Command(명령)은 데이터의 변화를 주는 입력, 수정, 삭제 관련 작업들이라 볼 수 있고 Query는 조회와 관련된 작업이라 보면 된다! 즉 시스템 상태를 변경하냐 마냐의 유무라고 생각하면 될 것 같넹

CQRS 등장배경과 개념

자 그럼 어쩌다가 이러한 개념이 등장하게 되었는지 그 부분을 생각해보자! 왜 그럴까..??

기존 아키텍쳐를 한번 생각해보자. 간단한 경우 데이터베이스를 쿼리하고 업데이트하는 데에는 동일한 데이터모델을 사용해! but 어플리케이션이 복잡해져도 그렇게 간단하게 할 수 있을까…??

예를들어 호텔예약정보를 사용자에게 반환해야하는 데 데이터베이스는 사용자, 방 정보, 그 외.. 들의 테이블이 존재하고 있을텐데 그럼 각각의 테이블에서 정보들을 가져와 새로운 DTO를 만드는 작업이 수반되어야 하지.

뿐만아니라 각각의 데이터 별로 체크해야하는 부분들이 존재할텐데 그러한 부분들을 추가하다보면 너무 복잡하고 무거운 형태로 가버린다 이거지!

→ 그래서 생각한 것이 Command 와 Query를 분리하자! 라는 것인거야!!

CQRS와 MSA

이러한 아키텍쳐는 MSA 구조와 잘 어우러지게 되는데 이제 그 이야기를 시작해보자!

MSA의 장점 중을 꼽으라면 여러가지가 존재하겠지만 각 서비스들이 물리적으로 분리되어있기 때문에 장애복구와 더불어 서비스간 환경에 서로 구애받지 않는다는 것이라고 생각한닷.

그렇다면 입력, 수정, 삭제와 조회를 분리하였을 때 입력, 수정, 삭제는 RDB 즉 관계형 데이터베이스를 사용하더라도 조회의 경우에는 NO-SQL을 사용하는 것이 가능하게 된다는 말이지!! 조금 더 쉽게 말해 아래의 그림을 먼저 참고하고 오자!

위 그림을 보면 크게 Command와 Query가 분리뒤어 있고 각각의 API가 존재하고 있다. 아마 처음 시스템에 변경을 가하는 작업과 조회하는 작업을 분리한다는 말을 들었을 때 이러한 의문이 든 사람이 있을 것이다!

그렇게 구조를 분리할 경우 데이터의 일관성이 깨질 수 있지 않는가…?? 잘못된 데이터를 조회할 위험이 있어보이는데… 라는 의문 말이다!!

이러한 부분들을 해결하기 위해 사용한 방안이 바로 Message Queue를 도입한 해결방안이다!

CQRS와 MQ

pub/sub 구조로 Command용 서비스와 Query용 서비스를 연결시켜주며 Event Driven Architecture 형태로 해결할 수 있다.

Command에서 데이터를 쓰면서 발생한 내역이 담긴 이벤트를 MQ에 pub 즉 발행하면 이를 sub(구독)하고 있는 Query 쪽에서 해당 이벤트를 보고 그에 맞게 최신상태로 동기화하게 하는거지!!

결과적으로 초기에 겪었던 문제들을 해결함과 동시에 데이터의 일관성도 유지하는 구조를 만들었다고 볼 수 있는거야!!

참조 https://engineering-skcc.github.io/microservice outer achitecture/inner-architecture-cqrs/

참조 https://docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs