인기글 선정과 관련해서 궁금한 점이 있습니다.
안녕하세요
강의 주제와는 맞지 않는 질문일 수도 있는데
모놀리식 아키텍처에서는 그냥 게시글 생성/수정/삭제, 댓글 생성/삭제 등 이런 로직에서 점수를 업데이트하면 될 것 같아서 그런데
모놀리식 아키텍처에서는 이벤트 방식으로 인기글을 선정하는 방법은 불필요하게 복잡하게 구현하게 되는걸까요?
답변 2
4
eoyeong님, 안녕하세요!
말씀하신 것도 충분히 좋은 방법입니다.
굳이 작은 규모의 시스템에서는 처음부터 복잡한 시스템(MSA 등)을 구축하며 오버엔지니어링 할 필요는 없습니다.
"분산 데이터 모델링"에서 설명하듯이, 도메인 간 경계만 잘 정리해두면,
나중에 분산의 필요성이 생길 때 비교적 손쉽게 처리할 수도 있고요.
아직 분산의 필요성이 안 보인다면, 그냥 게시글/댓글/조회수 처리되는 시점에 즉시 인기글 점수 산정하는 것이 쉽고 충분합니다.
다만, 이 부분은 염두에 두면 좋을 것 같은데요.
트랜잭션의 범위는 잘 고민해보시면 좋습니다.
메인 DB(강의에서는 MySQL)의 리소스는 가장 소중하기 때문에,
트랜잭션 범위를 적절하게 설정해야 효율적으로 사용되거든요. (너무 길어지면 DB커넥션/스레드 등의 리소스가 고갈될 수도 있겠죠!)
원본 데이터 CUD와 인기글 점수 산정 작업을 단일 트랜잭션으로 처리해야하는하는가 대해서는 고민해보시는 것도 좋을 것 같습니다.
그 과정에서 코드 구조를 어떻게 만들어나갈 수 있을지에 대한 고민도 많이 생기고요.
외에도, 동기/비동기(사용자 입장에서 인기글 처리를 기다려야하는가?)에 대한 고민도 같이 해보시면 좋습니다.
뒷단에서 인기글 선정이 되든말든 사용자는 당장 알 수도 없고 관심도 없는데, 인기글 선정을 단일 요청에서 처리 및 대기해야 하고, 그 작업이 길어지면 사용자 응답 지연이 생기게 됩니다.
또, 이벤트는 반드시 카프카와 같이 글로벌한 메시지 브로커를 통해서 발행되어야 하는 건 아닙니다.
이벤트는 단지 어떠한 사건이 발생했음을 알려주는 데이터일 뿐입니다.
어떻게 주고 받을지는 구현에 따라 다양할 수 있습니다.
예를 들어, 스프링부트에서 제공하는 ApplicationEventPublisher를 활용하면, 단일 애플리케이션 내에서 이벤트를 발행하고 수신할 수도 있습니다.
이벤트를 적절히 활용하면서도, 그 구현은 훨씬 간단하고 편한 방법이 많습니다.
이벤트를 활용하면, 어떠한 책임에 대해서 분리하기도 쉬워지고요.
말씀 주신 작업에서는, 원본 데이터 작업과 인기글 선정 작업에 대한 코드를 적절히 분리할 수도 있겠네요.
혹시 더 궁금한 점 있으시면 편히 문의 주세요!
2
너무 장황하게 말씀드렸나 싶기도 하네요.. ㅎㅎㅎ
아직 경험이 부족할 때에는 이러한 부분들을 다 고려하면서 만들기는 현실적으로 어려울 수 있어서,
당장은 생각하신대로 만들어보는 것도 좋을 것 같네요!
이후에 고도화하면서 더욱 정리할 필요성이 보일때 차츰 정리해나가시는 것도 충분합니다!
화이팅입니다!!
2
아뇨 전혀 장황하지 않고, 질문에 대한 답변을 너무 정성스럽게 달아주셔서 강의만큼이나 도움이 되는 답변이 많아 좋은 것 같아요!
다른 분들 질문에 대한 답변도 다 읽어보는 중입니다 ㅋㅋ
처음부터 완벽하게 만들어야겠다는 생각을 좀 내려놔야겠네요 ㅎㅎ
1
안녕하세요, 인프런 AI 인턴입니다. eoyeong님.
모놀리식 아키텍처와 이벤트 기반 아키텍처는 서로 다른 장단점을 가지며, 인기글 선정 방법에 영향을 미칠 수 있습니다. 질문해주신 “모놀리식 아키텍처에서 이벤트 방식으로 인기글을 선정하는 방법”에 대해 간단한 설명을 드리겠습니다.
모놀리식 아키텍처에서의 인기글 선정
간단한 접근 방식:
- 모놀리식 아키텍처에서는 데이터베이스 내에서 직접 게시글의 점수를 업데이트하는 방법이 일반적입니다. 이 방법은 코드가 단순하고 이해하기 쉬우며, 동일한 트랜잭션 내에서 여러 작업을 처리할 수 있어 데이터 일관성을 쉽게 유지할 수 있습니다.
- 모놀리식 아키텍처에서는 데이터베이스 내에서 직접 게시글의 점수를 업데이트하는 방법이 일반적입니다. 이 방법은 코드가 단순하고 이해하기 쉬우며, 동일한 트랜잭션 내에서 여러 작업을 처리할 수 있어 데이터 일관성을 쉽게 유지할 수 있습니다.
이벤트 기반 접근 방식의 고려사항:
- 모놀리식 아키텍처에서 이벤트 기반 시스템을 도입하면, 시스템이 과도하게 복잡해질 수 있습니다. 특히, 이벤트 전달 및 처리를 위한 추가적인 인프라가 필요하고 이벤트의 비동기 특성으로 인해 데이터 일관성에 대해 추가적인 고려가 필요합니다.
- 그러나 이벤트 기반 시스템은 각 컴포넌트의 결합도를 낮출 수 있어 시스템의 부분적인 변화나 확장을 더 쉽게 할 수 있다는 장점이 있습니다.
- 모놀리식 아키텍처에서 이벤트 기반 시스템을 도입하면, 시스템이 과도하게 복잡해질 수 있습니다. 특히, 이벤트 전달 및 처리를 위한 추가적인 인프라가 필요하고 이벤트의 비동기 특성으로 인해 데이터 일관성에 대해 추가적인 고려가 필요합니다.
결론
- 적용 가능 여부: 모놀리식 아키텍처에서는 단순한 코드와 설계가 더 유리할 수 있습니다. 시스템이 크고 복잡하지 않다면 굳이 이벤트 기반 아키텍처로 구현할 필요가 없을 수 있습니다.
- 시스템 확장성: 반면, 장기적으로 기능이 추가되고 시스템이 확장될 것이라면 이벤트 기반 아키텍처를 고려하는 것이 유리할 수도 있습니다. 그러나 이 경우에도 모놀리식 구조 내에서 가능한 간소한 형태로 구현하는 것이 좋습니다.
이 주제에 관련된 더 많은 정보는 아래 유사한 질문 답변 링크를 참고하시기 바랍니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
@Version 어노테이션이 붙은 필드는 낙관적 락이든 비관적 락이든 업데이트가 됩니다.
0
31
1
consumer에서 에러가 발생할 경우 데이터 유실 문의
0
49
2
게시글 테스트 데이터 삽입
0
51
2
정렬, 필터, 검색 등의 조건이 붙을 경우 최적화할 수 있는 방법이 무엇이 있을까요?
0
104
2
좋아요 기능 정합성 보장 방법
0
98
2
좋아요 동시성처리 최적의 선택?
1
137
2
프론트엔드 msa 환경 api 주소 통합? 과 서버끼리 통신 방식에대해
0
92
2
안녕하세요 무한스크롤 강의듣다가 질문이 있습니다.
0
61
1
조회수 조회 로직 질문
1
67
2
비로그인 유저도 어뷰징 방지 정책
1
73
2
CommentServiceTest의 테스트 로직 질문
0
54
2
무한 스크롤 방식에서 페이지 번호 방식 쿼리의 문제점 의문
1
74
2
path 쿼리 관련 질문드립니다!
0
60
2
antigravity 에디터를 쓰신다면 종료해주세요
1
123
0
프로젝트 구조
0
88
2
article_like_count api test
0
79
2
이벤트 페이로드 객체의 생성 방식이 팩토리 메서드 패턴이 아닌 빌더 패턴인 이유가 궁금합니다!.
0
104
2
[33. 좋아요 수 구현] 에서 테스트 하는 화면 동시성 문제
0
92
2
findByPath에서 articleId로도 검색을 해야 할 것 같아요.
0
94
3
jpa ddl-auto none을 하는 이유와 join 방법
0
97
2
팩터리 메소드와 response 객체 사용 이유가 궁금합니다!
0
91
2
커서 기반 페이지네이션 과 무한 스크롤링
0
111
2
게시글 생성 로직에서 오류 발생시 redis 게시글 수 되돌리기
0
97
2
멀티 모듈이 아닌 MSA 환경에서 common
0
158
2