Durable Task의 가치는 모든 백그라운드 작업자나 메시지 큐 또는 데이터베이스를 대체하는 데 있는 것이 아니라, 장시간 지속되거나 외부 이벤트를 기다리며 중단되거나 일부 단계가 실행된 후 중단될 수 있는 작업을 구성하는 데 있습니다. .NET 블로그는 Durable Task .NET SDK 버전 1.26.0과 Durable Task Scheduler를 사용한 다섯 가지 실용적인 예를 제시하며, 이 도구가 조정 기록은 보존하지만 일시 중단된 CLR 실행 스택을 복구하지는 않는다고 강조합니다.
핵심 개념은 워크플로 엔진이 조정하는 부분과 애플리케이션의 책임으로 남는 부분을 분리하는 것입니다. Durable Task는 진행 지점을 저장하고, 실행 스레드를 계속 점유하지 않은 채 대기하며, 기록된 결과를 바탕으로 조정자 코드를 다시 실행할 수 있습니다. 그러나 사용자 권한을 결정하거나, 외부 효과가 단 한 번만 실행되도록 보장하거나, 삭제해도 안전한 리소스를 결정하거나, 결제가 실제로 도착했는지를 단독으로 판단하지는 않습니다.
사람의 승인은 작업자를 중지시키는 것을 의미하지 않는다
송장 처리에서는 각 송장을 별도의 하위 조정으로 실행할 수 있습니다. 검토가 필요하지 않은 송장은 계속 진행하고, 사람의 승인이 필요한 송장은 외부 이벤트와 견고한 시간 제한을 기다립니다. 작업자가 중단되더라도 다른 작업자가 조정자를 다시 실행하여 수동으로 상태를 재구성하는 대신 대기 지점으로 돌아갈 수 있습니다.
그러나 승인 이벤트는 단지 신호일 뿐입니다. 문서화된 엔드포인트는 신호를 보내기 전에 애플리케이션 저장소에 최종 결정을 원자적으로 기록해야 하며, 회계 단계는 안정적인 배포 ID와 변경할 수 없는 요청 지문을 검증해야 합니다. 회계 기록이 승인된 후 활동 확인이 유실되었다면 Durable Task 기록만으로는 중복을 방지하기에 충분하지 않으며, 회계 시스템과의 조정 프로토콜이 필요합니다.
Azure 환경 프로비저닝: ARM의 역할은 어디에서 끝나는가?
이 글은 ARM과 Bicep이 특정 리소스를 배포하는 데 충분할 수 있다고 설명합니다. 두 도구는 종속성 순서, 병렬 실행, 안정적인 ID를 사용한 원하는 상태의 재적용을 제공합니다. 따라서 ARM이 이미 제공하는 배포 오케스트레이션을 Durable Task로 다시 구축하는 것은 정당화되지 않습니다.
프로세스가 리소스 배포를 넘어 테넌트 요청 수락, 진행 상황 알림, 준비 상태 대기, 테넌트 활성화까지 이어질 때 이점이 나타납니다. 이 예에서는 프로비저닝 요청과 해당 ID를 outbox와 함께 애플리케이션 데이터베이스에 저장한 다음, 네트워크, 데이터베이스, 스토리지, 애플리케이션, DNS, 준비 상태 확인 단계를 연결하는 조정을 사용하도록 제안합니다. Azure 작업 자체에는 여전히 작업 기록, 안정적인 ID, 응답 유실 시 조정이 필요합니다.
또한 이 글은 보상을 되돌리기 버튼으로 간주하지 말라고 경고합니다. 스토리지 실패 후에도 Azure가 데이터베이스를 계속 생성하고 있을 수 있기 때문입니다. 따라서 이전 시도가 새로운 작업을 시작하지 못하도록 막고, 이전에 전송된 작업을 확인하며, 아직 완료되지 않은 작업이 리소스를 다시 만들 수 없다는 점을 확인한 후에만 해당 시도가 독점적으로 소유한 리소스를 삭제해야 합니다. 상태나 소유권을 입증할 수 없다면 안전한 결과는 추측에 따른 삭제가 아니라 NeedsIntervention입니다.
결제 시간 제한 만료는 거절이 아니다
구독 주기에서는 거래가 승인된 후 결제 제공업체의 응답이 사라질 수 있습니다. 즉시 재시도하면 이중 청구가 발생할 수 있고, 이를 거절로 간주하면 오해를 불러일으키는 알림이 전송될 수 있습니다. 이 예에서는 각 결제 주기를 주기 ID와 안정적인 결제 키에 연결한 다음 durable 타이머, 콜백, 주기적 확인, 명확한 유예 기간을 사용하도록 제안합니다.
결제 원장은 Unknown, Pending, Declined, Paid, NotCharged 상태의 authoritative 기준입니다. 영수증이 확인되고 현재 주기가 종료된 후에만 다음 주기로 이동합니다. 시간 제한이 만료되었는데도 상태가 해결되지 않은 경우, 결제의 성공 또는 실패를 가정하는 대신 결과는 NeedsReconciliation이 됩니다.
지연된 이벤트에는 대상 측의 보호가 필요하다
뉴스 기사의 검색 색인을 업데이트할 때 버전 12가 버전 13 이후에 도착하거나 색인 작업이 역순으로 완료될 수 있습니다. durable 엔터티는 확인된 가장 높은 버전과 카운터 업데이트 순서를 저장할 수 있지만, 외부 색인을 잠그거나 두 요청이 병렬로 쓰는 것을 막지는 못합니다.
따라서 대상 자체가 원자적인 버전 장벽을 적용하여 최신 버전이 확정된 후 더 오래된 버전의 쓰기를 거부해야 합니다. 또한 시스템에는 신뢰할 수 있는 inbox, 후속 처리를 위한 디스패처, 소스와의 주기적인 조정이 필요합니다. 단일 ID를 사용하는 조정자 패턴조차 외부 효과에 대해 단 한 번의 실행을 보장하지는 않습니다.
이것이 AI 에이전트에는 무엇을 의미하는가?
인시던트 보조자의 워크플로에서는 특정 모델의 제안을 저장하고, 엔지니어의 승인을 기다린 다음, 잠재적인 중단 후 승인된 도구를 실행해야 합니다. 여기서 가치는 재실행할 때마다 새로운 제안을 다시 생성하는 것이 아니라 승인 경로와 동일한 결정을 복구하는 데 있습니다. 제안의 ID, 도구의 유효성, 오래되었거나 중복된 요청의 실행 방지는 여전히 애플리케이션의 책임입니다.
다섯 가지 예에서 얻는 실용적인 결론은 ‘다음에 무엇이 일어날지’를 저장하는 것이 그 자체로 하나의 시스템이 될 때 Durable Task가 적합하다는 것입니다. 반면 애플리케이션에 이미 명확한 큐, 타이머, 조정 기록이 있거나 ARM처럼 외부 시스템이 신뢰할 수 있는 조정을 제공한다면, 이 프레임워크는 가치보다 복잡성을 더할 수 있습니다. 또한 모든 예는 권위 있는 기록, idempotency 키, 버전 장벽, outbox 또는 조정 프로토콜과 같은 명시적인 외부 경계에 의존합니다.