인프런 커뮤니티 질문&답변
작성한 질문수
Orchestration SAGA 패턴 보상에 대한 질문입니다.
해결된 질문
작성
·
35
0
Orchestration SAGA 패턴 구현에 대해 고민하다가 질문이 생겨 남깁니다.
보상을 요청하는 메서드가 명시적으로 나와있어 호출할 때(동기로 호출)
만약 rollback을 요청하는 호출이 실패하게 된다면 이후의 순서대로 service에 보상 요청을 하는 동작을 멈춰야 할지 계속 진행하는 게 바람직할지 고민이 됩니다.
예를 들어 서비스 1,2,3,4가 있고 center server가 orchestration 관리를 하고 1,2,3,4 순서대로 서비스 호출해서 관리를 진행한다고 했을 때 3에서 장애가 발생해서 2를 롤백하던 중 2 롤백에서 예외가 발생해서 롤백에 실패한 경우 orchestration에서 1에 대한 롤백을 진행해줘야 할지 아니면 일단 멈춰야 할지 고민입니다.
고민의 이유는
순서대로 롤백을 해주는 것은 앞에 작업이 뒤의 작업에 의존성이 있을 때만 그렇게 해주면 되나에 대한 고민이 있었습니다. 두 롤백 간에 데이터 의존성이 없다면 괜찮지 않을까 고민했습니다.
다음으로 일단 1도 롤백을 한다면 어디서부터 어디까지 롤백이 진행됐는지 추적이 어려워지지 않을까 고민했습니다. 롤백을 어떤 것은 해주고 어떤 것은 안해준다면 어디까지 롤백했는지 추적이 힘들어지지 않을까 생각이 들었습니다.
답변 2
0
안녕하세요 won님 답변이 늦어서 죄송합니다. 개인적으로 이 SAGA 패턴이라는게 저는 막 정해진 방식은 없다고 생각을 해요. 상황에 따라 맞춰서 가는게 맞다고 생각은 합니다.
하지만 그래도 표준에 대한 기준으로 잡아보자면, 저는 계속 진행하면서 각 보상 결과를 독립적으로 추적하는 구조가 되어야한다. 라고 말할 수 있을꺼같아요.
왜냐하면 가정을 해주신 2번 롤백이 실패했다는 상황이 사실상 1번 자체를 시도조차 하지 않는다는건 좀 다른 문제입니다. 상태 자체가 다르다고 느껴져요.
명시적으로 우리가 잘못되었다고 1번 서비스는 롤백 시도도 안한다는게 일단 의도적으로 우리가 이걸 방치한다는 관점이기 떄문입니다. 최소한 시도를 해야 이걸 시도했는지 시도를 하지 않았는지 히스토리에 남아있는다는 관점도 있기 떄문이에요.
이 SAGA라는것의 최종적인 목적이 결국 시스템이 일관된 상태를 유지한다. 가 기본적인 목표입니다. 그래서 1번은 독립적으로 실행되어야 해요.
의존성관점에서도 이 틀은 벗어나지 않습니다. SAGA에서 의존성이라는 관점은 단순하게 롤백 순서를 지켜야한다. 정도의 관점이지 이걸 롤백을 건너 뛰어도 된다 까지는 다루지 않는게 맞는거 같아요.
추적 관점은 보통은 우리가 상태 추적을 위한 step을 독립적으로 관리하시는게 편하실겁니다.
예를들어 음.. 예시적인 코드로 표현하자면 이런 형태가 될꺼같아요.
saga_instance
saga_id, status (COMPENSATING | COMPENSATION_FAILED | COMPLETED)
이렇게 status를 스탭마다 두어서 관리를 하는거죠. 이러한 관점에서 WAL 이라는 패턴도 한번 적용해보시면 도움이 되실꺼같아요.
혹시라도 추가적인 질문이 있다면 남겨주세요 좋은 질문 남겨주셔서 감사합니다!
맞아요 딥하게 들어간다면 그런 고민까지 하실 수 있습니다. 그래서 보통은 보상을 위한 재시도 메커니즘을 많이 도입해요.
말씀해주신 부분처럼 Outbox + CDC 패턴도 가능하겠죠, 이것도 결국은 나중에 다시 시도할 수 있도록 우리가 실패한 상태를 기록하자 라는게 목표인거고요.
사실 일반적으로 WAL 패턴을 매우 잘 구현하셔서 상태를 잘 관리하시면 거의 모든 상황에 대해서는 해결이 가능합니다. 그래서 저라면 일단 그냥 WAL 방식을 되게 짜임새 있게 잘 구현을 할꺼같아요.
예를들면 A 서비스 호출에 대해서도 A 서비스 호출 전 상태 -> 서비스 호출 시도 -> 서비스 호출 성공 및 실패
그 이후에 성공 및 실패케이스에 대해서 따로 백그라운드에서 Loop 돌며 후속처리
이런 형태가 가장 일반적으로 볼 수 있는 형태가 되겠죠. 이렇게 복잡하게 구현이 되는 이유가 사실상 이 SAGA라는게 기본적으로 복잡하기 떄문이에요. 어쩔 수 없는 트레이드 오프입니다.
말씀해주신 부분처럼 근데 Kafka와 같이 전송하셔도 됩니다. 앞서 말씀드린 방식은 DB에 대한 부하가 좀 더 발생 할 수 있는 케이스겠고 트래픽이 너무 많다면 Kafka같이 외부 서비스를 태워서 처리해야하는 방식을 택해야하죠.
혹시 이정도로 답변 드릴 수 있을꺼 같은데 이해가 되셨을까요??
0
안녕하세요, 인프런 AI 인턴입니다. won님.
Orchestration SAGA 패턴에서 롤백(보상 트랜잭션)에 대한 고민을 하신 점에 대해 설명드리겠습니다. 이는 매우 중요한 주제로, 각 서비스의 롤백 및 보상 처리가 제대로 관리되지 않으면 데이터 일관성이 깨질 수 있습니다.
롤백 순서와 의존성:
- 의존성이 없는 경우: 롤백 순서가 중요하지 않다면 병렬이나 비순차적으로 롤백을 진행할 수 있습니다. 만약 서비스 간에 데이터 의존성이 없다면 개별적으로 롤백이 되어도 무방합니다.
- 의존성이 있는 경우: 의존성이 있는 경우, 특히 앞 서비스의 상태가 뒷 서비스의 동작에 영향을 끼친다면, 반드시 순서대로 롤백이 이루어져야 합니다.
- 의존성이 없는 경우: 롤백 순서가 중요하지 않다면 병렬이나 비순차적으로 롤백을 진행할 수 있습니다. 만약 서비스 간에 데이터 의존성이 없다면 개별적으로 롤백이 되어도 무방합니다.
롤백 추적:
- 모든 서비스에 대한 롤백 상태를 중앙화하여 추적하는 것이 중요합니다. 이는 로그 시스템 혹은 상태 저장소를 사용하여 각 서비스의 롤백 상태를 기록하고 모니터링할 수 있습니다.
- 롤백이 실패할 경우, 별도의 에러 처리로 롤백 상태를 고려한 이후 절차를 수행해야 합니다.
- 모든 서비스에 대한 롤백 상태를 중앙화하여 추적하는 것이 중요합니다. 이는 로그 시스템 혹은 상태 저장소를 사용하여 각 서비스의 롤백 상태를 기록하고 모니터링할 수 있습니다.
정지와 지속성:
- 에러 발생 시 롤백이 진행되지 않은 서비스들에 대한 롤백을 멈추어야 하는지의 여부는 데이터 무결성과 사용자 경험 측면에서 결정하십시오. 만약 상태 불일치가 클 수 있다면 전체 중단 후 수동 조치를 고려해 볼 수 있습니다.
- 지속적인 에러 체크와 알림 시스템을 통해 빠르게 오류를 대응할 수 있는 체계를 갖추는 것이 중요합니다.
- 에러 발생 시 롤백이 진행되지 않은 서비스들에 대한 롤백을 멈추어야 하는지의 여부는 데이터 무결성과 사용자 경험 측면에서 결정하십시오. 만약 상태 불일치가 클 수 있다면 전체 중단 후 수동 조치를 고려해 볼 수 있습니다.
이와 유사한 주제를 다룬 질문들을 참고해보시면 도움이 될 수 있습니다:
해당 링크에서는 트랜잭션 보장에 대한 다양한 접근 방식을 논의하고 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사합니다! 이전에도 비슷하게 status를 저장하는 방법을 떠올리긴 했었는데 좀 더 고도화할 수 있는 방안을 떠올린 것 같아요.
다만 이 단계에서 한 가지 더 질문이 있습니다.
WAL 패턴은 어디까지 진행했는지 상태를 로그처럼 쌓는 걸로 이해했는데 결국 서버가 정상적으로 돌아가고 보상을 제대로 다 진행해주기 위해서는 WAL 패턴으로 실패한 보상 상태를 저장한 대상들에 대한 추후 보상이 이뤄져야 한다고 보는데 여러 개 서치할 수록 오히려 애매한 지식만 들어와 더 혼동이 오는 것 같아 Hong 님의 의견을 들어보고 싶습니다!
outbox로 저장해놓고 CDC 로 읽어서 kafka에 발행하는 방식도 있고
Toss slash 발표를 보니 Kafka 관련된 서버를 여러 개 두고 장애가 난 Consumer 서버가 회복할 때까지 기다리고, Batch를 이용해 정합성 등을 확인하는 방법도 있는 것으로 보입니다.
물론 이런 것들도 상황과 사용할 수 있는 인프라 자원에 따라 다르겠지만
최초 saga 트랜잭션 안의 서비스 호출이나 이벤트 발행이 실패한다는 것은 그것을 받아주는 서버의 장애로 인해 보상 트랜잭션이 제대로 작동안 할 가능성이 크다는 생각이 들어 이렇게 보상이 실패한 경우의 최종 결과적 정합성을 맞춰주는 부분에 대한 Hong님의 생각이나 경험이 궁금해서 남겨봤습니다.