CQRS 패턴

CQRS는 Command and Query Responsibility Segregation의 약자로 명령의 해당하는 영역과 조회에 해당하는 영역을 분리하는 것이다. 명령과 조회의 영역을 분리하게 되면 성능, 확장성 및 보안이 최적화될 수 있고 유연성이 생기므로 시스템이 진화하고 업데이트 수행하는 데에 도메인 레벨에서 충돌과 악영향을 일으키지 않도록 할 수 있는 방향성을 두고 있다.

명령과 조회의 영역이 하나인 구조

분리되지 않는 단순한 아키텍처를 살펴보면 데이터베이스를 Read와 Write 하는 데 동일한 모델을 사용하게 된다. 복잡성이 없는 간단한 모델 및 구조의 CRUD라면 최적화된 구조일 수도 있다. 하지만 서비스 비즈니스가 커짐으로 인해 시스템 애플리케이션이 구조가 더 복잡해졌고 많은 트래픽을 감당해야 한다면 운영하기가 어려워질 수 있다. Entity와 Business Dto 간의 객체 매핑이 복잡해질 수 있고 모델 Write에서 복잡한 유효성 검사 및 비즈니스 논리 코드들을 구현할 수 있다. 너무 많은 작업을 수행하기에 과도한 모델이 될 수 있다.

위의 그림은 앞서 설명했던 명령과 조회의 책임을 하나의 도메인과 DB로 되어 있는 구조이며 예를 들어 상품에 대한 리뷰 정보 명령과 상품 리뷰의 조회 발생하는 그림이다.

사용자는 상품에 대한 별점, 내용 등의 정보들이 Create, Update, Delete 명령이 일어나고 다른 사용자는 언제든지 상품 리뷰를 확인할 수 있는 구조이다.

어떤 문제가 발생될까?

• 프런트에 리뷰 노출에 대한 조회의 요구사항이 커질수록 도메인의 영향이 발생된다. 즉, 데이터에 대한 복잡성이 높아진다. 
• 관계형 데이터베이스는 명령에 대해 데이터 일관성(Consistency)을 유지하는 것이 중요하다. 일관성을 지키기 위해 DB는 Locking을 하게 되고 조회 연산이 대기를 하며 전반적으로 성능에 영향을 미칠 수 있다.

이 외에 복잡도에 의한 유지보수성이 떨어지고 확장성이 낮아지는 이슈들이 있기도 하다.

명령과 조회의 영역이 분리된 구조

cqrs

인벤트 소싱 패턴으로 명령 애플리케이션으로부터 수행 완료된 데이터를 이벤트 스토어를 통해 퍼플리싱 하고 조회 애플리케이션은 데이터를 Consume 하여 조회 모델을 생성, 저장을 수행한다.

이로써 도메인은 도메인 로직에만 집중할 수 있는 환경이 되었으며 조회에서는 복잡한 조인 쿼리 없이 단순한 쿼리로 원하는 정보를 얻음으로써 성능에 대한 이점이 좋아진다. 또한 명령과 조회의 비율에 따라 Database 인스턴스의 비율도 유연하게 가져갈 수 있다.

명령과 조회 DB가 분리되었다는 건 서로 다른 저장소를 이용할 수 있다. 그러므로 조회 DB는 관계형 데이터베이스가 아니더라도 조회 성능에 최적화된 다른 종류의 데이터베이스를 사용할 수 있다. Redis, ElasticSearch, MongoDB 등을 사용하여 조회 성능을 올리는 것을 고려해봐야 한다.

물론 두 데이터베이스 저장소가 다르기에 데이터 일관성을 보장할 수 있어야 하고 관리의 요소가 늘어난 상태이기 때문에 시스템이 안정화될 때까지는 모니터링에 투자를 많이 해야 하는 단점이 있다.

 

CQRS를 적용을 고려해야 하는 시점은?

• 프런트 조회의 요구사항이 복잡해질 때
• 조회 성능을 높이고 싶을 때
• 도메인 데이터를 관리하는 영역과 프런트로 전달하는 영역의 책임이 나눠져야 할 때
• 시스템 확장성을 높이고 싶을 때