현업에선 MSA 환경에서 DTO 관리를 어떻게 하나요?

Question

예를 들어, WAS - Mail Server가 있고 이 둘은 MQ 방식으로 통신합니다.이 때, WAS, Mail Server간 메시지 형식을 정의하는 클래스 A가 있습니다.현업에서 WAS, Mail Server에 각각 A라는 클래스를 정의하여 사용하나요?만약, 맞다면 DTO 관리는 어떻게 하는지 궁금합니다! (이원화 등 다양한 문제가 있을 것 같습니다!)짚선생한테 물어보니깐 이런 경우 공통 모듈을 사용한다는데 이 방식에 단점이 있는지 궁금합니다!

wharup · Accepted Answer

MSA에서 서비스는 분리하는 목적은 독립적으로 변경하고 배포하는 것입니다. 그래서 서비스가 API나 이벤트를 변경할 때도 다른 서비스와 함께 변경할 필요 없어야 합니다.그래서 [1] 각각 DTO를 정의합니다.[2] 변경할 땐 기능을 제공하는 서비스는 하위 호환성을 유지하면서 변경하고, 기능을 사용하는 서비스는 자신이 사용하지 않는 변경은 무시합니다(Tolerant Reader Pattern).[3] 공통 모듈을 라이브러리로 제공하면, 각 개발팀이 독립적으로 배포하는 체계에 잘 안맞고 결국 라이브러리 버전이 파편화될 수 있습니다. 모든 개발팀이 각자 알아서 배포하는데, 라이브러리가 배포되었으니 같은 타이밍에 배포하려고 일정 조율하는게 어색합니다. 그래고 각 개발팀은 뭔지도 모르는 변경 내역을 업데이트하려고 관련 기능을 검증하고 배포하는게 꺼려지는 거지요. 그러다 보면 라이브러리 배포를 미루게 되어 여러 버전이 공존할 수 있습니다.

ㅇㅈㅇ · Answer

API로 받나 MQ로 받나 연동규격 관점에서는 다를게 없죠.걍 API 정의보고 호출하는 거랑 똑같은거고 객체를 공유할 이유가 없습니다.MSA는 기본적으로 다른 서비스라고 인식해야 해요. 불가피한 경우를 제외하면 타사 서비스 연동하듯이 접근해야합니다.

siva6 · Answer

상황에 따라 다르기는 합니다.DTO를 직접 공유하는 방법은 잘 안쓰기는 하지만, 두개의 서비스가 한팀 또는 작게는 한 사람이 관리한다면공통 모듈로 만들어서 사용하기도 힙니다. 배포도 동시에 하구요.api공유처럼 객체자체 정의가 아니라 요청/응답에 대한 정의만 내립니다.요즘은 보통 json으로 응답을 정의하고, 데이터가 필요한 쪽에서 알아서 사용하는 거죠.제공하는 쪽에서 최대한 하위 호환성을 유지해줘야 합니다.좀 더 우아한 방식은 protobuf를 사용하는 건데, 내부적인 version관리까지 사용한다면 이슈가 많이 줄죠.물론 관리 포인트가 늘어나기는 합니다.

현업에선 MSA 환경에서 DTO 관리를 어떻게 하나요?

3개의 답변

Q&A 목록