Saga 패턴은 되돌릴 수 있는 홈 AI 작업을 어떻게 조율하나요?

사가(saga)는 하나의 워크플로를 순서가 정해진 단계로 나누고, 이후 단계가 실패하면 보상 작업을 실행하여 되돌릴 수 있는 홈 AI 작업을 조정합니다.

이는 에이전트가 하나의 트랜잭션을 공유할 수 없는 여러 독립 서비스에 접근할 때 유용합니다. 워크플로는 진행 상황을 기록하고 실패 지점을 감지한 다음, 되돌릴 수 있는 단계를 의도적으로 원상 복구합니다.

사가는 하나의 홈 작업을 여러 로컬 단계로 나눕니다

사가는 각 단계를 로컬 트랜잭션 또는 부수 효과로 처리하여 여러 독립 시스템에 걸친 워크플로를 조정합니다. 필요한 단계가 모두 완료된 후에야 전체 작업이 성공합니다.

사가 패턴은 메시지 또는 오케스트레이션을 통해 조정되는 로컬 트랜잭션의 연속으로 정의됩니다. 하나의 전역 ACID 트랜잭션으로 모든 참여자를 감쌀 수 없을 때 유용합니다. 사가 패턴은 더 큰 트랜잭션을 일련의 로컬 트랜잭션으로 분해하며, 이는 사가 패턴 개요에 설명된 것처럼 여러 단계로 구성된 홈 작업에 자연스럽게 적용됩니다.

홈 AI 워크플로는 미디어 서비스를 중지하고, 라이브러리를 이동하고, 마운트를 업데이트하고, 메타데이터를 새로 고친 다음, 서비스를 다시 시작할 수 있습니다.

전체 워크플로가 원자적으로 실행되지 않더라도 각 구성 요소는 로컬에서 커밋합니다.

되돌릴 수 있는 각 단계는 보상 작업을 정의합니다

사가는 하나의 데이터베이스 명령으로 모든 서비스를 롤백하지 않습니다. 되돌릴 수 있는 단계는 이전 작업을 의미상 복원하거나 상쇄하는 보상 작업을 정의합니다.

Microservices.io는 실패가 발생하면 이전에 완료된 단계에 대해 보상 트랜잭션이 실행된다고 설명합니다. 보상은 이력을 지우는 것이 아니라 일관성을 복원합니다. Azure는 되돌릴 수 있는 사가 단계에 대한 보상 작업을 설명하며, 이는 Azure 사가 패턴에서 사용되는 보상 모델을 뒷받침합니다.

MoveFile은 MoveFileBack으로 보상할 수 있고, DisableShare는 EnableShare로 보상할 수 있습니다. 일부 외부 작업에는 완벽한 역작업이 없을 수 있으므로 그에 맞게 표시해야 합니다.

오케스트레이터는 정방향 및 역방향 순서를 결정할 수 있습니다

오케스트레이션 기반 사가에서는 하나의 워크플로 구성 요소가 순서를 파악하고, 명령을 보내며, 응답을 기록하고, 계속 진행할지 보상을 시작할지 결정합니다.

Microservices.io는 사가 오케스트레이터가 단계와 보상 작업을 호출하는 방식을 보여 줍니다. 중앙 상태 머신은 독립적인 반응이 얽힌 구조보다 홈 서버에서 감사하기 쉬운 경우가 많습니다. Temporal의 사가 지침은 오케스트레이터가 보상 작업을 등록하고 이후 단계가 실패하면 이를 호출하는 방법을 보여 주며, 이는 Temporal 사가 패턴에 설명된 역순 조정 방식과 일치합니다.

후반 단계가 실패하면 보상 작업은 일반적으로 종속성의 역순으로 실행됩니다.

파일을 이동한 후 마운트가 변경되었다면, 워크플로는 데이터를 되돌리기 전에 먼저 마운트를 복원해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

코레오그래피는 이벤트 전반에 조정을 분산합니다

코레오그래피 기반 사가에서는 각 참여자가 이벤트에 반응하고 다음 이벤트를 발생시킵니다. 중앙 조정자가 사라지는 대신 워크플로 로직이 여러 구독자에게 분산됩니다.

사가 패턴은 코레오그래피와 오케스트레이션을 명확히 구분합니다. 둘 다 보상을 조정할 수 있지만 관찰 가능성은 다릅니다. AWS는 오케스트레이션과 이벤트 기반 코레오그래피를 구분하며, 이는 AWS 사가 오케스트레이션에 설명된 조정 방식의 트레이드오프를 뒷받침합니다.

소규모 셀프 호스팅 워크플로에서는 오케스트레이션이 검사하기 더 쉬운 경우가 많습니다. 독립 서비스가 이미 이벤트 버스를 통해 통신하고 있다면 코레오그래피도 적합할 수 있습니다.

보상에는 멱등성과 안정적인 작업 식별자가 필요합니다

타임아웃이나 충돌 후 보상 작업이 재시도될 수 있으므로, 다시 실행해도 안전하거나 대상 상태가 이미 복원되었음을 감지할 수 있어야 합니다.

사가 모델은 명시적인 로컬 트랜잭션 및 보상 트랜잭션 의미 체계를 전제로 합니다. 안정적인 워크플로 ID와 단계 ID를 사용하면 재시도와 중복 실행을 구분할 수 있습니다. IBM의 사가 지침은 로컬 트랜잭션과 보상 동작을 강조하며, 이는 IBM 사가 구현 지침에서 재시도와 보상에 안정적인 식별자 및 멱등 실행이 필요한 이유를 뒷받침합니다.

이는 ZimaSpace의 반복되는 에이전트 도구 호출 루프와도 연결됩니다. 복구 워크플로는 안전하게 재개하는 중인지, 아니면 부수 효과를 반복하는 중인지 알아야 합니다.

사가는 모든 작업을 진정으로 되돌릴 수 있게 만들 수 없습니다

일부 가정용 작업은 되돌릴 수 없는 외부 결과를 초래합니다.

전송된 메시지, 안전하게 삭제된 파일 또는 제3자 구매는 역방향 API 호출만으로 항상 취소할 수 없습니다.

사가는 보편적인 분산 롤백이 아니라 보상에 의존합니다. 따라서 되돌릴 수 없는 단계는 뒤쪽에 배치하고 신중하게 제어해야 합니다. Red Hat의 분산 트랜잭션 패턴 논의는 보상이 보편적인 롤백이 아니라 비즈니스 수준의 시정 조치임을 강조하며, 이는 Red Hat 분산 트랜잭션 패턴에서 그 경계를 설명합니다.

ZimaSpace의 읽기 전용 우선 에이전트 전략은 관찰에서 수정으로 나아가는 더 안전한 진행 방식을 제공합니다. 사가는 이후 의도적으로 허용된 변경을 조정합니다.