次の方法で共有

永続化のベスト プラクティス

このドキュメントでは、ワークフローの永続化に関連するワークフローの設計と構成のベスト プラクティスについて説明します。

Durable ワークフローの設計と実装

一般に、ワークフローは、イベントを待機しているためにワークフローがアイドル状態になる時間とインターリーブされる短時間で作業を実行します。 このイベントには、メッセージや期限切れのタイマーなどがあります。 アイドル状態になったときにワークフロー インスタンスをアンロードできるようにするには、サービス ホストがワークフロー インスタンスを保持する必要があります。 これは、ワークフロー インスタンスが非永続化ゾーンに存在しない場合にのみ可能です (たとえば、トランザクションの完了を待機している場合や、非同期コールバックを待機している場合など)。 アイドル状態のワークフロー インスタンスのアンロードを許可するには、ワークフロー作成者は、有効期間の短いアクションにのみトランザクション スコープと非同期アクティビティを使用する必要があります。 特に、作成者は、これらの非永続化ゾーン内の遅延アクティビティをできるだけ短くする必要があります。

ワークフローを永続化できるのは、ワークフローで使用されるすべてのデータ型がシリアル化可能な場合のみです。 さらに、永続化されたワークフローで使用されるカスタム型は、SqlWorkflowInstanceStoreによって永続化されるためには、NetDataContractSerializerでシリアル化できる必要があります。

ホストまたはコンピューターで障害が発生した場合、ワークフロー インスタンスが永続化されていない場合、ワークフロー インスタンスを復旧することはできません。 一般に、ワークフローのライフ サイクルの早い段階でワークフロー インスタンスを保持することをお勧めします。

ワークフローが長時間ビジー状態の場合は、そのビジー期間中にワークフロー インスタンスを定期的に保持することをお勧めします。 これを行うには、ワークフロー インスタンスをビジー状態に保つ一連のアクティビティ全体に Persist アクティビティを追加します。 この方法では、アプリケーション ドメインのリサイクル、ホストエラー、またはコンピューターの障害によって、システムがビジー期間の開始にロールバックされません。 ワークフローに Persist アクティビティを追加すると、パフォーマンスが低下する可能性があることに注意してください。

Windows Server App Fabric を使用すると、永続化の構成と使用が大幅に簡略化されます。 詳細については、「Windows Server App Fabric の永続化」を参照してください。

スケーラビリティ パラメーターの構成

スケーラビリティとパフォーマンスの要件によって、次のパラメーターの設定が決まります。

これらのパラメーターは、現在のシナリオに従って次のように設定する必要があります。

シナリオ: 最適な応答時間を必要とする少数のワークフロー インスタンス

このシナリオでは、すべてのワークフロー インスタンスがアイドル状態になったときに読み込まれたままになります。 TimeToUnloadを大きな値に設定します。 この設定を使用すると、ワークフロー インスタンスがコンピューター間を移動できなくなります。 この設定は、次の 1 つ以上が該当する場合にのみ使用します。

  • ワークフロー インスタンスは、その有効期間を通じて 1 つのメッセージを受信します。

  • すべてのワークフロー インスタンスは 1 台のコンピューターで実行されます

  • ワークフロー インスタンスによって受信されるすべてのメッセージは、同じコンピューターによって受信されます。

Persistアクティビティを使用するか、TimeToPersistを 0 に設定して、サービス ホストまたはコンピューターの障害後にワークフロー インスタンスを復旧できるようにします。

シナリオ: ワークフロー インスタンスが長時間アイドル状態である

このシナリオでは、 TimeToUnload を 0 に設定して、できるだけ早くリソースを解放します。

シナリオ: ワークフロー インスタンスが短時間で複数のメッセージを受信する

このシナリオでは、これらのメッセージが同じコンピューターで受信される場合、 TimeToUnload を 60 秒に設定します。 これにより、ワークフロー インスタンスのアンロードと読み込みのシーケンスが迅速に行われなくなります。 これにより、インスタンスが長時間メモリ内に保持されることはありません。

TimeToUnloadを 0 に設定し、InstanceLockedExceptionActionを BasicRetry または AggressiveRetry に設定します(これらのメッセージが別のコンピューターで受信される可能性がある場合)。 これにより、ワークフロー インスタンスを別のコンピューターによって読み込むことができます。

シナリオ: ワークフローで短い期間の遅延アクティビティを使用する

