[C#] CQRS 란?

참조

CQRS는 Command Query Responsibility Segregation 의 약자로 단어 그대로 해석하면 "명령 조회 책임 분리" 입니다.
이는 애플리케이션들을 구성하는 아키텍처에 대한 하나의 패턴입니다.
즉, 애플리케이션을 구현함에 있어 명령과 조회에 대한 책임을 분리하는 것이 CQRS 입니다.
그렇다면 명령과 조회는 어떤것을 의미하며, 이 둘의 책임을 왜 분리됐어햐 했는지 알아 보고, 나아가 어떻게 분리하여 CQRS 패턴을 구현하는지 알아 봅니다.

전통적인 CRUD 아키텍처 기반에서 애플리케이션을 개발 및 운영하다 보면 자연스럽게 Domain Model의 복잡도가 증가되기 마련이고 이로 인해 유지보수 Cost 는 지속적으로 증가하게 되며 Domain Model은 점점 설계 시 의도한 방햫과는 다르게 변질 되게 됩니다.
특히나 요즘처럼 고차원적인 UX, 급변하는 Business, 시도떄도 없이 달라지는 요구사항을 충족하는 Model을 만드는건 더욱더 어려운일이 되어 버렸습니다.
이런 일련의 변경사항과 흐름을 곰곰히 보면, 애플리케이션의 Business 정책이나 제약은 거의 대부분 데이터 변경(C,U,D) 작업에서 처리되고 데이터 조회(R) 작업은 단순 데이터 조회가 대부분인데 이 두 업무를 동일한 Domain Model로 처리하게 되면 각 업무 영역에 필요치 않은 Domain 속성들로 인해 복잡도는 한 없이 증가하고 Domain Model은 애초 설계 의도와는 다른 방향으로 변질됩니다.
때문에, 위 사항을 개선하기 위하여 명령을 처리하는 책임과 조회를 처리하는 책임 을 분리 구현 하면 된다고 생각을 하였고 이때 나온 개념이 CQRS 입니다.

위 그림처럼 Database(RDBMS) 는 분리하지 않고 기존 구조 그대로 유지 시키고 Model Layer 부분만 Command와 Query Model로 분리하는 수준으로 간단하게 적용할 수 있습니다.
이렇게 분리된 Model은 각자의 Domain Layer 에 대해서 만 모델링하고 코딩하기 떄문에 훨씬 단순하게 구현/적용 할 수 있습니다.
하지만, 동일 Database 사용에 따른 성능상 문제점은 개선하지 못하는 단점이 있습니다.

프리미엄의 형태는 Command 용 Database 와 Query 용 Database 를 분리하고 별도의 Broker 를 통해서 이 둘 간의 Data를 동기화 처리하는 방식입니다.
이 경우는 데이터를 조회 하려는 대상 서비스들은 각자 자신의 시스템에 맞는 저장소를 선택 할 수 있기에 폴리글랏 저장 구조로 구성할 수도 있습니다.
이 경우 각각의 Model 에 맞게 저장소(RDBMS, NoSql, Cache) 를 튜닝하여 사용할 수 있다는 이점이 있고, Database 사용에 따른 성능 관점의 문제점을 해결할 수도 있습니다.
하지만 동기화 처리를 위한 Broker 의 가용성과 신뢰도가 보장되어야 하는 위험이 존재합니다.

폴리글랏 저장 구조? 다수의 Database 혼용하여 사용 하는 것을 폴리글랏 저장소라고 합니다.

디럭스 형태는 이벤트 소싱(EventSourcing) 을 적용한 구조입니다.
이벤트 소싱이란 애플리케이션 내의 모든 Activity 를 이벤트로 전환해서 이벤트 스트림(Event Stream) 을 별도의 Database 에 저장하는 방식을 말합니다.
이벤트 스트림을 저장하는 Database 에는 오직 데이터 추가만 가능하고 계속적으로 쌓인 데이터를 구체화 시키는 시점에서 그때까지 구축된 데이터를 바탕으로 조회대상 데이터를 작성하는 방법을 말합니다.
이벤트 소싱의 이벤트 스트림은 오직 추가만 가능하고 이를 필요로 하는 시점에서 구체화 단계를 거치게 되고 이런 처리 구조가 CQRS의 Model 분리 관점과 굉장히 궁합이 잘 맞기에 대부분 CQRS 패턴을 적용하고자 할 때 이벤트 소싱이 적용된 구조를 선택하게 됩니다.

주의 할 점은, CQRS 패턴에서 이벤트 소싱은 필수가 아니지만 이벤트 소싱에서 CQRS 는 필수 입니다.

728x90