마이크로 서비스 아키텍처에서 엔티티 중복 문제를 어떻게 해결하나요?

Question

안녕하세요. MSA를 공부 중인 학생입니다.현재 MSA 서적을 한 권 읽었고, 이를 바탕으로 MSA 기반 채팅 서버를 구축 중입니다.그런데 개발 도중에 궁금한 점이 생기더라고요.여러 개의 도메인을 여러 개의 서버(서비스)로 분리하면서 하나의 데이터베이스에 여러 개의 서버가 접근 해야 되는 상황이 종종 생기는데 이를 실무에서는 어떻게 대처하는지 궁금합니다.조금 더 설명을 추가하자면, 채팅 서버에서도 User 테이블을 가져와야 되고, 유저 서버에서도 User 테이블을 가져와야 되는 상황이 생겼습니다. 저는 JPA를 사용해서 데이터베이스의 테이블과 연결을 하니까 User Entity 클래스를 채팅 서버, 유저 서버에 작성을 했습니다. 그런데, 이런 식으로 할 경우 채팅 서버와 유저 서버에 중복된 코드가 발생할 것이고, 서로에게 원하지 않는 데이터 업데이트가 발생하거나 나중에 수정할 부분이 생길 경우 유지 보수 하기가 어려울 것 같다는 생각이 들었습니다.인터넷을 조금 찾아보니까 각 서버에 맞게 엔티티 클래스를 작성해서 관리한다고 하던데... 실무에서는 어떻게 대처하는지 궁금합니다. 아니면 설계 단계에서 최대한 중복이 안되도록 설계를 진행할까요...?

KrongDev · Accepted Answer

채팅 서버에서 실제로 필요한 User 정보가 어떤 범위인지가 중요할거 같다 생각이 듭니다.User 테이블을 별도로 두 개 만들어 관리하는 방식은, 시간이 지날수록 데이터 정합성 문제가 발생할 가능성이 크고,동일한 테이블을 각 서버에서 사용하는 것은 코드 레벨의 정합성도 요구한다 생각합니다.간단하게 해결할만한 방법은 core 모듈을 두고, 해당 모듈에서 User Entity를 관리하는 방법이 가장 간단할 거 같고,채팅 서버에서 단순히 사용자 식별 정보나 표시용 정보가 필요하다면, User 서버를 호출하여 필요한 데이터를 조회하는 방식을 권장하고 싶습니다. 만약, 채팅 서버에서 User테이블과의 Join이 필요한 상황이거나 성능상 로컬 데이터가 필요한 상황이라면, 채팅 서버 전용 User테이블을 관리하는 방법을 고려해볼 수 있을 거 같네요.이 경우 데이터 정합성 문제가 발생할 텐데, Kafka와 같은 이벤트 스트리밍 플랫폼을 활용하여 비동기적으로 동기화하는 방법을 적용한다면 추후 유지 보수에 큰 어려움이 없을 것 같습니다.

kenu,전독시 · Answer

저는 실무로 MSA를 다뤄 본 적은 없지만,하나의 데이터베이스에 여러 개의 서버가 접근 <-- 이거 bottle neck(병목)입니다.MSA가 가장 피해야 할 안티패턴이죠.상식적으로는 각 모듈별로 Cache DB를 가지고 운영한다고 배웠습니다.이런 구조입니다.

캐티 · Answer

솔 .. 이거는 관계형 데이터베이스에서 유연한 대처가 안되겠쩌. ai는 하는 수 없는 중복이라고 하였쩌. 유저에 닉네임이 변경되었다 이럼 여럿 서버에 업데이트를 쳐야 하는데 이럼 망하는 거는 아니고 .. 싫어하겠쩌. 일반적으로 실무에서는 그냥 하라는 대로 되는 대로 치는 거여요.이런 거는 데이터베이스보다 파일 시스템에서 쳐야 긍정에 여지가 많아져요. 파일시스템은 예로 아이디.txt 내용 안에 닉네임을 두어도 되어요.Storage area network - Wikipedia돈이 많이 깨집니다. 내가 수상한 정도로 돈이 많은 개발 회사이다 이럼 괜찮은 선택이 되는 여지가 있는데 .. 굳이.아이 .. 이만큼 초거대 서비스를 만들거 아니지 않았나요. 대부분에 경우로 트래픽으로 과부하가 나는 서비스는 드물을 거이고 애당초 이즈음 왔으면 떼돈 방석에 올라야 하는 거여요. 서버 하나에 그저 그런 모델로 하여도 문제가 없을 거여요.

집킨 · Answer

채팅 서버가 유저 DB를 쓰는게 문제입니다유저에 대한 연산이 필요하면 유저 서버에 요청해야죠

xml개발자 · Answer

으음.. 고민을 해본적이 없네요..요즘 DB스펙이 엄청 좋아요.. 클라우드에서는 상상 이상으로 쉽게 확장도 가능합니다.으음... 만약 그렇다면, 업무에 따라서 DB서버를 분리할 것 같아요.유저정보 DB서버, 채팅내용 DB서버 따로따로

흐음흐음 · Answer

모노레포 모듈로 따로빼서 관리합니다.

MuDaeng · Answer

msa해본사람으로 db는 서로 분리해놓고 (논리적분리는 뷰테이블, 물리적분리는 카프카)유저서버 db의 유저테이블에서 수정하고 카프카로 수정사항을 전파하거나 view테이블로 전파함타 서버에서는 읽기만하고 수정해야 할때는 그 서버에서 직접 디비를 수정하는게 아니라 유저서버 동기api를 사용하거나 카프카 이벤트로 유저서버에 요청해야됨

siva6 · Answer

MSA에서 중복은 어쩔 수 없습니다.질문하신 User Entity만 본다면 User에는 모든 사용자 정보를 나타내는 Entity가 필요할테구요.채팅에서는 id와 nickname정도만 있는 Entity가 존재하면 되지 않을까요?데이터 중복이 더 문제인데, API를 콜하지만 캐시를 만들어 콜 수를 줄이거나 MQ나 DB replica를 사용하는 등의 데이터 복제가 필요할 수 도 있습니다.

zoony · Answer

멀티 모듈로 구조 잡아도 됩니다.repo를 모노로 가져가야 하는 단점이 있지만 질문과 같은 중복을 어느정도 대처할 수 있습니다core-module : 공통으로 사용하는 db 관련 코드들api-module, chatting-module : 빌드할때 core-module을 같이 빌드합니다.msa를 지향하신다하면user를 메인으로 다루는 서비스에서 내부 api를 만들고 chatting 서비스에서 호출해서 써도 됩니다.모든 개별 서비스가 gateway를 통해서 들어온다면gateway에서 특정서비스로 갈때 user정보를 실어서 줘도 됩니다.대부분의 하위 서비스에서는 현재 로그인한 유저 정보가 필요할테니깐요

마이크로 서비스 아키텍처에서 엔티티 중복 문제를 어떻게 해결하나요?

9개의 답변

#jpa 목록