안녕하세요! 마이크로서비스 아키텍쳐와 같이 DB join 을 하기 힘든 케이스에 대해 저는 다음과 같은 경험을 해보았었습니다. 1️⃣ 각 마이크로 서비스별로 데이터 변경이 발생할때마다 전파하여

안녕하세요! 마이크로서비스 아키텍쳐와 같이 DB join 을 하기 힘든 케이스에 대해 저는 다음과 같은 경험을 해보았었습니다. 1️⃣ 각 마이크로 서비스별로 데이터 변경이 발생할때마다 전파하여 필요한 데이터를 맞춰준다. 이 방식으로 하면 프론트 혹은 API Gateway 레벨에서 취합을 하지않아도 되고 취합된 데이터를 관리하고 있는 서비스만 요청하면 되는 장점이 있습니다만, 전파를 하기 위한 데이터 파이프라인을 구축 해야하고 데이터 sync 에 대한 안정성 및 실시간 처리를 위한 고민, 데이터 복제에 필요한 스토리지 비용 등이 추가로 들어간다는 단점이 있어 자칫 배보다 배꼽이 커질 수 있습니다. 또한 데이터 파이프라인을 어떻게 구축하느냐에 따라 실시간으로 처리가 되지 못하기 때문에 이부분도 잘 고려하여 선택해야 합니다. 2️⃣ API Gateway 에서 취합하기 위에서 설명드린 1안에 비해 비용이 적게 들어간다는 장점이 있고, GraphQL 을 사용할 경우 Client 한테 좀 더 효율적인 API 제공이 가능합니다. 다만 우려하신것처럼 특정 마이크로서비스에 장애가 발생할 경우 다른 서비스의 데이터도 못받기 때문에 이를 극복하기 위해 API Gateway 단에서 특정 마이크로 서비스의 데이터 조회 실패에 대한 fail over 고민이 추가로 필요합니다. 3️⃣ 프론트에서 취합하기 백엔드 입장에서는 자신의 서비스에 맞는 API 만 제공하면 되는거라 편하지만 프론트엔드에서는 백엔드가 편해지는 만큼 유지보수 비용이 증가하게 됩니다. 또한 API 를 요청하는 client 나 요청해야할 마이크로 서비스의 종류가 많을 경우(웹, 모바일 앱, Open API 등등..) 각 클라이언트별로 취합에 관련된 코드를 동일하게 가져가야하므로 유지보수 비용이 그만큼 배로 들어가게 됩니다. 대신 장점으로는 질문자님께서 말씀하셨던 특정 서비스에 대한 장애를 우회할 수 있는 전략을 프론트단에서 가져갈 수 있습니다. 1안의 경우 동일한 데이터를 조회하는 화면이 많고 데이터가 캐쉬 성격의 데이터이거나 조회해야 할 마이크로 서비스가 다양할 경우 선택하면 좋으실듯 합니다. 2안과 3안은 장단점이 trade off 관계라서 클라이언트 종류나 마이크로 서비스가 확장될 수 있는 서비스라면 2안으로 가는게 좀더 효율적일듯 하고요, 그게 아니라면 2안과 3안 중 적절한 방향으로 선택하시면 좋지 않을까 싶습니다. 2안으로 가셨을 경우 선택해볼 수 있는 옵션중 하나가 GraphQL 일텐데요 이와 관련된 내용도 참고하실 수 있게 추가로 공유드립니다. - https://careerly.co.kr/comments/79890?utm_campaign=self-share