지속성 모범 사례

2025-06-17

이 문서에서는 워크플로 지속성과 관련된 워크플로 디자인 및 구성에 대한 모범 사례를 설명합니다.

지속성 워크플로 디자인 및 구현

일반적으로 워크플로는 이벤트를 기다리고 있기 때문에 워크플로가 유휴 상태인 시간과 인터리브되는 짧은 기간 동안 작업을 수행합니다. 이 이벤트는 메시지 또는 만료 타이머와 같은 것일 수 있습니다. 워크플로 인스턴스가 유휴 상태가 되면 언로드하려면 서비스 호스트가 워크플로 인스턴스를 유지해야 합니다. 워크플로 인스턴스가 비지속성 영역에 없는 경우에만 가능합니다(예: 트랜잭션이 완료되는 것을 기다리거나 비동기 콜백을 기다리는 경우). 유휴 워크플로 인스턴스를 언로드할 수 있도록 하려면 워크플로 작성자가 단기 작업에만 트랜잭션 범위 및 비동기 활동을 사용해야 합니다. 특히 작성자가 이러한 지속되지 않는 영역 내에서 지연 작업을 가능한 한 짧게 유지해야 합니다.

워크플로에서 사용하는 모든 데이터 형식을 직렬화할 수 있는 경우에만 워크플로를 유지할 수 있습니다. 또한, 지속형 워크플로에 사용되는 사용자 지정 형식은 NetDataContractSerializer로 직렬화할 수 있어야 하며, 이를 통해 SqlWorkflowInstanceStore에 의해 지속적으로 유지됩니다.

호스트 또는 컴퓨터 오류가 지속되지 않은 경우 워크플로 인스턴스를 복구할 수 없습니다. 일반적으로 워크플로의 수명 주기 초기에 워크플로 인스턴스를 유지하는 것이 좋습니다.

워크플로가 오랫동안 사용 중인 경우 사용 중인 기간 동안 워크플로 인스턴스를 정기적으로 유지하는 것이 좋습니다. 워크플로 인스턴스를 사용 중인 상태로 유지하는 작업 시퀀스 전체에 활동을 추가하여 Persist 이 작업을 수행할 수 있습니다. 이러한 방식으로 애플리케이션 도메인 재활용, 호스트 오류 또는 컴퓨터 오류로 인해 시스템이 사용 중인 기간의 시작으로 롤백되지 않습니다. 워크플로에 Persist 활동을 추가하면 성능이 저하될 수 있음을 유의하세요.

Windows Server App Fabric은 지속성의 구성과 사용을 크게 간소화합니다. 자세한 내용은 Windows Server App Fabric 지속성을 참조하세요.

확장성 매개 변수 구성

확장성 및 성능 요구 사항에 따라 다음 매개 변수의 설정이 결정됩니다.

이러한 매개 변수는 현재 시나리오에 따라 다음과 같이 설정해야 합니다.

시나리오: 최적의 응답 시간이 필요한 적은 수의 워크플로 인스턴스

이 시나리오에서는 모든 워크플로 인스턴스가 유휴 상태가 되면 로드된 상태로 유지되어야 합니다. 큰 값으로 설정합니다 TimeToUnload . 이 설정을 사용하면 워크플로 인스턴스가 컴퓨터 간에 이동하지 못하게 됩니다. 다음 중 하나 이상이 true인 경우에만 이 설정을 사용합니다.

워크플로 인스턴스는 수명 동안 단일 메시지를 받습니다.
모든 워크플로 인스턴스는 단일 컴퓨터에서 실행됩니다.
워크플로 인스턴스에서 받은 모든 메시지는 동일한 컴퓨터에서 수신됩니다.

Persist 활동을 사용하거나 TimeToPersist을 0으로 설정하여 서비스 호스트 또는 컴퓨터의 장애가 발생한 후 워크플로 인스턴스를 복구할 수 있도록 합니다.

시나리오: 워크플로 인스턴스가 오랜 시간 동안 유휴 상태입니다.

이 시나리오에서는 가능한 한 빨리 리소스를 해제하려면 0으로 설정합니다 TimeToUnload .

시나리오: 워크플로 인스턴스는 짧은 시간 안에 여러 메시지를 받습니다.

이 시나리오에서는 동일한 컴퓨터에서 이러한 메시지를 받는 경우 60초로 설정합니다 TimeToUnload . 이렇게 하면 워크플로 인스턴스의 빠른 언로드 및 로드 시퀀스를 방지할 수 있습니다. 또한 인스턴스를 메모리에 너무 오래 유지하지 않습니다.

다른 컴퓨터에서 이러한 메시지를 받을 수 있는 경우, 먼저 TimeToUnload를 0으로 설정하고 InstanceLockedExceptionAction를 BasicRetry 또는 AggressiveRetry로 설정합니다. 이렇게 하면 워크플로 인스턴스를 다른 컴퓨터에서 로드할 수 있습니다.

시나리오: 워크플로에서 짧은 기간의 지연 활동을 사용합니다.

