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

shinyurim님, 안녕하세요!

말씀주신 질문에 대해서는 여러가지 관점에서 살펴볼 수 있을 것 같습니다.

먼저 의존성 관점에서 살펴보겠습니다.

강의는 MSA로 구성되어 각각의 서비스가 도메인 단위로 분리되어 있습니다.

그리고 도메인 간에 의존성 방향으로 보면,

댓글/좋아요/조회수는 게시글을 참조하므로, 댓글/좋아요/조회수 -> 게시글로 단방향 의존성이 만들어져있습니다. (참조에 대한건 참조키, 데이터 유효성 검증 등의 관점에서 이해하면 됩니다.)

그런데 만약 게시글 생성/삭제 시점에 댓글/좋아요/조회수 서비스에 직접 호출해서 데이터를 초기화해 둔다면,

게시글 -> 댓글/좋아요/조회수 방향으로도 의존성이 생겨서 순환 참조가 발생하게 됩니다.

(순환 참조에 대한 문제는 다양하고 치명적인데요, 이러한 의존성에 대한 이야기와 해결 방법은 인기글/캐시 최적화 전략 챕터에서 조금 더 살펴보게 됩니다.)

물론, 순환 참조를 발생시키지 않고서도 게시글 생성/삭제 시점에 댓글/좋아요/조회수 초기화할 방법도 있습니다.

게시글 생성/삭제 시점에 이벤트를 발행하면, 댓글/좋아요/조회수에 간접적 의존성으로 바라보기 때문에 순환참조가 발생했다고 하진 않습니다.

(이러한 이벤트와 간접적 의존성에 대한 이야기는 인기글 챕터에서 조금 더 살펴보게 됩니다.)

이벤트 활용에 대한 언급은 의존성 문제를 해결하기 위한 하나의 방법인 것이라 언급 드렸는데, 당연히 시스템의 복잡도는 올라가게 됩니다.

MSA가 아닌 모놀리틱 아키텍처라면, 단일 애플리케이션에서 직접 코드에 접근할 수 있으므로 복잡도가 많이 올라가진 않겠지만요.

그런데 복잡도를 올리면서까지 생명주기를 동일하게 맞춰야할 필요가 있는지는 서비스 요구사항마다 다를 것 같습니다.

그래서 일단 의존성 방향에 대한 이야기는 이 정도로 언급드려보고, 이어서 생명주기 관점에서 살펴보겠습니다.

"게시글이 있다면 게시글 조회수 객체도 같이 존재하고, 이 둘의 객체 생명주기는 같아야 한다고 생각"

서비스 정책 상 필요하다면 그렇게 만들 수도 있으나,

반드시 생명주기가 같아야하는지, 또는 반드시 동기적으로 동시에 일어나야하는지에 대해서도 고민해볼 수 있을 것 같습니다.

조금 비슷하면서도 다른 예시로 댓글을 들어보겠습니다.

서비스에서 "내가 작성한 댓글 목록" 페이지가 있고, 정책 상 삭제된 게시글이더라도 댓글 목록을 보여줘야한다면,

게시글의 삭제 여부와는 무관하게 사용자의 데이터를 임의로 삭제하지 않고 남겨둬야 합니다.

이 경우 게시글이 삭제되더라도 댓글은 남겨두므로, 게시글과 댓글의 생명주기는 다를 수 있는 것입니다.

댓글 수만큼은 노출되는 영역이 없다고 하더라도, 댓글을 삭제할때 댓글 수도 같이 정리하면 충분합니다. 굳이 댓글 수만 먼저 제거할 이유도 없어지게 되고, 그렇지 않는게 오히려 일관된 설계가 되기도 합니다.

이러한 관점이라면 어차피 게시글과 댓글의 생명주기는 다르게 동작하므로,

댓글 수 생성도 게시글 생성 시점에 맞춰두지 않을 수 있는 것이고요.

또, 삭제된 게시글의 댓글 데이터를 노출해야하는 정책이 없다고 하더라도 생명주기를 다르게 운영해야하는 상황도 있습니다.

게시글 삭제 또는 사용자의 댓글 삭제에 의해 사용자에게는 댓글이 삭제된 것처럼 보이더라도,

내부적인 운영 방침 상 일정 기간 보관이 필요한 상황입니다. (사용자의 복구 요청, 데이터 추적이 필요한 경우 등)

참조가 끊겼고 어차피 노출되는 영역이 없다면, 게시글과 생명주기를 동일하게 만들지 않고 그대로 보관해뒀다가 배치 등으로 이후에 정리해도 충분합니다.

또, 게시글 생성/삭제에 참조 데이터들을 모두 실시간/동기적으로 생성/삭제한다는건 무겁고 복잡할 수 있습니다.

예를 들어, 게시글 생성/삭제 시점에 댓글/좋아요/조회수 외에도 수많은 참조 데이터가 있다면,