このシナリオでは、 SqlWorkflowInstanceStore は、 Delay アクティビティの有効期限が切れたために読み込む必要があるインスタンスの永続化データベースを定期的にポーリングします。 SqlWorkflowInstanceStoreが次のポーリング間隔で期限切れになるタイマーを見つけた場合、SQL ワークフロー インスタンス ストアはポーリング間隔を短縮します。 次のポーリングは、タイマーの有効期限が切れた直後に行われます。 これにより、SQL ワークフロー インスタンス ストアでは、ポーリング間隔よりも長く実行されるタイマーの精度が高くなり、 RunnableInstancesDetectionPeriodによって設定されます。 短い遅延のタイムリーな処理を有効にするには、ワークフロー インスタンスは少なくとも 1 つのポーリング間隔でメモリ内に残る必要があります。

永続化データベースに有効期限を書き込むには、 TimeToPersist を 0 に設定します。

TimeToUnloadを RunnableInstancesDetectionPeriod 以上に設定して、少なくとも 1 つのポーリング間隔でインスタンスをメモリ内に保持します。

永続化データベースの負荷が増加するため、 RunnableInstancesDetectionPeriod を減らすことはお勧めしません。 SqlWorkflowInstanceStoreを使用する各サービス ホストは、検出期間ごとに 1 回データベースをポーリングします。 RunnableInstancesDetectionPeriodを短すぎる時間間隔に設定すると、サービス ホストの数が多い場合、システムのパフォーマンスが低下する可能性があります。

SQL ワークフロー インスタンス ストアの構成

SQL ワークフロー インスタンス ストアには、次の構成パラメーターがあります。

InstanceEncodingOption
このパラメーターは、ワークフロー インスタンスの状態を圧縮するように SqlWorkflowInstanceStore に指示します。 圧縮により、永続化データベースに格納されるデータの量が減り、永続化データベースが専用データベース サーバー上に存在する場合に備え、ネットワーク トラフィックが減少します。 圧縮を使用する場合は、インスタンスの状態を圧縮して抽出するために計算リソースが必要です。 ほとんどの場合、圧縮によってパフォーマンスが向上します。

InstanceCompletionAction
このパラメーターは、完了したインスタンスを保持または削除するように SqlWorkflowInstanceStore に指示します。 完了したインスタンスを保持すると、永続性データベースストレージの要件が増え、テーブルが大きくなり、テーブルの参照時間が長くなります。 デバッグまたは監査に完了したインスタンスが必要な場合を除き、完了したインスタンスを削除するように SqlWorkflowInstanceStore に指示することをお勧めします。 削除されたインスタンスは、ユーザーが最終的に削除するプロセスを確立した場合にのみ保持する必要があります。 完了したワークフロー インスタンスがインスタンス ストアに存在する限り、関連付けキーを再利用できないことに注意してください。

RunnableInstancesDetectionPeriod
このパラメーターは、Delay アクティビティの有効期限が切れたときに読み込む必要があるインスタンスについて、SqlWorkflowInstanceStoreが永続化データベースをポーリングする最大間隔を定義します。 SqlWorkflowInstanceStoreが次のポーリング間隔で期限切れになるタイマーを見つけた場合は、ポーリング間隔を短くして、タイマーの有効期限が切れた直後に次のポーリングが行われるようにします。 これにより、SQL ワークフロー インスタンス ストアは、 RunnableInstancesDetectionPeriodよりも長く実行されるタイマーの高い精度を実現します。

永続化データベースの負荷が増加するため、 RunnableInstancesDetectionPeriodを減らすことはお勧めしません。 SqlWorkflowInstanceStoreを使用する各サービス ホストは、検出期間ごとに 1 回データベースをポーリングします。 RunnableInstancesDetectionPeriodを短すぎる間隔に設定すると、サービス ホストの数が多い場合、システムのパフォーマンスが低下する可能性があります。

HostLockRenewalPeriod
このパラメーターは、ホストが永続化データベースのロックを更新する間隔を定義します。 この間隔を短くすると、ホストまたはコンピューターで障害が発生した場合に、ワークフロー インスタンスの迅速な復旧が可能になります。 一方、ロック更新期間が短い場合は、永続化データベースの負荷が増加します。 SqlWorkflowInstanceStoreを使用する各サービス ホストは、更新期間ごとに 1 回、データベース内のロックを更新します。 コンピューターで多数のサービス ホストが実行されている場合は、ロックの更新によって発生する負荷がシステムのパフォーマンスを低下させないようにしてください。 その場合は、 HostLockRenewalPeriodを増やすことを検討してください。

InstanceLockedExceptionAction
有効にすると、 SqlWorkflowInstanceStore は、ロックされたインスタンスを次の 30 秒間読み込むための再試行を行います。 ワークフローが短時間で複数のメッセージを受信し、これらのメッセージが異なるコンピューターで受信される場合は、 InstanceLockedExceptionAction を BasicRetry または AggressiveRetry に設定します。

読み込み再試行メカニズムでは、読み込みの再試行が試行されない限り、パフォーマンスのオーバーヘッドは発生しないため、 InstanceLockedExceptionAction は常に有効にする必要があります。