작성
·
402
2
안녕하세요.
여태까지 강의를 듣던중에 의문이 생겼는데요
기존 JPA의 연관관계 매핑을 이용하던 설계 방식에서는 user entity에서 order의 PK가 아닌 order 엔티티 객체를 @OneToMany 와 같은 방식으로 객체 간의 연관관계를 맺어줌으로써 사실상 DB에서 PK로 order를 조회하는 방식을 사용해왔는데요
현재 강의에서처럼 마이크로서비스로 설계하게 되면 user-service가 order-service의 DB정보를 모르게되니 연관관계 매핑이나 join 문으로 조회하는 것도 아닌 http 요청을 한번 더 보내게되는게 어떤 이점을 가지나요? 후반부 강의를 아직 다 안들어서 그런지..
답변 3
5
안녕하세요.
강사님은 아니지만 제 생각을 말씀드리면, 실무에서 MSA를 도입하려면 우선 어느 정도 규모가 있는 시스템에 대하여 적용을 하게 될 것 같습니다.
현재 강의 예제 정도 규모의 시스템이라면 MSA 보다는 기존의 모놀리식 방식이 실무 서비스 운영하는데 개발/운영 리소스 비용이 더 적게 들어가지 않을까 싶습니다.
단, 서비스가 "어느정도" 규모가 있어지면 그때 MSA 전환/도입을 고민하게 될 것 같고, 이때 각 업무 도메인 간에 "어느정도" 유사성이 있는지를 고민하여 설계하게 될 것 같습니다. 이 "어느정도"에 따라 질문하신 분 의견 처럼 Join 키들 통해 같은 쿼리로 조회를 하게 할지, 아니면 MSA에 맞게 RestTemplate 또는 MQ로 연동하게 될지를 결정하게 될 것 같습니다.
3
안녕하세요. 그럼 이상적인 마이크로서비스 구조에서는 데이터 공유가 그렇게 잦은 것이 아니라면 각 테이블 간의 외래키를 통한 연관관계는 설정하지 않고 네트워크를 통해서 각각의 디비에 쿼리를 한번씩 날리는 것으로 해결하는 건가요?
현재 강의에서의 내용상 지금 방식은 이해하였고 다만 실무에서 사용한다면 어떤식으로 설계되는것이 좋은 것인지 궁금해지네요. 너무 작은 단위로 나누다보면 데이터베이스의 정규화나 JPA를 이용하여 객체지향적으로 설계하는 방식의 장점을 다 포기해야되는 것 같아서요
3
안녕하세요, 이도원입니다.
강의에서는 마이크로서비스 자체에 대한 기본적인 내용을 학습하는 것을 목표로 하였습니다. 따라서 각 마이크로서비스 간의 종속성이나 데이터의 연관성에 대한 구조 설계에 초점을 맞췄다기 보다는 마이크로서비스 간의 통신 방법의 하나인 RESTful API를 사용하여 통신하고, 데이터의 공류를 위한 Kafka를 사용해 보고 있습니다.
use-servicer와 order-service와의 연계를 고려하여 도메인 설계를 해야 하며, 데이터 공유가 잦을 경우, 서비스 경계를 나눌지 하나로 할지를 고민해 봐야 할 것 같습니다.
위에서 말씀드린 RESTful API는 사용법이 간단하다는 장점이 있는 반면, 말씀하신것처럼 Network 트래픽이 발생하게 됩니다. 성능의 향상을 위해서는 gRPC를 통한 통신 방법이나 서비스 설계를 다시 해 보는 것이 좋다고 생각됩니다.
답변이 되었으면 좋겠네요. 궁금하신 사항은 다시 글 남겨 주십시오.
감사합니다.