MSA와 사가 패턴을 찾아보면서 궁금했던 부분이 있어서 질문 남겨봅니다.

모든 자료가 그런 것은 아니지만 많은 MSA 관련 자료가 EDA (Event-Driven Architecture)를 이야기하고 있고, 카프카를 도입하면서 느슨하게 연결되어있고 원하는 메시지만 수신할 수 있도록 하는 구조로 설명을 하는 것 같습니다. (메시지 큐를 도입했을 때의 문제점에 대한 이야기는 별로 없고, 그 이상의 무언가를 찾거나 노하우를 구하기 쉽지 않은 듯 하네요.)

디커플링 자체는 상당히 좋은 장점 중 하나이지만, 개별 시스템으로 분리되면서 트랜잭션 관련해서도 고민이 많이 필요하고 연결하는 고리가 많아지는 만큼 신경써야 할 부분도 많을 것으로 보입니다.

그래서 들었던 질문이 몇 가지 있는데 마땅히 답을 구할만한 곳이 없었는데 이 쪽에서 관련된 질문에 답을 해주실 것 같아 달아봅니다.

1. 이벤트 소싱에 대해 맞게 이해한 것인지 ?

우선 이벤트 소싱이 CQRS, 비동기 처리와 많이 엮여서 나오는 주제이긴 하지만 이벤트 소싱 자체만을 두고 봤을 때에는

1) 이벤트의 모든 이력을 남기고
2) 핸들러가 이를 처리하는 것이 전부

라고 이해해도 될까요 ?

CQRS는 표면적으로는 변경과 질의를 분리하는 개념이지만, 이벤트 기록을 모두 재생해서 조회하는 것이 어려워서 질의와 변경을 분리하는 아이디어 때문에 이벤트 소싱에서 함께 언급되는 패턴으로 이해했고, 비동기 처리는 이벤트 소싱이 비동기 처리를 편하게 할 수 있는 환경 정도로만 이해했습니다.

제가 이해한게 맞는지 모르겠어서 잘 이해했는지 질문을 드리고 싶구요 ㅎㅎ

2. 짧은 시간 안에 처리되어야 하는 API도 MSA에 적합한가 ?

위에 제가 이해한 것이 맞다는 가정하에 말씀드리는 거긴 한데요. 예를 들면 만약에 OTT에서의 유료 영상 결제, 문서 파일 결제, 웹툰 등에서 결제하자마자 결과를 검증하고 사용해야 하는 과업이 있고, 이 과업을 단일 API로 처리하던 것을 MSA로 전환할 경우에

1) API, gRPC 등 네트워크 통신을 사용하는 MSA의 경우 : 코드나 개념적인 분리를 통해 서비스를 작게 쪼갤 수 있는 장점은 있지만 네트워크 이슈, 롤백 등 신경써야 할 문제가 많아진다

2) 카프카 등의 메시지 큐를 통한 MSA일 경우 : 카프카 자체의 문제 혹은 처리하는 개별 마이크로 서비스에 병목이 생기면 처리가 지연되며, 단일 API로 주고받던 경우에는 앱 수정이 불가피하다 (카프카를 사용하면 더더욱 이벤트 소싱을 고려할 수밖에 없고 PENDING 상태가 기존 앱에서 정의되지 않았기 때문에) 는 문제가 있을 것 같습니다.

아무래도 제가 카프카를 넣는 것이 우려가 되는 이유는

1) 각 서비스에서 발행한 카프카 메시지를 어떻게 추적하는지 쉽지 않다고 생각했고,
2) 장애 포인트가 쪼개지는 서비스와 개념적으로 발생하는 연결의 갯수에 비례해서 많아지기 때문이라 생각했고,
3) 또한 카프카를 통해서 처리하는 속도가 API로 처리하는 지금 속도 대비 느리게 세팅된 상태라 과하게 생각하는건가 싶기도 하고,
4) 앱에서 '서버의 아키텍쳐 변경을 위해 생긴 PENDING 상태에 대해 알고 있어야 하는가'에 대해서 고민이 많아서

그런 것 같습니다. 제가 MSA 관련해서는 경험이 없다보니 의견을 좀 들어보고 싶습니다.

3. 보상 트랜잭션과 관련하여

각자의 로컬 트랜잭션만 보장하고 문제가 생기면 그게 반하는 트랜잭션을 새로 발행해서 상태를 상쇄시키는 형식인 것 같습니다.

상태 머신이 명확하게 구분된다면 보상 트랜잭션 구현이 용이하겠지만, 그렇지 않을 경우나 모호한 경우가 있을 것이라 생각됩니다.

또한 보상 트랜잭션이 실패하는 경우 더더욱 현상 파악이 쉽지 않을 것 같기도 하고, 구현하는 서비스마다 제각각이라 노하우를 구하기 쉽지 않을 것으로 보여서 구현 난이도가 꽤 올라갈 것으로 보이는데, 이런 부분을 보완할 수 있는 방법이 있을지 궁금합니다.