Transactional Sagas - 1부 종류와 단점
saga pattern 의 종류
Pattern name | Communication | Consistency | Coordination |
Epic Saga(sao) | Synchronous | Atomic | Orchestrated |
Phone Tag Saga(sac) | Synchronous | Atomic | Choreographed |
Fairy Tale Saga(seo) | Synchronous | Eventual | Orchestrated |
Time Travel Saga(sec) | Synchronous | Eventual | Choreographed |
Fantasy Fiction Saga(aao) | Asynchronous | Atomic | Orchestrated |
Horror Story(aac) | Asynchronous | Atomic | Choreographed |
Parallel Saga(aeo) | Asynchronous | Eventual | Orchestrated |
Anthology Saga(aec) | Asynchronous | Eventual | Choreographed |
출처 : Software Architecture: The Hard Parts, October 2021
Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
비동기를 잘 모르던 시절에는 Epic Saga(sao) , Phone Tag Saga(sac) 정도였다.
MSA한다고 공부하고
이전에 알고 있던 네트워크 지식으로 홉수 줄이겠다고 하다보면 대충 이런 아키가 나온다.
에픽, 폰태그 둘은 동기 기반이고
대용량에서는 병목 & 성능저하가 나옵니다.
그러다 대용량 트레픽을 취급 하면서 비동기가 뭔가 멋있어보였다. 병목이 사라진다.
나는 이벤트 드리븐이다!! 하면서 kafka 도입하고 나는 메시지를 생산(produce) 할태니 필요한 도메인에서 컨슘 해가세요!!
카프카 만세!
뭔가 심플하고 멋있다. (추가로 데이터가 있네 없네 제로 페이로드 + 그래프ql 도 도입하기도 한다)
하지만 사실은 이런 풀어서 보면 이 그림 아닌가? Asynchronous, Atomic, Choreographed
중간에 누가 잘못되어도 알수 없는..
이름도 호러스토리다...
장애 한번 나면 처음 도메인 부터 가장 마직막 팀까지 전부 호출당해서 나는 정상이다 너는 정상이니? 일일이 물어서 어디서 문제가 생겼는지 찾는다.
Domain-driven design + 비동기 하면서 신나게 달리면
정신차리고 보면 대충 이런 모양이 된다. 그리고 생각한다 이게 맞나...?
버너 보겔스는 자신의 트위터 계정을 통해 2008년 아마존닷컴의 마이크로서비스간 종속성을 나타낸 그래프를 이미지로 공개했다.
아마도 자랑(?)이였겠지
혼란한데...
그럼 어쩌라고??
Software Architecture: The Hard Parts에서는 Parallel Saga(aeo) 가 좋다고 한다.
이유는 다음에..
출처 : Software Architecture: The Hard Parts, October 2021