이 시나리오 SqlWorkflowInstanceStore 에서는 만료된 Delay 활동으로 인해 로드해야 하는 인스턴스에 대해 지속성 데이터베이스를 정기적으로 폴링합니다. SqlWorkflowInstanceStore 다음 폴링 간격에서 만료되는 타이머를 찾으면 SQL 워크플로 인스턴스 저장소는 폴링 간격을 단축합니다. 그런 다음 타이머가 만료된 직후에 다음 폴링이 발생합니다. 이러한 방식으로 SQL 워크플로 인스턴스 저장소는 폴링 간격보다 더 오래 실행되는 타이머의 높은 정확도를 달성합니다 RunnableInstancesDetectionPeriod. 더 짧은 지연을 적시에 처리하려면 워크플로 인스턴스가 하나 이상의 폴링 간격 동안 메모리에 남아 있어야 합니다.

지속성 데이터베이스에 만료 시간을 쓰려면 0으로 설정합니다 TimeToPersist .

TimeToUnload을(를) RunnableInstancesDetectionPeriod보다 길거나 같게 설정하여 인스턴스를 최소한 하나의 폴링 간격 동안 메모리에 유지하십시오.

지속성 데이터베이스의 RunnableInstancesDetectionPeriod 부하가 증가하므로 줄이지 않는 것이 좋습니다. SqlWorkflowInstanceStore를 사용하는 각 서비스 호스트는 검색 기간당 데이터베이스를 한 번 폴링합니다. 시간 간격을 너무 작게 설정 RunnableInstancesDetectionPeriod 하면 서비스 호스트 수가 큰 경우 시스템 성능이 저하될 수 있습니다.

SQL 워크플로 인스턴스 저장소 구성

SQL 워크플로 인스턴스 저장소에는 다음과 같은 구성 매개 변수가 있습니다.

InstanceEncodingOption
이 매개 변수는 SqlWorkflowInstanceStore 워크플로 인스턴스 상태를 압축하도록 지시합니다. 압축은 지속성 데이터베이스에 저장된 데이터의 양을 줄이고 지속성 데이터베이스가 전용 데이터베이스 서버에 있는 경우 네트워크 트래픽을 줄입니다. 압축을 사용하는 경우 인스턴스 상태를 압축하고 추출하려면 계산 리소스가 필요합니다. 대부분의 경우 압축을 통해 성능이 향상됩니다.

InstanceCompletionAction
이 매개 변수는 완료된 SqlWorkflowInstanceStore 인스턴스를 유지하거나 삭제하도록 지시합니다. 완료된 인스턴스를 유지하면 지속성 데이터베이스 스토리지 요구 사항이 증가하고 테이블 조회 시간이 늘어나게 됩니다. 디버깅 또는 감사에 완료된 인스턴스가 필요하지 않은 경우 완료된 인스턴스를 삭제하도록 지시 SqlWorkflowInstanceStore 하는 것이 가장 좋습니다. 삭제된 인스턴스는 사용자가 최종적으로 제거하는 프로세스를 설정하는 경우에만 유지되어야 합니다. 완료된 워크플로 인스턴스가 인스턴스 저장소에 있는 한 상관 관계 키를 다시 사용할 수 없습니다.

RunnableInstancesDetectionPeriod
이 매개 변수는 SqlWorkflowInstanceStore이(가) Delay 활동이 만료될 때 로드해야 하는 인스턴스를 지속성 데이터베이스에서 폴링하는 최대 간격을 정의합니다. SqlWorkflowInstanceStore 다음 폴링 간격에서 만료되는 타이머를 찾으면 타이머가 만료된 직후에 다음 폴링이 수행되도록 폴링 간격이 단축됩니다. 이러한 방식으로 SQL 워크플로 인스턴스 저장소는 보다 RunnableInstancesDetectionPeriod오래 실행되는 타이머의 높은 정확도를 달성합니다.

지속성 데이터베이스의 RunnableInstancesDetectionPeriod부하가 증가하므로 줄이지 않는 것이 좋습니다. SqlWorkflowInstanceStore를 사용하는 각 서비스 호스트는 검색 기간당 데이터베이스를 한 번 폴링합니다. 간격을 너무 작게 설정 RunnableInstancesDetectionPeriod 하면 서비스 호스트 수가 큰 경우 시스템 성능이 저하될 수 있습니다.

HostLockRenewalPeriod
이 매개 변수는 호스트가 지속성 데이터베이스에서 잠금을 갱신하는 간격을 정의합니다. 이 간격을 줄이면 호스트 또는 컴퓨터가 실패할 경우 워크플로 인스턴스를 더 빠르게 복구할 수 있습니다. 반면에 잠금 갱신 기간이 짧으면 지속성 데이터베이스에 대한 부하가 증가합니다. 이 기능을 사용하는 SqlWorkflowInstanceStore 각 서비스 호스트는 갱신 기간마다 데이터베이스의 잠금을 한 번 업데이트합니다. 컴퓨터가 많은 서비스 호스트를 실행하는 경우 잠금 갱신으로 인한 부하가 시스템 성능을 저하시키지 않는지 확인합니다. 이 경우 HostLockRenewalPeriod을 늘리는 것이 좋습니다.

InstanceLockedExceptionAction
사용이 설정된 경우, SqlWorkflowInstanceStore는 다음 30초 동안 잠겼던 인스턴스를 로드하려고 다시 시도합니다. 워크플로가 짧은 시간에 여러 메시지를 수신하고 이러한 메시지를 다른 컴퓨터에서 수신하는 경우 BasicRetry 또는 AggressiveRetry로 설정합니다 InstanceLockedExceptionAction .

부하 재시도 메커니즘은 부하 재시도를 시도 InstanceLockedExceptionAction 하지 않는 한 성능 오버헤드를 발생시키지 않으므로 항상 사용하도록 설정해야 합니다.