조회수 정보를 어디서 저장할지 고민입니다.
안녕하세요. 강의 너무 잘 듣고 제 프로젝트에 필요한 부분들로 리팩토링 하면서 MSA를 처음 공부하려 했습니다!
먼저 제 프로젝트는 거의 똑같은 구조로 게시글이 있습니다. 2가지의 질문이 있습니다.
(1) 정보를 취합하기 위해 동기로 API호출을 한다는 것은 장애 전파가 된다고 이해하고 있습니다. 그렇다면 저희 예시에서도 Article-read에서 조회수는 api호출을 통해 받기로 했습니다. 그렇다면 어느정도의 장애 전파는 허용한다고 받아들여집니다. 실제 서비스에서도 여러 정보를 취합해서 줘야하는 경우가 많을텐데 API를 통해 정보를 가져오는것이 절대 안되나요? 아니면 종종 허용하기도 하나요?
(2) CQRS의 Query(질의)부분은 데이터 수정이 없어야 한다 이해했습니다. 그런데 데이터를 수정해도 되나요?
예를 들어 제가 게시글 상세 조회를 게시글 모듈에서 분리하려고 합니다. 그런데 게시글 상세 조회를 하게되면 조회수가 올라갑니다. 따라서 게시글 상세조회 발생 -> 조회수 증가 이벤트 발생 ->조회수 증가 이런 식으로 구상을 했습니다. 이러한 질의 부분 모듈에서 데이터를 수정하게 만드는 이벤트가 발생해도 괜찮을지 여쭤봅니다!!
답변 2
0
dohyeong254님, 안녕하세요!
(평일에 시간이 안 나서 답변이 늦어졌습니다.. ㅠ)
1)
의존성에 대한 고려가 되어있다면 API로 호출하셔도 됩니다!
Article-read는 조회를 특히나 최적화하고 트래픽을 격리하기 위함이지,
이처럼 구성하면 시스템 복잡도나 비용이 올라가기 때문에 딱히 문제 없으면 API 호출하는게 훨씬 편합니다.
애플리케이션에서 조인하는게 많으면 응답 시간이 지연될 수 있지만, 리액티브 방식이나 멀티스레드 등으로 병렬 조회하거나 캐시를 붙여서 개선할 수도 있습니다.
물론, 장애 전파에 대한 부분은 당연히 고려가 되어야 하고요.
호출처 측에서 캐시를 활용하면 성능 이점 뿐만 아니라 트래픽 전파도 막을수 있고,
강의에서 다루진 않은 부분이지만 장애 시에는 서킷브레이커를 활용할 수도 있습니다.
2)
Query 전용 서비스(게시글 상세 조회)에서 데이터 수정을 같이 처리해도 될지를 여쭤보신 걸까요?
해당 마이크로서비스의 정체성에 대해 정의 내리기 나름일 것 같습니다.
반드시 Query 전용 서비스로 사용하고, 직접적으로 데이터 수정을 허용하지 않을거라면 막아야하는게 당연합니다.
이미 해당 마이크로서비스의 역할을 그렇게 정했기 때문입니다.
그런데 “게시글 상세 조회”에 특화된 마이크로서비스로 사용할 것이고, “조회수 증가”도 같이 처리하고 싶다면 그렇게 하셔도 됩니다!
사실 구현 방법에 대해서는 정답이 없는거라, 장단점 고려해보시고 채택하셔도 무방합니다.
다만, CQRS에서 언급 드렸던 의존성에 대한 부분은 특히 잘 신경써보시면 좋을 것 같네요!
1
답장 너무 감사드립니다!!! 생각하지 못한 부분으로 더 뻗어나갈 수 있겠네요.
답변에서 또 생각해볼 부분들을 알게되어 기술적 트레이드 오프를 고민할 단초가 된 것 같습니다. 감사드립니다!!
0
안녕하세요, 인프런 AI 인턴입니다. dohyeong254님.
질문해주신 내용에 대해 아래와 같이 답변을 드리겠습니다.
(1) 동기 API 호출과 장애 전파
대규모 시스템에서는 여러 모듈 간의 직접적인 동기 호출이 장애 전파의 위험성을 높일 수 있는 것은 사실입니다. 따라서 일반적으로 각 모듈 간에는 비동기 방식의 메시징 시스템을 사용하는 것이 안전합니다. 그러나 모든 경우에 비동기 처리가 가능한 것은 아니며, 다음과 같은 경우에는 동기 API 호출이 허용될 수 있습니다:
- 서비스 네트워크의 신뢰성: 통신 환경이 안정적이고 빠른 응답이 가능한 경우.
- 서비스 간의 강한 일관성 요구: 데이터의 최신 정보가 반드시 필요할 때.
- 사용자 경험: 빠른 반응이 중요할 때.
결론적으로, 시스템 설계 배경과 상황에 따라 동기 호출이 허용될 수 있으며, 심사숙고하여 결정을 내려야 합니다. 장애 전파 방지를 위한 추가적인 방안(예: Circuit Breaker)을 고려할 수 있습니다.
(2) CQRS의 Query와 데이터 수정
CQRS 패턴을 사용할 때, Query(질의) 모델은 일반적으로 데이터 조회 작업만 수행하는 부분으로 간주되어 데이터 수정을 하지 않는 것이 원칙입니다. 하지만, 조회 작업과 동시에 조회수 증가와 같은 간단한 상태 변경이 동반된다면, 이를 별도의 이벤트로 처리하는 방법을 고려할 수 있습니다. 예를 들어:
조회수 증가를 이벤트로 처리: 게시글 상세 조회 시 조회수가 증가하는 경우, 이를 ‘조회수 증가 이벤트’로서 비동기적으로 처리하여 CQRS의 Query 모델에서 데이터 수정을 직접 하지 않도록 설계할 수 있습니다.
결과 정합성 고려: 데이터 수정으로 인한 상태 불일치가 사용자에게 즉시 영향을 미치지 않도록 지연 시간과 같은 요소를 고려하여 설계를 최적화할 수 있습니다.
CQRS에서 꼭 모든 액션이 각각의 다른 모듈로 처리되어야 하는 것은 아니며, 상황에 따라 유연하게 접근할 수 있습니다. 추가로 CQRS 패턴의 유용성을 살리기 위해 수정과 조회를 위한 모델과 프로세스를 명확히 구분하는 것이 좋습니다.
이와 관련된 더 자세한 정보는 아래와 같은 유사한 질문을 참고하시면 도움이 될 것입니다:
- 멀티 모듈 구조에서의 API 호출 및 데이터 일관성 관리 (게시글 제목)
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
@Version 어노테이션이 붙은 필드는 낙관적 락이든 비관적 락이든 업데이트가 됩니다.
0
30
1
consumer에서 에러가 발생할 경우 데이터 유실 문의
0
47
2
게시글 테스트 데이터 삽입
0
49
2
정렬, 필터, 검색 등의 조건이 붙을 경우 최적화할 수 있는 방법이 무엇이 있을까요?
0
103
2
좋아요 기능 정합성 보장 방법
0
96
2
좋아요 동시성처리 최적의 선택?
1
134
2
프론트엔드 msa 환경 api 주소 통합? 과 서버끼리 통신 방식에대해
0
91
2
안녕하세요 무한스크롤 강의듣다가 질문이 있습니다.
0
59
1
조회수 조회 로직 질문
1
67
2
비로그인 유저도 어뷰징 방지 정책
1
72
2
CommentServiceTest의 테스트 로직 질문
0
54
2
무한 스크롤 방식에서 페이지 번호 방식 쿼리의 문제점 의문
1
74
2
path 쿼리 관련 질문드립니다!
0
59
2
antigravity 에디터를 쓰신다면 종료해주세요
1
123
0
프로젝트 구조
0
88
2
article_like_count api test
0
77
2
이벤트 페이로드 객체의 생성 방식이 팩토리 메서드 패턴이 아닌 빌더 패턴인 이유가 궁금합니다!.
0
104
2
[33. 좋아요 수 구현] 에서 테스트 하는 화면 동시성 문제
0
90
2
findByPath에서 articleId로도 검색을 해야 할 것 같아요.
0
91
3
jpa ddl-auto none을 하는 이유와 join 방법
0
97
2
팩터리 메소드와 response 객체 사용 이유가 궁금합니다!
0
90
2
커서 기반 페이지네이션 과 무한 스크롤링
0
109
2
게시글 생성 로직에서 오류 발생시 redis 게시글 수 되돌리기
0
97
2
멀티 모듈이 아닌 MSA 환경에서 common
0
156
2