[마이크로서비스] 04. CQRS

# 학습 내용

1.  CQRS

CORS : Command Query Responsibility Segregation 

- 명령과 조회의 책임 분리

- 명령을 처리하는 책임 / 조회를 처리하는 책임을 분리

- 초기 CQS에서 시작되어 확장

 

CQS?

- Command Query Separation

- 시스템에서 처리되는 명령, 조회를 정의하는 핵심 개념이자 둘을 분리하는 디자인 패턴

 > 명령 : 상태를 변경하는 작업

 > 조회 : 상태를 반환하는 작업

 

만약에...

• 서비스 성능 향상을 위해 인스턴스를 스케일 아웃해 여러개로 실행할 경우? 빈번한 명령, 조회 작업으로 리소스 교착 상태 발생 가능성
• 통상적으로 명령보다 조회 요청이 훨씬 많으므로 하나의 서비스 내에 모든 기능이 있을 경우? 조회 요청 빈도가 증가함에 따라 명령 기능도 함께 확장해야하므로 도메인 복잡도 증가

 

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

- 마이크로서비스 핵심은 서비스별 데이터 저장소를 각기 다르게 채택하는 것

- 기존 하나의 데이터 저장소에 CRUD를 처리했다면

1. CQRS는 요청을 크게 명령(Create, Update, Delete)와 조회(Read)로 나누어 처리하거나
2. 물리적으로 명령 작업과 조회 작업을 위한 저장소를 별도로 분리

- 이처럼 명령과 조회를 각각 분리할 경우 명령(쓰기) 요청 부하를 줄이고, 조회 대기 시간을 줄이는 등의 이점 누리는 것 가능

 

CQRS 패턴과  이벤트 소싱 패턴을 함께 사용

이벤트 주도 아키텍처

- 메시지 브로커를 이용

- 이벤트로 인해 상태가 변경되면 이를 데이터 모델로 처리하고 최종값을 반영하는 형태

이벤트 소싱 패턴

- 최종값을 데이터로 저장하는 것이 아닌 상태 변경 이벤트 자체를 저장하는 기법

- 이렇게 처리할 경우 메시지 브로커와 데이터 저장소를 분리하지 않아도 됨

- 데이터로 변경하는 복잡한 과정 없이 쓰기 속도도 빠름

- 이벤트에 따른 CRUD를 전부 처리할 필요 없이 이벤트 발생/조회만 처리하면 되므로 서비스 확장이 좀 더 용이

- 즉 이벤트는 한 번 발생 후 수정되지 않고 업데이트/삭제 없이 입력만되는 개념

- 저장소에 이러한 에빈트를 저장(쓰기)해두고 필요한 데이터가 생기는 시점에 축적된 이벤트를 조회(읽기)하기만 하면 되는 형태

- CQRS와 같은 맥락의 패턴을 지님

∴ 이벤트 소싱 + CQRS 조합은 함께 사용하기 좋은 패턴

 

---

# References

https://learn.microsoft.com/ko-kr/azure/architecture/patterns/cqrs

CQRS 패턴 - Azure Architecture Center