MicroService Architecture ‐ CQRS Patterns

MicroService Architecture - CQRS Patterns

CQRS(Command Query Responsibility Segregation) 패턴

• DB를 읽기 및 쓰기 작업으로 분리하는데 이렇게 하는 이유는 비효율적인 조인이나 복잡한 쿼리를 피하기 위해서이다.
  • Command : 데이터 상태를 애플리케이션에 반영 및 변경
  • Query : 복잡한 조인 작업 처리, 결과 반환 용도. 데이터 상태를 애플리케이션에서 변경하지 않는다.

CQRS Level 1 정리

• 분리 수준 : Controller 및 Service만 분리
• 장점 : 간단한 구조, 구현 난이도 낮음
• 단점 : 성능상 큰 장점은 없음, 확장성 제한적

CQRS Level 2 정리

• 분리 수준 : Controller, Service, DB 스키마 분리
• 장점 : 읽기 모델을 조회 최적화하여 성능 향상 가능
• 단점 : 구현 및 관리 복잡성 증가

CQRS Level 3 정리

• 분리 수준 : Controller, Service, DB 스키마, 물리적 DB 분리
• 장점 : 읽기/쓰기 성능 및 확장성 극대화
• 단점 : 복잡성, 비용, 관리 난이도 증가

CQRS(Command Query Responsibility Segregation) - Read and Write Operations

• DB 읽기 및 쓰기에 서로 다른 접근 방식으로 서로 다른 전략을 정의한다.
• 이렇게 하는 이유는 읽기 및 쓰기 작업이 성능과 확장성 요구 사항이 다르기 때문이다.

Event Sourcing

• 데이터 변경 이력(상태 변화)을 DB(Event Store)에 저장한다.
• 상태를 직접 저장하지 않고, 발생한 이벤트들을 저장한다.
• 저장된 이벤트를 재생해서 상태를 복원한다.
• 최신 데이터 상태만 DB에 저장하는 것이 아니라 모든 이벤트를 순차적으로 DB에 저장한다.
• Event Store : 이벤트 데이터베이스 역할로 이벤트 저장소가 된다.
• Write DB에는 이벤트를 저장하고 Read DB에서는 Write DB에서 발행한 이벤트를 소비하는 구조가 된다.
• 시스템은 쿼리 성능을 높이고 DB에 대한 독립적 확장이 가능하다.

장점

• 독립적인 확장성, 분리된 읽기 및 쓰기 기능
  
• 쿼리 성능 향상
  
• Read DB의 비정규화된 데이터로 복잡하고 오래 실행되는 조인 쿼리를 최소화할 수 있다.
  
• 유지 관리 및 유연성 향상
  
• Kubernetes 배포에 적합한 분산 수평 확장 DB 적용
  

단점

• 구현 복잡성이 증가 - CQRS 자체가 시스템을 더 복잡하게 설계하게 된다는 것을 인지해야 한다.
  
• Eventual Consistency 문제가 있다.
  
• Distributed Transaction Management 문제가 있다.