[Architecture 공부] CQRS에 대해서 알아보자.

CQRS란?

 

Command and Query Responsibility Segregation(명령과 조회의 책임 분리)를 나타낸다.

 

• 말그대로 시스템에서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 핵심.
• 명령 : 시스템의 상태를 변경하는 작업.
• 조회 : 시스템의 상태를 반환하는 작업.
• 즉 명령과 조회로 작업의 책임을 분리하는 것.

 

CQRS가 필요한 이유.

• Application의 BIZ정책이나 제약(비즈니스 로직)은 대부분 데이터 변경 (C,U,D) 작업에서 처리되고, 데이터 조회(R)작업은 단순 데이터 조회가 대부분.
• 두 역할을 하나의 동일한 Domain Model로 처리하게 되면, 각 업무 영역에서의 새로운 요구사항으로 인한 Model 변경이 누적되면서 C,U,D를 위한 모델과 조회를 위한 모델간에 차이가 발생하게 됨.
• 즉. 각 업무 영역에 필요치 않은 Domain 속성들로 인해 복잡도는 한 없이 증가하고 Domain Model은 애초 설계 의도와는 다른 방향으로 변질.

 

 

CQRS적용방법(단계)

1단계 

[Simple한 CQRS적용 구조 - 이미지 출처 : http://auconsil.blogspot.com/2013/08/cqrs-command-query-responsibility.html]

• RDBMS는 분리하지 않고 기존 구조 그대로 유지
• Model Layer 부분만 Command와 Query Model로 분리.
• 하지만 동일 Database 사용에 따른 성능상 문제점은 개선하지 못함.

 

2단계

 

[Database까지 분리한 CQRS적용 구조 - 이미지 출처 : http://auconsil.blogspot.com/2013/08/cqrs-command-query-responsibility.html]

• Command용 Database와 Query용 Database를 분리하고 별도의 Broker를 통해서 이 둘 간의 Data를 동기화 처리 하는 방식.
• 데이터를 조회하려는 대상 서비스(시스템)들은 각자 자신의 시스템(서비스)에 맞는 저장소를 선택 할 수 있기에 폴리글랏 저장구조(다수의 Database 혼용하여 사용하는 것)로 구성가능. 따라서 각각의 model에 맞게 저장소를 튜닝하여 사용할 수 있음.
• 1단계의 데이터베이스 성능문제점 해결이 가능
• 하지만 동기화 처리를 위한 Broker의 가용성과 신뢰도 보장이 되어야하는 Risk존재.

 

3단계

[EventSourcing 모델 - 이미지 출처 : https://www.future-processing.pl/blog/cqrs-simple-architecture/]

• 이벤트 소싱 적용구조.
• 이벤트 소싱이란 Application내의 모든 Activity를 이벤트로 전환하여, 이벤트 스트림(Event Stream)을 별도의 Database에 저장하는 방식을 말함.
• 이벤트 스트림 저장 DB에는 오직 데이터 추가만 가능하고, 계속적으로 쌓인 데이터를 구체화(Materialized) 시키는 시점에서 그때 까지 구축된 데이터를 바탕으로 조회 대상 데이터를 작성.(Application 내의 상태 변경을 이력으로 관리하는 패턴이 발전된 형태로 보면됨.)
• 참고로 CQRS패턴에 이벤트 소싱은 선택이지만, 이벤트 소싱에 CQRS는 필수다.

 

 

참고[https://justhackem.wordpress.com/2016/09/17/what-is-cqrs/]

참고[https://www.popit.kr/cqrs-eventsourcing/]

참고[https://always-kimkim.tistory.com/entry/cqrs-pattern]