인프런 커뮤니티 질문&답변

gotjd9773님의 프로필 이미지

작성한 질문수

서버개발자 과제전형 완벽가이드 - 1편

데이터베이스 연결

cqrs에 관하여

해결된 질문

24.09.23 16:54 작성

·

33

0

안녕하세요. 지식공유자님!

데이터베이스 연결 강의를 보고 질문 드립니다.

서비스를 command와 query로 분리하고 있는데요.

이것을 cqrs 패턴으로 부른다고 알고 있습니다.

이게 좋다고는 들었는데, 정확히 왜 그런지는 잘 모릅니다.

만약, 면접관이 "cqrs에 대해서 아느냐? 왜 이렇게 구현했느냐?" 라고 묻는다면, 지식공유자님께서는 어떻게 답변하시겠습니까?

감사합니다.

답변 2

1

J Tech님의 프로필 이미지
J Tech
지식공유자

2024. 09. 24. 10:08

안녕하세요 gotjd9773님! 정말 좋은 질문 남겨주셨네요

결론부터 말씀드릴게요.

“cqrs에 대해서 아느냐?” 라고했을때는 

“명령과 조회 책임 분리로, 데이터 저장소에 대한 읽기와 업데이트 작업을 분리를 하는것을 의미합니다. 전통적인 CRUD접근법에서는 동일한 데이터모델을 사용하여 CRUD를 수행하지만 시스템이 복잡해짐에 따라 cqrs로 조회와 업데이트작업에 대한 최적화된 모델로 개선할 수 있게됩니다”

“왜 이렇게 구현했느냐?” 라고 했을때는

“고성능이필요한 애플리케이션에서 읽기 쓰기 부하를 분리하고 각각 독립적으로 확장시키기 위해서 구현하였습니다”


(부연설명)

첫번째 질문인 “cqrs에 대해서 아느냐?” 라고 했을때는 알고계신 개념을 말씀주시면 됩니다. 정의는 gotjd9773님께서 이미 알고계시기도하고, 웹상에 훨씬 자세하게 나와있기때문에 해당 내용을 참고하시는게 좋을것 같습니다.

오히려 두번째 질문이 더 중요할것같은데요, cqrs를 안써도되는데 썼기때문에 (물론 모델까지 충실히 분리하진 않았습니다. 요구사항을 보면 거의 1:1이기때문이에요) 합리적으로 설명을 잘 해야겠죠. 과제요구사항에 기반했을때는 대용량트래픽을 대비한 설계가 필요합니다. 이러한 서비스의 경우 보통 읽기의 워크로드가 쓰기보다 훨씬 높습니다.

저의 실무업무 경험상 대고객 트래픽이 중요하면서 굉장히 확장성이 높아야하는 프로젝트의 경우 command와 query서비스를 분리하는 형태가 관리와 유지보수가 쉬웠습니다. 과제에서는 메서드가 몇개 없지만, 실제로 위와같은 개발을 하다보면 서비스를 최대한 분리했음에도 한 화면에 담기지 않을정도로의 많은 양의 메서드가 존재하는경우도 많았습니다. 모델도 당연히 읽기/쓰기에 사용되는 형태도 달라지구요. 또한 읽기와 쓰기가 동일한 데이터베이스를 바라보지 않는 경우도 많습니다.

결론적으로 위와같은 확장성을 고려했을때 코드레벨에서 나누어놓는것이 향후를 생각했을때 최적의 판단이었다라고 생각합니다.

과제내에서 확장될 수 있는 부분은 “6강 면접대비 - 시스템고도화”에서도 말씀드렸다시피 ES와 같은 검색엔진을 도입하는것과 같이 시스템이 점차 확장됐을때 쓰기와 읽기의 데이터소스가 달라질 수 있습니다. 

물론 cqrs가 만능이 아닙니다. 복잡성이 높아진다거나 하는 단점도 존재하구요. 다만 현 상황을 해결하기위한 최적의 선택이다라는 기조로 말씀을 이어나가시면 될 것 같아요. 🙂

 

궁금증이 해결이 되지 않았다면 언제든 다시 말씀주세요 🙏

(인프런 AI인턴이 자동으로 댓글을 달아주는데.. 저건 그냥 참고만해주세요ㅎㅎ 맞는말이라도 내가 작성한 프로젝트에 연관되는 내용으로 설명해야합니다)

0

인프런 AI 인턴님의 프로필 이미지

2024. 09. 23. 16:56

안녕하세요, 인프런 AI 인턴입니다. gotjd9773님,

CQRS 패턴에 대해 질문 주셔서 감사합니다.

CQRS(Command Query Responsibility Segregation) 패턴은 Command와 Query를 분리하는 디자인 패턴입니다. 이는 시스템의 복잡성을 줄이고 성능 최적화를 가능하게 하며, 확장성과 유지보수성을 높일 수 있어 많은 장점이 있습니다.

간단하게 CQRS 패턴의 핵심 개념과 장점을 정리해드리겠습니다:
* Command와 Query의 분리:
- Command: 시스템의 상태를 변경하는 작업(예: 추가, 수정, 삭제).
- Query: 데이터를 조회하는 작업.
* 장점:
- 단일 책임 원칙: 각 클래스가 하나의 책임만 가지도록 해 코드의 명확성과 유지보수성을 높입니다.
- 성능 최적화: 읽기와 쓰기 작업을 분리하여 각각 별도의 저장소를 사용할 수 있어 성능을 최적화할 수 있습니다.
- 확장성: 읽기와 쓰기 작업이 분리되어 있기 때문에 각각의 요구사항에 맞게 독립적으로 확장할 수 있습니다.

이와 관련된 기존 지식 공유자의 답변들을 확인하시면 더 도움이 될 수 있습니다. 아래에 관련 링크들을 첨부합니다:

  1. 멀티모듈 구성에서 하위 모듈은 java 모듈로 하는 이유가 궁금합니다.

    • 모듈 간의 의존성 및 프로젝트 구조에 대한 설명이 있습니다.
  2. 포트폴리오 질문

    • 다양한 기술의 적용 시 고려해야 할 사항에 대한 내용이 포함되어 있으며, 클린 아키텍처에 대한 견해가 도움이 될 수 있습니다.
  3. Readme 파일 작성방법

    • README 파일 작성과 관련된 내용이지만, 프로젝트 구조와 관련된 참고 사항이 포함되어 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.