[CQRS] 명령과 조회를 분리하는 CQRS로 개발하기 - 1

왜 갑자기 CQRS를 도입해요?

CQRS는 명령과 조회를 분리함으로써 성능 향상 및 결합도가 낮아지는 효과를 기대할 수 있습니다. 채팅 서비스를 구현하게 된다면 일반 게시글이나 댓글에 비해 더 많은 양의 데이터가 저장될 것이라고 생각했습니다. 이를 위해 명령과 조회를 분리하고 조회에 성능이 좋은 NoSQL을 일관성과 정확성이 중요한 데이터 처리, 복잡한 관계 처리, 안정성을 보장하는 RDB를 조합하여 최적의 데이터베이스 환경을 구성하려고 합니다.

CQRS 도입이 필요할까요?

CQRS 패턴은 모든 상황에 적합한 해결책은 아닙니다. 사용 여부는 프로젝트의 요구사항과 복잡성에 따라 결정되어야 합니다. 오히려 단순한 CRUD 작업이 주로 이루어지는 간단한 애플리케이션에는 비효율적입니다. 근데 사실 한 번 써보고 싶기도 하고 어떤 장점이 있을까 해서 채팅 서비스를 CQRS로 구현하려고 합니다.

DB가 분리가 된다면 일관성은 어떻게 보장해 주나요?

처음 CQRS에 대해 알게 되었을 때 조회와 명령으로 DB가 분리된다면 대체 어떻게 데이터가 동기화되는 걸까?라는 의문이 제일 먼저 생겼다. 이때 강사님께 질문을 드렸는데 메시징 큐를 통해 비동기 처리를 해주면 된다는 것을 알게 되었습니다.

 

메시징 큐 선택

비동기 처리를 위해 어떤 메시징 큐를 사용할 것인지에 대한 고민이 생겼다. 메시징 큐는 두 가지가 대표적이라고 합니다.

1. Kafka

2. RabbitMQ

공통점

1. Kafka와 RabbitMQ 모두 메시지를 안전하게 전달합니다. 메시지를 생성하고 Producer가 Consumer에게 전달합니다.

차이점

처리 방식

1. Kafka는 메시지를 토픽으로 구성하여 여러 소비자 그룹이 해당 토픽을 구독하고 메시지를 처리. (pub/sub 방식)
    RabbitMQ는 메시지를 큐에 저장하고 소비자가 해당 큐에서 메시지를 가져와 처리. (메시지 브로커 방식)

용도의 차이

2. Kafka는 병렬 처리와 메시지를 지속적으로 저장하여 데이터를 보존, 대용량 데이터 처리와 장기적 데이터 보존에 적합.
    RabbitMQ는 메시지를 큐에서 소비되면 메모리에서 제거,실시간 메시지 처리에 적합.

Kafka 선택

저는 채팅 서비스에 CQRS를 구현하려고 합니다. 실시간 메시지 처리에 적합한 건 RabbitMQ가 아닌가? 라는 생각이 들었습니다. 하지만 Kafka를 선택한 이유는 많은 양의 데이터를 한 번에 처리하기 위해 CQRS를 도입한 것이기 때문입니다.

 

결론

CQRS와 메시징 큐를 도입하는 프로젝트에 대해 간단히 설명했습니다. 하지만 CQRS 및 메시징 큐는 이렇게 간단하게 설명되는 것이 아니라 조금 더 확실하게 알고 가면 좋을 거 같습니다.