[0508] 마이크로서비스 - CQRS

• Command Query Responsibility Segregation, 명령과 조회의 책임 분리
• 초기 CQS(Command Query Separation)에서 시작되어 확장됨
• 시스템에서 처리되는 명령과 조회, 이 두 작업을 정의하는 핵심 개념이자, 이 둘을 분리시키는 디자인 패턴
• 명령: 상태를 변경하는 작업
• 조회: 상태를 반환하는 작업
• 마이크로서비스의 핵심은 서비스별 데이터 저장소를 각기 다르게 채택한다는 점
• 서비스 성능 향상을 위해 인스턴스를 스케일 아웃하여 여러 개로 실행할 경우 빈번한 명령과 조회 작업으로 리소스 교착 상태가 발생할 수 있음
• 통상적으로 명령보다 조회 요청이 훨씬 많이 사용되기 때문에, 하나의 서비스 내에 이러한 모든 기능을 넣어두면 조회 요청 빈도가 증가함에 따라 명령 기능도 함께 확장해야 하기 때문에 도메인의 복잡도가 높아짐
• 이러한 문제를 해결하기 위한 방법 중 하나로 CQS 패턴을 사용함
• 기존에 하나의 데이터 저장소에서 CRUD 작업을 모두 처리했다면, CQRS는 요청을 크게 명령(Create, Update, Delete)과 조회(Read)로 나누어 처리함
• 단순히 모델을 나누는 형태로 명령과 조회 분리
• 하나의 데이터 저장소를 사용한다는 면에서 완벽하게 마이크로서비스 설계 철학과 부합하는 것은 아님

• 물리적으로 명령 작업과 조회 작업을 위한 저장소를 따로 준비할 수 있음
• 명령과 조회를 각각 분리하면 명령(쓰기) 요청의 부하를 줄이고, 조회 대기 시간을 줄이는 등 다양한 이점을 누릴 수 있음

• 이벤트 소싱 패턴과 함께 사용되기도 함
• 메시지 브로커를 이용한 이벤트 주도의 아키텍처의 경우, 이벤트로 인해 상태가 변경됐을 때 이를 데이터 모델로 처리하고 최종값을 반영하는 형태를 의미함
• 이벤트 소싱 패턴의 경우, 이를 데이터로 저장하는 것이 아니라 상태 변경 이벤트 자체를 저장하는 기법을 의미함
• 메시지 브로커와 데이터 저장소를 분리하지 않아도 되며, 데이터로 변경하는 복잡한 과정이 없어 쓰기 속도도 빠르고 이벤트에 따른 CRUD를 전부 처리할 필요 없이, 이벤트 발생/조회만 처리하면 되어 서비스 확장을 좀 더 용이하게 할 수 있음
• 이벤트는 한 번 발생한 후에 수정되지 않고 업데이트나 삭제 없이 입력만 되는 개념이기 때문에 저장소에 이러한 이벤트를 저장(쓰기)해두고, 필요한 데이터가 생기는 시점에 축적도니 이벤트를 조회(읽기)하기만 하면 되는 형태로, CQRS와 같은 맥락의 패턴을 가짐