CQRS

■ CQRS란?

CQRS는 Command Query Responsibility Segregation(명령과 조회의 책임 분리)의 약자로
이름처럼 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다.

■ CQRS의 시작?

CQRS는 초기 CQS에서 시작되어 확장되었습니다.
CQS는 Command Query Separation의 약자로 시스템에서 처리되는 명령과 조회,
이 두 작업을 정의하는 핵심 개념이자, 이 둘을 분리시키는 디자인 패턴입니다.

◐ CQRS에서 명령과 조회

• 명령 : 상태를 변경하는 작업 (Create, Update, Delete)
• 조회 : 상태를 반환하는 작업 (Read)

■ CQRS 패턴을 마이크로서비스에 적용

마이크로서비스의 핵심은 서비스별 데이터 저장소를
각기 다르게 채택한다는 점입니다.

■ 발생하는 문제점

• 성능 향상을 위한 스케일 아웃시 빈번한 명령과 조회 작업으로 리소스 교착 상태가 발생한다.
• 명령보다 조회요청이 훨씬 많이 사용되기에 조회 요청의 빈도가 증가함에 따라 스케일 아웃시 명령기능도 함께 확장해야 하기에 도메인의 복잡도가 높아진다.

■ 해결책

• CQRS 패턴 적용 :
  명령(Create, Update, Delete)과 조회(Read)로 나누어 처리

■ 여전한 문제?

• 단순히 모델을 나누는 형태로 명령과 조회를 분리한 것으로 하나의 데이터 저장소를
  사용한다는 면에서 완벽하게 마이크로서비스 설계 철학과 부합하는 것은 아니다.
  

■ 또 다른 해결책

• 아예 물리적으로 명령 작업과 조회 작업을 위한 저장소를 따로 준비한다.
• 이러한 방법으로 명령과 조회를 분리하면 명령(쓰기) 요청의 부하를 줄이고 조회 대기 시간을 줄이는 등의 다양한 이점이 있다.

■ 이벤트 소싱 패턴
CQRS 패턴은 이벤트 소싱 패턴과 함께 사용되기도 합니다.

■ 이벤트 소싱 패턴의 흐름
1. 이벤트 발생
2. 발생한 이벤트에 대해 수정 혹은 업데이트, 삭제 없이 입력만을 진행해 저장소에 이벤트를 저장해둔다. (쓰기)
3. 필요한 데이터가 생기는 시점에 축적된 에벤트를 조회(읽기)하는 형태

▶ 이벤트 주도 아키텍처?
메세지 브로커를 이용한 이벤트 주도의 아키텍처의 경우, 이벤트로 인해 상태가 변경된 경우, 이를 데이터 모델로 처리하고 최종값을 반영하는 형태

▶ 이벤트 소싱 패턴?
이벤트 소싱 패턴의 경우, 이를 데이터로 저장하는 것이 아니라
상태 변경 이벤트 자체를 저장하는 기법이다.

■ 이벤트 소싱 패턴의 장점?

• 메시지 브로커와 데이터 저장소 분리할 필요 X
• 이벤트를 데이터로 변경하는 복잡한 과정이 없어 쓰기 속도가 빠르다.
• 이벤트에 따른 CRUD를 전부 처리할 필요 없이, 이벤트 발생/조회만 처리하면 되어 서비스 확장이 용이하다.