인프런 커뮤니티 질문&답변
작성한 질문수
수강중에 궁금한것이 생겨 질문드립니다.
해결된 질문
작성
·
73
·
수정됨
0
안녕하세요 좋은강의 감사드립니다. 제 주변도 사서 듣는다고 합니다.
예전에 완강해놓고 관련프로젝트를 하다 궁금한점이 생겼습니다.
이런식으로 분리된 구조라면, 유저 정보는 어떻게 가져오는건가요??
예를들어서 게시판이면, 거기에 들어가면 게시글들이나 댓글들 뿐만 아니라 유저의 닉네임이라던가, 유저가 설정한 대표이미지 라던가 등등 유저정보에 관한것들도 같이 뷰 렌더링을 위해선 필요한 정보들일텐데
유저와 관련된 서비스도 뭔가 따로 분리가 되어있을것 같은데 이때 유저 정보들은 어떻게 같이 가져오는지 궁금합니다.
디비도 다 따로 사용할텐데 연관관계매핑도 아닐테고...모르겠네요
답변 2
0
한국의일론매식기님, 안녕하세요!
낯익은 닉네임인데 오랜만에 다시 인사 드리네요.
일단 말씀 주신 질문은, 유저 도메인이 하나의 마이크로서비스로 분리된 상황을 염두에 두신 것 같습니다.
강의에서 하나의 마이크로서비스로 분리했던 인기글 서비스를 예시로 들어보겠습니다.
인기글 서비스는 게시글/댓글/좋아요/조회수 서비스에 직접적으로 의존성을 가지고 있습니다.
인기글 데이터를 만들기 위해서 또는 인기글이 가지고 있지 않은 데이터를 가져오기 위해서 게시글/댓글/좋아요/조회수 서비스에 접근할 수 있는 것입니다.
이러한 관계를 보면, 인기글 -> 게시글/댓글/좋아요/조회수 서비스에는 단방향 의존성이 만들어져있다는 사실을 알 수 있습니다.
하지만 게시글/댓글/좋아요/조회수 서비스는 인기글 서비스를 모릅니다.
게시글/댓글/좋아요/조회수 서비스는 인기글이 어떻게 만들어지는지 관심도 없고, 이를 만들어주기 위한 책임도 없습니다.
이렇게 도메인 간에 단방향 의존 관계가 만들어져 있는 것입니다.
유저 도메인의 예시를 보겠습니다.
게시글을 작성하려면, 당연히 사용자가 우선적으로 있어야합니다. 이를 위해 게시글이 처리될 때 사용자의 유효성이 먼저 검증되어야 합니다.
따라서, 게시글 -> 사용자로 의존 관계는 불가피합니다. (이러한 의존 관계는 데이터 모델 간에 참조 방향으로 이해하셔도 좋습니다)
하지만 사용자는 게시글 도메인이 있는지 모를 수 있고, 알 필요도 없습니다.
그러면, 게시글 -> 사용자에 대한 단방향 의존 관계만 유지할 수 있습니다.(단방향에 대한 이야기는, 순환 참조에 대한 복잡성에 대해 참고해보시면 됩니다.)
게시글이 유저 도메인에 접근하는게 어색함이 없다는 것을 의미합니다.
게시글 생성/수정/삭제 시점에 사용자를 검증해야 한다면? 게시글은 그냥 유저 도메인에 접근해서 회원 정보를 불러와서 사용자를 인증하고, 해당 API를 호출할 수 있는지 확인하여 인가해주면 됩니다.
이러한 구조에 대한 실 구현은 다양할 수 있는데요,
앞단에 인증 레이어를 만들어서 인증된 토큰 정보를 마이크로서비스 간에 전달해도 되고,
유저 도메인에 접근하여 인증 정보를 각 마이크로서비스에 뿌려주는 인증 모듈을 제공할 수도 있는 등.. 꼭 정해진 정답은 없습니다.
사용자에 대한 정보를 화면에 나타내기 위한 방법도 마찬가지입니다.
게시글은 유저 도메인에 접근할 수 있으므로 게시글 서비스에서 유저 서비스에서 필요한 정보를 불러와서 같이 내려주는 서버 간 통신으로 해결해도 되고,
클라이언트 코드에서 유저 도메인에 직접적으로 접근해도 되고,
클라이언트가 데이터를 조합하기 위한 BFF를 구성해도 되고,
백엔드에서 데이터를 조합하기 위한 레이어를 하나 추가로 구성해줄 수도 있습니다.
서버에서 데이터베이스가 분리되어 있다고 해도, 결국 클라이언트 관점에서는 필요한 데이터를 받을 수 있는지가 궁금할 뿐입니다.
서버의 도메인 관점에서는 데이터를 어디서 불러오든지 상관 없습니다. 그저 기술과 구현의 차이일 뿐입니다.
DB에서 즉시 조인하지 못한다면, 마이크로서비스의 각 분리된 데이터베이스에서 필요한 데이터를 불러오고,
애플리케이션 레벨에서 데이터를 조합하여 응답할 수도 있는 것입니다.
정형화된 방법은 없지만, 의존 관계와 애플리케이션 조인 등을 활용해서 적절한 구조를 만들어낼 수 있다고 봐주시면 될 것 같네요!
여기에서 적절함의 기준은, 클라이언트 개발자와의 협의, 개발 비용(돈 문제 뿐만 아니라 생산성/유지보수/개발 난이도) 등 다양한 요인이 고려될 수 있을 것 같습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 한국의일론매식기님.
강의를 수강하며 MSA(Microservices Architecture) 및 데이터 분리에 대한 궁금증이 생기셨군요. MSA 환경에서는 데이터가 여러 서비스에 분산되어 있기 때문에, 각각의 서비스가 필요한 정보를 어떻게 얻는지가 중요한 과제가 됩니다.
MSA에서 유저 정보 가져오기
API 호출:
각 서비스는 필요한 정보를 얻기 위해 서로 API를 통해 통신합니다. 게시판 서비스에서 유저 정보를 필요로 할 때, 유저 서비스에 API 요청을 보내 필요한 데이터를 가져올 수 있습니다.
예를 들어, 게시글이나 댓글 리스트를 가져올 때 각 게시글/댓글의 작성자 ID 정보를 통해 유저 서비스에 해당 ID의 유저 정보를 요청하여 닉네임이나 프로필 이미지를 얻는 방식입니다.
이벤트 스트리밍 또는 메시지 큐:
- Kafka 같은 메시지 큐 시스템을 이용하여 서비스 간의 데이터를 비동기적으로 전달할 수 있습니다. 유저 정보가 업데이트되면 메시지 큐를 통해 다른 서비스에 변화된 정보를 전달하여 동기화할 수 있습니다.
- Kafka 같은 메시지 큐 시스템을 이용하여 서비스 간의 데이터를 비동기적으로 전달할 수 있습니다. 유저 정보가 업데이트되면 메시지 큐를 통해 다른 서비스에 변화된 정보를 전달하여 동기화할 수 있습니다.
데이터 복제:
- 모든 데이터를 다른 서비스에 복제하는 방식으로, 필요한 데이터를 각 서비스의 데이터베이스에 캐싱 형태로 유지할 수 있습니다. 하지만, 데이터 일관성 문제를 잘 관리해야 합니다.
- 모든 데이터를 다른 서비스에 복제하는 방식으로, 필요한 데이터를 각 서비스의 데이터베이스에 캐싱 형태로 유지할 수 있습니다. 하지만, 데이터 일관성 문제를 잘 관리해야 합니다.
API 게이트웨이 및 BFF(Backend for Frontend):
- API 게이트웨이를 통해 클라이언트에서 다수의 요청을 하나의 요청으로 처리할 수 있게 하며, BFF 패턴을 사용하여 각 클라이언트에 맞춤형 응답을 제공할 수 있습니다.
- API 게이트웨이를 통해 클라이언트에서 다수의 요청을 하나의 요청으로 처리할 수 있게 하며, BFF 패턴을 사용하여 각 클라이언트에 맞춤형 응답을 제공할 수 있습니다.
Federated Identity 및 Single Sign-On(SSO):
- 유저 인증 및 식별을 중앙 집중화하여 유저 정보의 일관성을 유지할 수 있습니다. 유저 데이터 관리는 따로 하더라도 각 서비스는 통합된 인증 시스템을 통해 유저를 식별할 수 있게 됩니다.
- 유저 인증 및 식별을 중앙 집중화하여 유저 정보의 일관성을 유지할 수 있습니다. 유저 데이터 관리는 따로 하더라도 각 서비스는 통합된 인증 시스템을 통해 유저를 식별할 수 있게 됩니다.
이와 같이 MSA 환경에서는 다양한 방법으로 유저 정보를 통합 관리합니다. 각 방식에는 장단점이 있으며, 시스템의 요구사항과 아키텍처에 맞춰 적절한 방법을 사용합니다.
이 주제와 관련된 더 자세한 정보는 강의의 추가 자료나 관련 질문 게시판을 참고하거나, 아래의 유사한 질문 링크를 통해 더 많은 정보를 얻으실 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.