CQRS 패턴

CQRS 패턴이란?

Command Query Responsibility Segregation의 약자로 ‘명령 조회 책임 분리’라고 합니다.
즉 명령과 조회를 분리하는 패턴인데요! 이 둘을 왜 분리를 해야 하는지 분리를 했을 때 이점은 무엇인지 알아보겠습니다.

명령과 조회를 분리한 이유

마틴 파울러는 명령과 조회를 분리한 이유가 비즈니스의 복잡도가 증가하여 이를 줄이고자 나온 개념이라고 합니다.

개발을 하다보면 많은 도메인 로직들이 생겨나고 복잡도가 증가하게 됩니다.(C, U, D) 또한 이에 따른 다양한 Read 방식도 제공해야 합니다. (R)

따라서 서로 다른 책임을 가지고 있으므로, 이를 분리하여 처리를 하면 성능 상 이점을 가져갈 수 있습니다.

분리를 할 경우 이점

명령 부분과 조회 부분을 분리하면 성능 상의 이점을 가져온다 라고 표현을 하였는데요!

어떻게 동작하길래 성능이 좋아진다 라는 걸까요?🤔

크게 2가지 관점에서 생각해 볼 수 있을 것 같습니다!

1. Domain로직을 분리함으로써 복잡도를 줄일 수 있고, 이에 따른 유지보수성도 당연히 증가할 것이라 생각됩니다.
2. DB와의 통신인데요! 요청을 분리하게된다면 DB와의 통신으로 병목현상 등을 없앨 수 있을것이라 판단됩니다.

DB도 Replication을 하여 Master, Slave로 나눈 뒤 Master에는 Write만 Slave에는 Read만 가능하도록 구성할 수 있습니다. 이처럼 부하를 분산시켜 하나의 서버에서 발생할 수 있는 병목 현상 문제를 해결 할 수 있습니다.

다만 이렇게 한 곳에서 데이터를 집중해서 관리하는 것이 아니라 분산해서 관리를 하게되면 반드시 이슈가 되는 문제가 남아있습니다. 바로 동기화 문제입니다.

이러한 동기화 문제를 해결하기 위해 마틴 파울러는 다양한 아키텍쳐 패턴들이 있다고 합니다.

CQRS with separated persistance mechanisms

쓰기용 DB와 읽기용 DB를 분리하여 처리를 하는 방식을 말합니다.

이 두 DB간의 데이터 동기화는 별도의 Broker를 두어 쓰기용 DB의 변경 데이터를 읽기용 DB로 전달하게 됩니다.

Event Sourcing

이벤트 소싱 개념의 첫 시작은 .NET 이라는 것을 알고 계셨나요?

일반적으로 DB에 우리는 최종 결과물을 저장하게 됩니다. 따라서 변경된 상태 등의 히스토리를 알기 힘듭니다. 이러한 문제를 해결하기 위해서 Event Sourcing은 변경상태를 오직 적재만 하는 역할을 하는 개념입니다.

데이터를 적재만 한다니.. 벌써부터 조회 시 부하가 걱정되지 않나요? 그런데 여기다가 쓰기용인 Command 처리까지 한다면? 서버의 가용성이 크게 떨어질 것입니다.

따라서 Event Sourcing에서는 CQRS 패턴을 필히 고려해야 한다고 합니다.

이처럼 데이터를 동기화 하는 방식에는 다양한 방안들이 존재합니다. 이 방안들을 여기서 논하기에는 너무 크고 방대한 내용이 될 것 같아 CQRS에 대한 내용은 여기서 마무리 하려고 합니다.

강의를 듣거나 학습을 하다보면 가끔 CQRS에 대한 용어를 접하게 되는데요!

이번 기회에 내용을 정리했으니 이후 반갑게 맞이할 수 있을꺼라 생각하니 기분이 좋네요!😁

다음엔 기회가 된다면 데이터 동기화를 위한 다양한 방안들에 대해 심도 있게 논의해 볼 수 있는 자리를 가져보도록 하겠습니다. 감사합니다~!

Reference

우아한 형제들에서 적용한 CQRS : https://www.youtube.com/watch?v=BnS6343GTkY
MS CQRS 개념정의 : https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
Spring Camp(Event Sourcing): https://www.youtube.com/watch?v=TDhknOIYvw4