이러한 참조 데이터들을 모두 생성/삭제 시점의 생명주기를 동일하게 관리하는건 쉽지 않은 작업이 될 수 있습니다.

어떠한 액션이 없을 때까지 비어있는 데이터로 남아있을거라면, 굳이 불필요한 공간에 미리 만들어둘 필요도 없는 것이고요.

예를 들어, 댓글이 생성되지 않았는데도 댓글 수 데이터를 만들어둔다면, 값이 비어있는 상태로 불필요한 공간만 차지한 채 영구히 남아있게 됩니다.

이번에는 도메인 간 격리와 의존성 방향으로 보면, 게시글은 댓글/좋아요/조회수에 대해서 몰라도 되는데, 게시글 생성/삭제마다 모든 참조 모델을 만들어줘야한다는 사실을 게시글 서비스에서 알고 있어야한다는 것도 관리가 복잡해지는 지점이 되기도 합니다.

(이벤트를 사용한다는건 게시글이 불특정 다수에게 알려줄 뿐이라, 각 서비스에서 게시글 생성/삭제 이벤트만 구독하고 알아서 처리한다면 이런 부분은 해결되기도 하지만요.)

이러한 방법론에 대한 부분들은 실제 경험하지 않으면 와닿지 않을 수도 있고, 여러 엮인 내용들이 많고 방대하다보니 잘 이해가 되셨을진 모르겠습니다..!

정답도 없는 내용들이라 머릿속 생각들을 글로 풀어내는게 쉽진 않네요.

조금 더 편히 주고받고 싶으시면 멘토링으로 신청주셔도 좋습니다.(절대 강요 아님!)

아무튼, "생명주기가 반드시 달라야한다"라는건 아니고, 제가 말씀드린 내용이 모든 상황에 항상 더 나은 것도 아닙니다. 생명주기를 동일하게 하는게 유리한 상황도 많으니깐요.

여러가지 상황들을 고려했을 때, 생명주기를 다르게 운영하는게 유리할 때도 있다라는 것에 대해서 설명드리고 싶었습니다.

위 내용들 살펴보시고, 진행하시는 프로젝트에서는 생명주기를 동일하게 만들어도 괜찮겠다고 판단되시면 그렇게 하셔도 됩니다!

혹시 더 궁금한 점 있으시면 편히 문의 주세요!

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

질문 주신 내용은 likeCount, viewCount 등을 처음부터 게시글과 함께 생성하지 않는 이유에 대한 것입니다. 이러한 설계 선택은 시스템의 요구사항과 데이터베이스의 성능을 고려하여 결정됩니다.

이유: 초기화 방식의 선택

1. 데이터베이스의 성능 최적화:

   • 모든 게시글에 대해 likeCount나 viewCount를 미리 생성하면, 데이터베이스에 많은 빈 데이터를 저장하게 됩니다. 필요한 시점까지 초기화를 지연시킴으로써 공간 효율성을 높일 수 있습니다.
     

2. 지연 초기화(Lazy Initialization):

   • 초기화를 지연하여 필요할 때만 데이터를 생성하는 방법은 메모리 사용량과 초기 로딩 시간을 줄이는 데 도움이 됩니다. 이런 방식은 데이터가 사용되기 시작할 때까지만 리소스를 소비하게 합니다.
     

3. 유연한 데이터 관리:

   • 특정 데이터(예: 조회수)가 매우 자주 변동하는 경우, 데이터를 초기화하여 매번 누적 및 계산을 줄일 수 있습니다. 이 방식은 데이터가 실제 활용될 때만 적재하므로 효율적입니다.
     

초기화 방식 적용 고려 사항

• 빈도 및 성능 요구:

  • 만약 특정 프로젝트에서 likeCount나 viewCount를 모든 게시글 작성 시점에 바로 초기화하는 것이 성능 저하나 메모리 낭비를 유발하지 않는다면, 같이 생성하는 방법도 유효할 수 있습니다.
    

• 데이터 일관성:

  • 데이터를 함께 생성하면 데이터 일관성을 유지하기가 쉬울 수 있습니다. 즉, 초기화 데이터는 항상 게시글과 함께 존재하게 됩니다.
    

추가 고려 사항

• 업데이트 빈도:
  
  • 조회수나 좋아요 수가 매우 자주 업데이트되는 경우, 별도로 관리하는 것이 데이터베이스 부하 경감을 위한 좋은 선택일 수 있습니다.
    

위 설명을 통해 질문에 대한 이해와 설계 결정을 내리는 데 도움이 되길 바랍니다. 관련된 유사한 질문의 답변을 통해 더 많은 정보를 얻고 싶으시다면 아래 링크를 참고해 보세요:
- 좋아요 수 및 조회수 초기화 방식 선택에 대한 논의.

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