읽기, 쓰기 모델의 분리 - CQRS 패턴

CQRS(Command and Query Responsibility Segreagation)는 데이터 변경과 데이터 조회를 서로 다른 모델로 처리하는 것을 의미한다. 기존의 데이터베이스 접근 방식에서 변경과 조회에 대해 같은 모델을 사용하는 것과 달리 CQRS는 변경과 조회를 분리하여 처리한다.

전통적인 데이터베이스 접근 방식

하나의 데이터베이스 모델을 이용하여 변경과 조회를 처리한다면 어떤 문제들이 발생할 수 있을까?

1. 복잡한 요구사항의 경우 조회 시 성능 저하(복잡한 쿼리 동반)
2. 변경, 조회에 각각 필요한 정보를 하나의 모델에서 관리하면서 데이터 모델이 무거워짐
3. 동일한 데이터 모델에 병렬로 작업 수행시 경합 발생

물론 모든 경우에서 위와 같은 문제가 발생하지는 않을 것이다. 간단한 요구사항 같은 경우 변경과 조회 모델이 일치할 수도 있으며 큰 부하가 발생하지 않을 수도 있다. 다만, 위와 같은 문제가 발생한다면 CQRS 패턴 도입을 고려해볼 수 있겠다.

읽기, 쓰기 모델의 분리 - CQRS 패턴

CQRS 패턴은 CUD(Create, Update, Delete)와 READ 사이에 딜레이가 존재할 수 밖에 없다는 것을 인정하고 CUD와 READ의 모델을 분리하여 이점을 얻는 방식이다. CQRS는 아래 사진과 같은 방식으로 구현되어진다.

CQRS

위와 같이 읽기와 쓰기를 직접적으로 분리함으로써 여러가지 이점을 얻을 수 있다.

• 읽기 데이터베이스와 쓰기 데이터베이스의 독립적인 스케일링이 가능하다.
• 관심사의 분리 덕분에 유지, 보수에
• 읽기 성능 상승 및 심플한 쿼리

예상되는 문제점과 제한사항

CQRS는 읽기 성능 및 확장성에 큰 이점을 가져다주지만 모든 솔루션들이 그렇듯 장점만 존재하지는 않는다.

1. 일관성의 희생
   • CUD 작업 이후 이에 따른 이벤트를 발행하고 이벤트 처리를 통해 읽기 데이터베이스를 업데이트한다. 이때 쓰기 작업과 읽기 데이터 업데이트 사이의 딜레이로 인한 데이터 불일치 현상이 발생한다. 때문에, 일관성이 다소 중요하지 않은 프로그램에서 사용하는 것이 적합하다.
2. 비동기 이벤트 처리의 복잡성
   • 쓰기 작업 시 발행되는 이벤트를 처리하기 위해 메시지 큐나 이벤트 핸들링을 사용한다. 여기서 이벤트 처리 순서나 실패 시 재시도와 같은 문제들을 발생할 수 있기 때문에 이를 고려해야한다.

위와 같은 단점이 존재하기 때문에 CQRS를 도입할 때 충분한 고려가 필요하다. 만약 실시간 업데이트가 중요한 어플리케이션에서 CQRS를 이용하게 된다면 일관성 문제로 인해 유저들의 비난이 쏟아질 수도 있을 것이다.