728x90
반응형
CQRS
CQRS란 Command and Query Responsibility Segregation 의 약자입니다. 저장소로부터 질의/명령을 이용하여 읽기/ 쓰기 작업을 분리하여 애플리케이션의 성능, 확장성, 보안성 등을 증가시키는 방법입니다.
- 명령(Command): Aggregation을 중심으로 데이터의 변화를 만듭니다. 주로 쓰기 작업을 실행합니다.
- 질의(Query): Aggregation을 중심으로 데이터를 가져옵니다. 주로 읽기 작업을 실행합니다.
CQRS는 읽기/쓰기 모델을 분리하여 읽기 작업에 보다 높은 트랜잭션에서의 자유를 부여합니다. 주로 MongoDB와 같은 NoSQL을 사용하여 읽기 성능을 증가시킵니다. 쓰기 작업에는 PostgreSQL과 같은 RDBMS를 사용해 트랜잭션을 보장합니다.
읽기 저장소는 단순히 쓰기 저장소에서 레플리케이션 된 레플리카 저장소 일 수 있지만, 읽기의 성능을 증가시키기 위해 Aggregation 범위 안에서 도메인 객체를 연결해 성능을 향상시킬 수 있습니다.
장점
- 독립적인 스케일링: 읽기/쓰기 모델이 각각 독립적으로 스케일링을 할 수 있어 Lock 경합이 훨씬 덜 발생합니다. 이로 인해 레이스 컨디션, 데드락과 같은 데이터베이스 트랜잭션 문제를 예방할 수 있습니다.
- 보안: 읽기/쓰기 모델이 분리되면서 각 모델에 대한 접근을 분리할 수 있어 보안성이 증가합니다.
- 관심사 분리: 읽기/쓰기 모델에 대한 관심사가 분리되어 복잡한 비즈니스 로직은 쓰기 모델로 분리되고, 읽기 모델은 상대적으로 간단해집니다.
- 데이터 스키마 최적화: 읽기/쓰기 모델이 각각 성격에 맞게 최적화된 스키마를 가질 수 있습니다.
- 쿼리 단순화: 읽기 모델에 복잡한 조인문을 사용하지 않아도 됩니다.
단점
- 복잡성: 이벤트 소싱 패턴, 이벤트 드리븐 아키텍처와 같은 패턴을 포함할 경우 더 복잡해질 수 있습니다.
- 메세징: 주로 읽기/쓰기 모델의 통신에 메세징을 사용하므로 인프라 복잡성이 증가합니다.
- 데이터 일관성: 읽기 데이터의 일관성을 보장하기 어려울 수 있습니다. 쓰기 데이터의 레플리케이션은 지연될 수 있고 이에 따라 과거의 데이터를 읽어올 가능성이 있습니다.
정리
CQRS는 구조적, 성능적 이점을 가져올 수 있으나 읽기 지연, 아키텍처 복잡성 증가 등의 단점을 가지고 있습니다. 또한 메세징을 사용할 경우 각 메세지는 이벤트가 되고, 이벤트 소싱과 이벤트 드리븐 아키텍처로 구성되게 됩니다. 이럴 경우 아키텍처의 복잡성이 매우 증가하게 될 수 있고, 높은 수준의 개발 능력을 요구하게 됩니다.
간단한 구조일 때는 오히려 전통적인 방법을 사용하는 것이 데이터 일관성, 지연 속도 증가 등의 이점을 가져올 수 있습니다. CQRS를 적용하기 전엔 이에 대한 오버 엔지니어링 가능성과 가용 가능한 리소스, 트레이드 오프를 충분히 고려해보아야 합니다.
728x90
반응형