강의

멘토링

커뮤니티

Cộng đồng Hỏi & Đáp của Inflearn

Hình ảnh hồ sơ của ash
ash

câu hỏi đã được viết

Nhập môn và Thực tiễn MSA dành cho cả người không chuyên (feat. Spring Boot)

Yêu cầu và thiết kế dự án MSA

MSA 프로젝트 요구사항 및 설계 에서의 FK

Viết

·

43

0

안녕하세요 강의 잘 듣고있습니다.

MSA 프로젝트 요구사항 및 설계 부분에서

모놀로식으로 설계하게 될때는

FK 를 걸지만 MSA 에서는

DB가 독립적으로 분리되어 있어서 FK 를 걸 수 없을것 같습니다 .

Application 단에서도 하지않나요 ??

예를들어서

 

@ManyToOne

user: User;

 

아키텍처spring-cloudkafkamsadevops

Câu trả lời 2

0

jscode님의 프로필 이미지
jscode
Người chia sẻ kiến thức

안녕하세요 ! 질문 잘 해주셨어요 ~

질문해주신 내용에 답변 드려볼게요 !

"MSA 프로젝트 요구사항 및 설계 부분에서 모놀로식으로 설계하게 될때는 FK 를 걸지만 MSA 에서는 DB가 독립적으로 분리되어 있어서 FK 를 걸 수 없을것 같습니다 . Application 단에서도 하지않나요 ??"

-> 맞아요 ! MSA에서는 서비스별로 DB가 분리되어 있기 때문에 DB 레벨의 FK 제약은 걸 수 없고, 말씀하신 것처럼 @ManyToOne 같은 ORM 연관관계 매핑도 사용하지 않아요 ~

대신 연관된 데이터가 필요할 때는 다른 서비스의 ID 값만 가지고 있다가, 필요한 시점에 해당 서비스에 API 호출을 해서 데이터를 가져오는 방식으로 처리해요 !

예를 들어 Order 서비스에서 User 정보가 필요하다면 @ManyToOne으로 User를 직접 참조하는 게 아니라 userId만 저장해두고, 필요할 때 User 서비스에 REST API나 메시지 큐를 통해 요청하는 식이죠 !

그래서 MSA 환경에서는 데이터 정합성을 DB가 아닌 애플리케이션 로직과 서비스 간 통신으로 보장해야 하기 때문에 설계가 더 복잡해지는 트레이드오프가 있죠 :)

추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

SJ님의 프로필 이미지
SJ
Người đặt câu hỏi

만약에 그렇게 된다면 ORM 에서 기능으로 User 이런 객체를 넘겨서 where 조건 걸기도 하는데

예를들어서
foudUser = User

find({ where: { user: foundUser } )

등 이런식으로는 하지 못하는건가요 ??

 

그리고 예를들어서 left join 을 가져오게 될때 ,

leftJoin('user.board ' )

application 단에서 @OneToMany 가 걸려있다면 이런식으로 가져올수있는데

이렇게도 못가져오게 되나요 ??

 

만약 그렇다면 어떤식으로 하시게 되나요 ?

jscode님의 프로필 이미지
jscode
Người chia sẻ kiến thức

안녕하세요 ! 추가 질문 잘 해주셨어요 ~

질문해주신 내용에 답변 드려볼게요 !

"foudUser = User find({ where: { user: foundUser } ) 등 이런식으로는 하지 못하는건가요 ??"

-> 맞아요! MSA에서는 서비스 간 DB가 완전히 분리되어 있기 때문에 ORM을 통해 다른 서비스의 엔티티를 직접 참조하는 방식은 사용하지 않아요 ~

대신 userId처럼 ID 값만 저장해두고 find({ where: { userId: foundUser.id } }) 이런 식으로 ID 기반으로 조회하게 돼요 !

" left join 을 가져오게 될때 , leftJoin('user.board ' ) application 단에서 @OneToMany 가 걸려있다면 이런식으로 가져올수있는데 이렇게도 못가져오게 되나요 ??"

-> 이것도 마찬가지에요 ! DB가 물리적으로 분리되어 있기 때문에 서비스 간 JOIN 자체가 불가능해요 !

그래서 MSA에서는 각 서비스에서 필요한 데이터를 따로 조회한 다음 애플리케이션 레벨에서 직접 합치는 방식으로 처리해요 ~

예를 들어 게시글 목록에 유저 정보가 함께 필요하다면, Board 서비스에서 게시글 목록을 먼저 조회하고 거기에 담긴 userId들을 모아서 User 서비스에 API 호출로 유저 정보를 가져온 다음 애플리케이션 코드에서 두 데이터를 조합하는 식이죠!

이런 구조 때문에 MSA는 모놀리식에 비해 데이터 조회 로직이 훨씬 복잡해지고 네트워크 비용도 늘어나는 트레이드오프가 있어요 !

그래서 MSA가 항상 정답은 아니고, 서비스 규모와 팀 상황에 맞게 선택하는 게 중요해요 :)

추가로 궁금하신 점 있으시면 언제든 추가 질문 남겨주세요!

SJ님의 프로필 이미지
SJ
Người đặt câu hỏi

답변 감사합니다 !! 🙂

0

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

MSA(Microservices Architecture)에서의 외래 키 사용에 대해 궁금하신 점이 있으시군요. MSA에서는 각 마이크로서비스가 독립적으로 운영되기 때문에 데이터베이스도 각 서비스에 맞춰 분리하여 사용하는 경우가 많습니다. 이러한 구조에서는 전통적인 데이터베이스의 외래 키(FK) 제약 조건을 적용하기 어려운 경우가 많습니다.

MSA에서의 FK 사용에 관한 주요 포인트:

  1. 독립된 데이터베이스: 각 서비스는 자신의 데이터를 독립적으로 관리하고, 다른 서비스의 데이터와 직접적인 외래 키 관계를 설정하지 않습니다.

  2. Application 단에서의 관계 관리: MSA에서는 데이터베이스의 외래 키 대신, 애플리케이션 단에서 데이터 간의 관계를 관리합니다. 예를 들어, JPA의 @ManyToOne 어노테이션과 같은 ORM 매핑을 활용하여 객체 간의 관계를 명시적으로 표현할 수 있습니다. 하지만 이는 데이터베이스 수준에서의 FK를 설정하는 것과는 다릅니다.

  3. 데이터 일관성: 대신, 서비스 간의 일관성을 유지하기 위해 이벤트 기반 아키텍처를 사용하거나, 각 서비스의 API를 통해 필요한 데이터를 인정받는 방식으로 데이터를 동기화할 수 있습니다.

관련된 학습 자료나 유사 질문의 답변을 통해 더 구체적인 내용을 확인해 보시면 도움이 될 것입니다:

현재 본 강의에서 다루는 MSA 설계에 대한 좋은 예시와 일반적인 프랙티스들은 질문 해결에 큰 도움이 될 것입니다.

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

Hình ảnh hồ sơ của ash
ash

câu hỏi đã được viết

Đặt câu hỏi