Read Write 분리 CQRS

3줄 요약

  • Read Write 분리는 쓰기 모델을 안전하게 유지하면서 읽기 모델을 조회 형태에 맞게 최적화하는 선택이다.
  • CQRS는 단순히 DB를 둘로 나누는 이름이 아니라 command의 불변식과 query의 조회 비용을 서로 다른 모델로 다루는 설계다.
  • 성능은 좋아질 수 있지만 projection lag, rebuild, schema version, 장애 재처리 때문에 정합성과 운영 복잡도가 반드시 증가한다.

핵심 정리

  • 쓰기 모델은 주문 생성, 결제 승인, 재고 차감처럼 불변식과 트랜잭션 경계를 지킨다.
  • 읽기 모델은 주문 목록, 관리자 통계, 피드, 검색 결과처럼 화면과 API 응답 형태에 맞춘다.
  • Read replica는 읽기 부하를 분산하지만 원본 스키마와 조회 모델은 거의 그대로다.
  • Projection read model은 이벤트나 outbox를 읽어 조회 전용 테이블, 문서, 검색 인덱스를 만든다.
  • CQRS는 command와 query의 모델, 코드 경계, 저장소, 배포 책임을 어디까지 분리할지 정하는 방식이다.
  • 핵심 지표는 write latency, read latency, projection lag, stale read ratio, rebuild time, replay failure count다.
  • 이 선택은 성능을 개선할 수 있지만 read-after-write 정합성을 약화시키고, 장애 복구와 배포 절차를 복잡하게 만든다.

판단 순서

  • 먼저 쓰기 DB가 느려지는 원인이 읽기 쿼리인지, 인덱스 부족인지, batch인지, hot row인지 확인한다.
  • 단일 모델, 인덱스, 캐시, read replica, materialized view, projection, CQRS 순서로 복잡도를 올린다.
  • 사용자에게 stale data가 보여도 되는 화면과 절대 최신이어야 하는 화면을 분리한다.
  • read model이 깨졌을 때 원천 데이터나 이벤트로 재생성할 수 있는지 확인한다.
  • projection lag가 SLO를 넘을 때 API, 화면, 알림, 운영자가 각각 무엇을 보게 할지 정한다.

상세본 구성

  • 01. Read Write 분리 목적 상세.md는 쓰기 DB 보호와 읽기 최적화를 왜 분리해야 하는지 판단한다.
  • 02. CQRS 기본과 적용 기준 상세.md는 command/query 모델을 나누는 기준과 과한 도입 신호를 다룬다.
  • 03. Projection Read Model 상세.md는 이벤트 기반 read model의 멱등 갱신, 순서, rebuild를 다룬다.
  • 04. 동기화 지연과 일관성 상세.md는 read-after-write, stale UX, lag 알림 계약을 다룬다.
  • 05. 복잡도를 감당할 수 있는 기준 상세.md는 팀, 운영, 배포, 재처리 준비가 되었는지 점검한다.

헷갈리는 지점

  • Read replica와 CQRS를 같은 것으로 보기 쉽다. 둘 다 읽기 부하를 줄일 수 있기 때문이다.
    • Read replica는 같은 모델을 복제해 읽는 선택이고, CQRS는 쓰기 모델과 읽기 모델의 책임을 분리하는 선택이다.
  • CQRS를 쓰면 항상 이벤트 소싱이 필요하다고 오해하기 쉽다. 이벤트 흐름이 자주 같이 등장하기 때문이다.
    • CQRS는 command/query 분리이고, 이벤트 소싱은 상태 저장 방식을 이벤트 로그로 바꾸는 별도 결정이다.
  • read model이 빠르면 정합성 문제가 사라진다고 생각하기 쉽다. 조회 응답은 빨라졌기 때문이다.
    • 실제 문제는 “빠른데 오래된 값”이며, 이 값을 사용자와 운영자에게 어떻게 설명할지가 설계의 일부다.

확인 질문

  • 확인 질문: Read Write 분리는 무엇을 바꾸는가?
    • 답변: 쓰기 모델의 트랜잭션 보호와 읽기 모델의 조회 최적화를 분리해 성능을 바꾸지만, 정합성 지연과 운영 복잡도를 늘린다.
  • 확인 질문: read replica만으로 충분한 경우는 언제인가?
    • 답변: 조회 부하는 크지만 원본 테이블 형태로도 쿼리가 가능하고 replica lag를 허용할 수 있을 때다.
  • 확인 질문: projection read model을 도입하기 전에 반드시 확인할 것은 무엇인가?
    • 답변: 이벤트 순서, 멱등 갱신, lag 지표, rebuild 절차, stale 응답 계약을 감당할 수 있는지다.

참고 자료 기준