강의

멘토링

커뮤니티

인프런 커뮤니티 질문&답변

swm.3idiots님의 프로필 이미지
swm.3idiots

작성한 질문수

카카오 면접관이 알려주는 MSA 관점에서의 분산 트랜잭션 패턴

중간 단계의 처리를 수행하는 두번쨰 애플리케이션

23강 예제 질문입니다! (서비스 1 > 2 > 3 호출 시나리오 관련)

해결된 질문

작성

·

22

0

image.png

 

안녕하세요!

기존에 설명해주신 Orchestration 예제의 다이어그램과 호출 순서가 실습 코드랑 다른 것 같아서 질문드립니다.

 

다이어그램 : 오케스트레이터가 모두 요청/응답 받는 구조. 오케스트레이터 -> 2번 호출/응답 -> 오케스트레이터가 다시 3번 호출/응답

 

실습코드 : 오케스트레이터가 2번 서비스를 호출하고 2번 서비스가 3번 서비스를 호출하는 형태

 

질문 1)

위 2개의 내용이 다른 이유가 있을까요? + 오케스트레이션 패턴은 오케스트레이터가 모든 서비스를 호출하고, 다른 서비스는 오케스트레이터에 답변만 해주는 구조이고, 이 때문에 오케스트레이터가 SPOF가 될 수 있다고 이해했는데, 제가 잘못 이해한걸까요?

 

질문 2)

지금 예제에서는 REST API를 쓰는지, kafka 이벤트는 쓰는 여부 말고는 오케스트레이션/코레오그래피 모두 서비스 1 -> 2 -> 3 호출 하는 시나리오와 보상 처리를 하는 방법이 크게 차이가 없는 것 같습니다 (DLQ외) 예제를 보니까 헷갈리게 되는 것 같은데 제가 어떻게 이해하면 좋을까요?

 

감사합니다!

답변 2

0

Hong님의 프로필 이미지
Hong
지식공유자

안녕하세요 swm.3idiots님 질문 남겨주셔서 감사합니다.

 

질문 1)

수업 자료가 많다보니 관리가 일부 미흡한 부분이 있는거 같네요. 기본적인 기준은 질문자님이 주신 부분이 맞습니다. SPOF라는 관점이 틀린건 아니에요.

 

근데 저희가 정의대로 구현하는 케이스가 생각보다 많이 없습니다. 상황에 따라서 이 방식이 더 효과적이면 정의에서 좀 벗어난 방식을 적용하는 경우들이 많아요. 그만큼 실무는 많이 다르기 떄문입니다.

 

그래서 어느정도 실무에서 쓰는 가장 일반적인 패턴을 좀 보여드린거 같습니다. 생각보다 오케스트레이션이라는 패턴이 하나의 서비스에서 모두 관리하는 케이스는 많이 보지 못한거같아요.

  • 물론 그런 케이스가 나쁘다는건 아닙니다.

 

그래서 정의대로라면 SPOF의 관점이 맞지만, 현실적으로는 저런식으로 구현을 많이 한다고 너그롭게 봐주시면 감사하겠습니다.

 

질문 2)

맞아요. 기본적으로 목표하는바는 똑같습니다. 시나리오나 보상처리 시스템이 달라지면 안되기 떄문이에요.

 

단지 이 두 패턴의 차이는 어떻게 호출이되고 굴러가냐의 차이인거지 당연하게도 기본적으로 보장해줘야하는것들은 보장해줘야합니다. 특정 패턴이라고 이 방식은 도입하지 않아도 된다가 아닙니다.

 

결국 우리가 A라는 기능을 구현할 떄, 어떤 방식으로 A라는 기능을 구현하는것이 중요한지라는 방식으로 이해하시면 좋을꺼같아요.

 

단순하게 DB에서 데이터를 가져와서 뿌려주는 방식도 있을거고, 아니면 트래픽 특성을 고려해서 데이터를 미리 캐싱 처리 할 수 있는 방식도 있겠죠.

 

이와 같은겁니다. 기능을 구현하는데에 있어서 어떤 방식으로 내가 구현을 하는게 좋을지가 중요한거고, 이 SAGA라는 패턴에서도 이 두가지 패턴들을 대중적으로 사용해서 구현을 하는거라고 봐주시면 되는겁니다.

 

감사합니다.

0

안녕하세요, 인프런 AI 인턴입니다. swm.3idiots님.

질문해 주신 내용은 MSA의 오케스트레이션 패턴의 구현 방식과 각 서비스 간의 상호작용에 대한 중요한 고찰입니다. 이를 통해 오케스트레이션과 코레오그래피 패턴의 차이점에 대해 명확히 이해할 수 있습니다.

질문 1: 오케스트레이션 패턴의 구조와 차이 이유

오케스트레이션 패턴의 핵심은 중앙 컨트롤러(오케스트레이터)가 모든 서비스 간의 상호작용을 관리한다는 것입니다. 실습 코드에서 서비스 2가 서비스 3을 호출하게 된 이유는 특정 비즈니스 로직 또는 성능 최적화 때문일 수 있습니다.

이해 포인트:
- 오케스트레이터의 역할: 중앙에서 모든 요청/응답을 조율합니다. 이는 SPOF(단일 장애점) 문제가 발생할 수 있으므로, 분산 처리나 디커플링(Decoupling)을 통해 이를 보완할 수 있습니다.
- 다이어그램과 코드의 차이 이유: 실습에서는 좀 더 단순하게 서비스 간의 직접 호출을 통해 이해하기 쉽게 구현했을 수 있습니다. 이 경우 각각의 서비스가 어느 정도 자율성을 갖도록 만들거나, 실제 구조에 맞춰 최적화했다는 점을 참고하세요.

질문 2: 오케스트레이션 vs. 코레오그래피 차이

오케스트레이션과 코레오그래피 둘 다 분산 시스템에서 사용하는 패턴으로, 각기 다른 방식으로 트랜잭션과 비즈니스 로직을 관리합니다.

오케스트레이션:
- 중앙 집중형 컨트롤러: 중앙에서 모든 워크플로우를 관리하고, 트랜잭션 흐름을 통제합니다.
- SPOF 가능성: 오케스트레이터가 장애를 일으킬 경우 전체 시스템에 영향을 미칠 수 있습니다.

코레오그래피:
- 이벤트 기반 상호작용: 서비스들이 이벤트를 통해 서로를 구독하고, 독립적으로 자기 할 일을 수행합니다.
- 자율성 증가: 각 서비스가 독립적으로 운영되어 확장과 변화에 유연합니다.

REST API vs. Kafka:
- REST API는 주로 동기식 통신, 즉각적인 응답 확인에 적합하며, API 설계에 따라 복잡하거나 단순해질 수 있습니다.
- Kafka 같은 이벤트 시스템은 비동기적이고 확장성이 뛰어납니다. 이벤트 기반으로 서비스 간 결합도를 줄일 수 있습니다.

모든 패턴은 각각의 요구사항과 상황에 맞게 조합되어 사용될 수 있다는 점을 고려하세요. 각각의 방식이 사용하는 트랜잭션 처리와 보상 로직이 시스템 설계 및 요구사항에 따라 달라질 수 있습니다.

추가 참고

유사한 주제에 대한 논의는 다음의 유사한 질문 링크에서 확인하실 수 있습니다:

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.

현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

swm.3idiots님의 프로필 이미지
swm.3idiots

작성한 질문수

질문하기