CQRS 의 구현 수준
CQRS 를 구현할 때, 무작정 저장소를 분리한다고 해서 좋은 것이 아닙니다. 현재 상황에 맞게 적절한 수준의 CQRS 를 적용해야 시스템적 복잡성을 최소화 하면서도 성능적 이득은 가장 크게 얻는, 가성비 좋은 CQRS 구현이 가능합니다.
CQRS 의 구현 수준
| 단계 | 이름 | 설명 |
|---|---|---|
| 레벨 1 | 코드 수준 분리 (CQS) | - 동일 데이터 저장소 사용, 서비스/메서드만 분리 |
| 레벨 2 | 모델 수준 분리 | - 동일 데이터 저장소 사용, 테이블이나 스키마를 분리 |
| 레벨 3 | 저장소 수준 분리 (CQRS) | - 데이터 저장소를 분리 |
레벨1 코드 수준 분리(CQS)
- 분리 수준 : Command 와 Query 코드만 분리하는 수준의 책임 분리, 동일 저장소 사용
- 예시 : Command 와 Query 서비스 혹은 메서드 분리
- 장점 : 변경 사항이 적음, 복잡성 증가 정도가 낮음
- 단점 : 성능 개선 효과 미미
레벨2 모델 수준 분리
- 분리 수준 : 동일한 저장소 사용, 테이블이나 스키마를 분리
- 예시 : Command 용 정규화된 테이블, Query 용 반정규화된 테이블을 분리해 운용
- 장점 : Command - 인덱싱 최소화, Query - 조인 최소화로 성능 향상
- 단점 : 동일 DB 내 리소스 경함, 트랜잭션 락
- 중간 정도의 복잡성 증가를 보임
레벨3 저장소 수준 분리(CQRS)
- 분리 수준 : Command 용 저장소와 Query 용 저장소로 저장소를 분리
- 예시 : Command - RDBMS 사용 / Query - 검색엔진 사용
- 장점 : Command 와 Query 각각에 최적화된 저장소 기술 채택, 확장성 좋음
- 단점 : 시스템 복잡성 증가, 데이터 동기화 구현 필요
데이터 동기화 방식
동기식/비동기식 업데이트
| 구분 | 동기식 업데이트 | 비동기식 업데이트 |
|---|---|---|
| 방법 | Command 처리시 Query용 데이터 모델에도 변경사항을 즉시 반영 | Command 처리 후 Query용 데이터 모델에 비동기식 업데이트 |
| 장점 | - 일관성 보장이 용이함 - 구현 단순 |
- 확장성이 좋음 - 필요할 때 업데이트 하므로 성능적 이득 - 느슨한 결합 |
| 단점 | - 실시간 동기화로 인한 성능 감소 - Command 와 Query 데이터 모델 간 결합도 증가 |
- 최종적인 일관성을 보장하기에 복잡 - 동기화 지연시간이 발생함 |
데이터 동기화 기술 선택
| 동기화 기술 | 설명 |
|---|---|
| 데이터베이스 트리거 | - DB 내부 트리거로 변경사항 발생시 자동으로 Query 저장소에 반영 - 구현이 간단함 - 유지보수와 확장성에 한계가 있음 |
| 어플리케이션 레벨 동기화 | - 애플리케이션 레벨에서 직접 Query 저장소 업데이트 - 로직 통제가 쉬웁 - 코드 복잡도가 다소 높아질 수 있음 |
| 메시지 큐/이벤트 스트림 | - 이벤트 발행-구독 기반 비동기 동기화 - Kafka, RabbitMQ 등을 사용 - 확장성이 높음 - 결함에 대한 내성이 강함 |
| CDC Change Data Capture |
- DB 로그를 모니터링해 데이터 변경을 감지하고 Query 저장소에 반영 - 구현이 단순함 - 실시간성이 부족, 데이터 지연 발생 가능 |
| 배치 프로세스 | - 주기적으로 데이터를 동기화하는 접근 방법 |
일관성 보장의 강도
CQRS 에서 말하는 일관성이란?
- 원본 데이터와 복제본 간의 일치도를 뜻함
- 다른 말로 복제 일관성이라고 할 수 있음
- Command 저장소(모델)와 Query 저장소(모델)간 동일한 상태를 유지하는 강도와 실시간성
- 즉, Command 발생시 그 결과가 Query 모델에 얼마나 빠르고 정확하게 반영되는가
복제 일관성 전략
| 일관성 강도 | 설명 |
|---|---|
| 강한 일관성 | - Command 작업 완료 즉시 Query 모델에도 반영 - 항상 최신 데이터를 제공 - 장점 : 일관성 보장이 용이 - 단점 : 성능 저하, 결합도 증가 - 적용 포인트 : 정확도가 중요한 비즈니스 로직, 재고가 한정된 경우 |
| 인과적 일관성 | - 사용자의 직접적인 Command 작업에 대한 결과는 Query에 바로 반영 - 그 외의 데이터 변경은 시간차를 두고 Query 에 반영 - 장점 : 사용자 경험 향상, 성능 저하 최소화 - 단점 : 시스템 복잡도 증가, 사용자 간 데이터 불일치 가능 - 적용 포인트 : SNS 에서 내가 쓴 글 바로 보기 |
| 최종 일관성 | - Command 작업 후 일정 시간 내 Query 모델에 반영 - 일시적으로는 불일치가 있을 수 있음 - 장점 : 확장성 우수, 시스템 간 결합도 낮음 - 단점 : 데이터 지연 발생, 복잡한 설계 - 적용 포인트 : 상품 목록 조회, 대시보드 등 일반적인 조회 기능 |
| 맞춤형 일관성 | - 사용자별/기능별 차별화된 일관성 정책 적용 - 적용 포인트 : SNS 에서 일반인, 인플루언서 간 다른 일관성 정책 |
최종 일관성으로 갈 수록 성능 이득이 크고,
강한 일관성으로 갈 수록 실시간성 이득이 크다.
실제 사례
호텔 예약 시스템
- Command : 객실 예약 시 트랜잭션으로 정확한 재고 관리
- Query : 검색 결과에는 최종 일관성을 적용해 성능 이득, 일부 불일치 허용
- 검색 후 최종 예약 단계에서 재고 확인해 불일치 방지 : 강한 일관성
- 예약 완료 후 내 예약 내역 바로 확인 가능 : 인과적 일관성
소셜 네트워크 서비스
- Command : 게시물 생성, 댓글, 좋아요 등 액션은 트랜잭션으로 정확하게 처리
- Query : 타임라인, 친구 활동, 트렌드 토픽은 최종 일관성으로 확장성 확보
- 타인 활동은 몇 초간 지연 동기화 허용 : 최종 일관성
- 자신의 액션은 바로 피드에 반영 : 인과적 일관성
Reference
Wanted 커리어 프리온보딩 - 2-4년차 백엔드를 위한 CQRS 패턴과 실시간 데이터 처리
Comments