개발자

데이터 composition 위치에 대한 문의

2023년 04월 07일조회 138

안녕하세요. 백엔드 개발하던 중에 질문이 생겨서 올립니다. 페이지에 보여줄 데이터를 가져오는 작업을 하고 있는데, 데이터가 여러 마이크로서비스에 흩어져있다보니까 게이트웨이 성 서버에서 호출한 데이터를 취합해주고 있습니다. 예시를 들자면, 혼합 데이터 A는 데이터 A, B, C의 조합이라고 생각했을때, 게이트웨이에서 데이터 A, B, C를 각각의 마이크로서비스를 호출한후 혼합 데이터 A를 만들어서 클라이언트에 보내주고 있어요. 근데 이게 맞는 방법인지는 잘모르겠습니다. 보통 이렇게 DB 레벨에서 JOIN을 못 해줄경우, 데이터 취합은 어떻게 할 수 있나요? 제가 생각했던 다른 방식은 데이터 A, B, C를 각각 클라이언트에서 마이크로서비스로 요청을 해서 가져오는 것 정도였습니다. 이렇게 생각한 이유는 전자의 방식은 게이트웨이가 다운되면 모든 데이터를 못보지만, 후자의 경우는 하나의 마이크로서비스가 다운되어도 일부 데이터를 볼 수 있겠다 싶었어요. ex. 데이터 A의 마이크로서비스가 다운되어도, 데이터 B, C는 불러올 수 있음.

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.
profile picture
익명님의 질문

답변 3

인기 답변

이양일님의 프로필 사진

안녕하세요! 마이크로서비스 아키텍쳐와 같이 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

손정현님의 프로필 사진

안녕하세요! 개인적으로 질문하신 내용은 정답이 없다고 생각합니다. 서비스마다 각자 구현하기 나름이고 각 방법에 장단점이 있는 것 같아요. 우선 서비스가 잘게 쪼개져 DB 레벨에서 JOIN을 못해주는거는 생각보다 흔한 경우인것 같아요. 데이터를 취합해야한다면 1. 코드 레벨에서 각각의 서비스를 요청해서 취합하거나 2. 미리 취합된 데이터를 저장해놓고 그걸 조회하는 방식 정도를 본 것 같아요. 물론, 질문자님이 말씀하신 방법도 가능은 하지만 보안적인 이슈로 백엔드 구성을 클라이언트에 노출하지 못할 수도 있어서 경우에 따라 다를 것 같습니다 :)

커리어리 AI 봇님의 프로필 사진

데이터를 마이크로서비스로 분리하고 각각 호출하는 것은 마이크로서비스 아키텍처의 핵심 개념 중 하나입니다. 그러나 모든 데이터를 하나의 마이크로서비스에서 가져오는 방식도 적절한 경우가 있습니다. 우선 게이트웨이에서 데이터를 취합하고 클라이언트에게 보내주는 방식은 일반적인 경우입니다. 이는 서비스마다 데이터 소스가 다른 경우나 데이터 소스가 느리거나 비용이 많이 드는 경우, 그리고 데이터를 미리 조합하여 클라이언트에게 보내는 것이 더 나은 성능을 제공하는 경우에 사용될 수 있습니다. 하지만 데이터 A, B, C를 각각의 마이크로서비스에서 가져오는 방식도 적절한 경우가 있습니다. 예를 들어, 서로 다른 마이크로서비스에서 가져온 데이터를 비교하고 조합해야 하는 경우에는 각각의 서비스에서 데이터를 가져와서 클라이언트에서 조합하는 것이 더 나은 성능을 제공할 수 있습니다. 또한, 하나의 마이크로서비스가 다운될 때 일부 데이터만 유효한 경우, 각각의 마이크로서비스에서 데이터를 가져와 클라이언트에서 취합하는 것이 더 좋을 수 있습니다. 마이크로서비스 아키텍처에서 데이터를 가져오는 방식은 상황에 따라 다릅니다. 데이터 소스와 데이터 양, 그리고 성능 요구사항을 고려하여 적절한 방식을 선택해야 합니다. ----- ✅ Chat GPT의 답변을 평가해 주세요! 틀린 내용은 없는지, 답변이 도움이 되었는지 댓글로 작성해 주세요.

커리어리 AI 봇의 답변을 평가해 주세요!

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

목록으로
키워드로 질문 모아보기

실무, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!