バックグラウンド ジョブの開発に関するレコメンデーション
この Power Platform Well-Architected Reliabilityチェックリストの推奨事項に適用されます:
| RE:05 | エラー処理と一時的な故障処理を実装することで、ワークロードの回復力を強化します。 コンポーネントの故障や一時的なエラーを処理する機能をソリューションに組み込みます。 |
|---|
このガイドでは、バックグラウンド ジョブの開発に関するレコメンデーションについて説明します。 バックグラウンド ジョブは、ユーザーの操作を必要とせずに自動的に実行されます。 多くのアプリケーションでは、ユーザー インターフェイス (UI) から独立して実行されるバックグラウンド ジョブが必要です。
バックグラウンド ジョブの例としては、バッチ ジョブ、集中的な処理タスク、ワークフローなどの長時間実行されるプロセスなどがあります。 アプリケーションはジョブを開始し、ユーザーからの対話型要求を処理します。
たとえば、アプリケーションは概要を生成し、ユーザーがアップロードしたドキュメントから感情や重要なポイントを抽出する必要がある場合があります。 バックグラウンド ジョブを実行して AI アクションを実行し、概要とキー ポイントをデータベースに保存できます。 ユーザーはプロセスが完了するまで待つ必要はありません。 別の例として、ユーザーが経費請求を送信すると、経費請求を処理して承認のために送信するバックグラウンド ワークフローが開始されます。 バックグラウンド ジョブの実行中、ユーザーは引き続き別の経費請求を提出したり、アプリケーションを終了したりできます。 バックグラウンド ジョブが完了すると、経費請求が承認のために送信されたことを確認する電子メールがユーザーに送信されます。
アプリケーション UI の負荷を最小限に抑え、可用性を向上させ、対話型の応答時間を短縮するバックグラウンド ジョブ。
主要な設計戦略
バックグラウンド ジョブとして指定するタスクを選択するには、タスクがユーザーの操作なしで実行されるかどうか、および UI がタスクの完了を待機する必要があるかどうかを考慮します。 ユーザーまたは UI が実行中に待機する必要があるタスクは、通常、適切なバックグラウンド ジョブではありません。
バックグラウンド ジョブの種類
バックグラウンド ジョブの例は次のとおりです。
一連のトランザクションの実行など、完了までに長い時間を要するリソース集約型のジョブ。
夜間のデータ更新やスケジュールされた処理などのバッチ ジョブ。
注文処理やサービスおよびシステムのプロビジョニングなどの長時間実行されるワークフロー。
承認などの非同期コラボレーションを必要とするワークフロー。
タスクをより安全な場所に転送して処理する機密データ処理。 たとえば、Web アプリ内で機密データを処理したくない場合があります。 代わりに、Gatekeeper パターン などのパターンを使用して、保護されたストレージにアクセスできる分離されたバックグラウンド プロセスにデータを転送することもできます。
トリガー
バックグラウンド ジョブを開始するには:
イベント駆動型トリガー: アプリケーション内のユーザー アクションまたは データ ソース に対して発生するイベントによって、タスク がトリガーされます。
スケジュール駆動型トリガー: タイマーに基づくスケジュールは、タスク を呼び出します。 ジョブは定期的に、または 1 回の実行としてスケジュールできます。
イベント駆動型トリガー
アクションは、バックグラウンド タスクを開始するイベント駆動型の呼び出しをトリガーします。 イベント駆動型トリガーの例は次のとおりです:
UI または別のジョブがバックグラウンド ジョブをトリガーし、実行されたアクションからのデータをバックグラウンド ジョブに渡します。 たとえば、ユーザーがフォームを介して経費請求を送信すると、フォームの詳細がバックグラウンド ジョブに渡されて処理されます。
UI または別のジョブが、ストレージ内の値を保存または更新します。 バックグラウンド ジョブはストレージを監視し、新しい値の追加や既存の値の変更などの変更を検出し、その変更に基づいてバックグラウンド ジョブをトリガーします。
UI または別のジョブが、HTTPS URI や Web サービスとして暴露されている API などの エンドポイント に要求を送信します。 要求の一部として、UI またはジョブはバックグラウンド タスクに必要なデータを転送します。 エンドポイントまたは Web サービスは、データを入力として使用するバックグラウンド タスクを呼び出します。
イベント駆動型トリガーの他の例としては、アプリケーションでフォームが送信される、データ ストア に新しい行が追加される、copilot内の トリガー フレーズ がフローを呼び出す トピック を開始する、データ ストア でフィールドの値が変更される、特定の件名または特定の送信者からの電子メールが受信トレイに到着する、ファイルがファイル保存場所にアップロードされるなどがあります。
トリガー条件を使用してワークフローを合理化し、不要な実行回数を減らします。 トリガー条件は、ワークフローがトリガーされる前に満たす必要がある複数の条件を設定します。
注意
ワークフローの一部として、ワークフローを開始する データ ソース を変更する場合は、無限ループを防ぐために必ずトリガー条件を使用してください。 たとえば、アプリケーションが Microsoft Dataverse テーブル行のフィールドを変更し、ワークフローがそれらの変更されたフィールドに基づいて追加のクエリを実行し、同じ行をさらに変更する場合があります。 トリガー条件を使用すると、アプリケーションによって変更されたフィールドが更新された場合にのみワークフローが開始され、他のフィールドは更新されません。
スケジュール駆動型トリガー
タイマーは、バックグラウンド タスクを開始するスケジュール駆動型の呼び出しをトリガーします。 スケジュール駆動型トリガーの例は次のとおりです:
バックグラウンド ジョブは毎日または毎週実行され、一連のアクションを実行します。
別のプロセスまたはアプリケーションがタイマーを開始し、一定時間経過後または特定の時間にバックグラウンド タスクを呼び出します。
スケジュール駆動の呼び出しに適したタスクのその他の例には、バッチ処理ルーチン (最近の行動に基づいて顧客の関連製品リストを更新するなど)、日常的なデータ処理タスク (蓄積された結果の生成など)、日次データ分析などがあります。レポート、データ保持のクリーンアップ、およびデータの整合性チェック。
結果を返す
バックグラウンド ジョブは、UI またはバックグラウンド ジョブを呼び出したプロセスとは別のプロセスで非同期的に実行されます。 理想的には、バックグラウンド ジョブは 実行して忘れる 操作です。 実行時の進行状況は UI や呼び出しプロセスに影響を与えません。つまり、呼び出しプロセスはタスクが完了するまで待機しません。 UI と呼び出しプロセスは、タスクの終了を検出できません。
バックグラウンド タスクが呼び出しタスクと通信して進行状況または完了を示す必要がある場合は、次のようなメカニズムを実装する必要があります。
ステータス インジケーター値を、UI または呼び出し元タスクがアクセス可能なストレージに書き込みます。この値は監視または確認できます。 バックグラウンド タスクが呼び出し元に返すその他のデータは、同じストレージに配置できます。
UI または呼び出し元がステータス情報を取得するためにアクセスできるバックグラウンド タスクから API またはエンドポイントを公開します。 応答には、バックグラウンド タスクが呼び出し元に返すデータを含めることができます。
処理したステータスまたはデータを UI に返すようにバックグラウンド タスクを構成します。
調整
バックグラウンド タスクは複雑になる可能性があり、複数のタスクを実行する必要があります。 このようなシナリオでは、タスクを複数のコンシューマーが実行できる小さな個別のステップまたはサブタスクに分割するのが一般的です。 多くの場合、個々のステップは複数のジョブで再利用できるため、マルチステップ ジョブはより効率的で柔軟性が高くなります。 ステップの追加、削除、または順序の変更も簡単です。
複数のタスクとステップを調整するのは難しい場合がありますが、解決策を導くための一般的なパターンが 3 つあります。
タスク を複数の再利用可能なステップに分解します。 アプリケーションは、処理する情報に対して、複雑さの異なるさまざまなタスクを実行する必要がある場合があります。 このようなアプリケーションを実装するための単純だが柔軟性のないアプローチは、この処理をモノリシック モジュールとして実行することです。 ただし、このアプローチでは、アプリケーションが他の場所で同じ処理の一部を必要とする場合に、コードのリファクタリング、最適化、またはコードの再利用の機会が減る可能性があります。
タスク のステップのオーケストレーションを管理します。 アプリケーションは多くのステップで構成されるタスクを実行する場合があり、その一部ではリモート サービスを呼び出したり、リモート リソースにアクセスしたりすることがあります。 個々のステップは互いに独立している場合もありますが、タスクを実装するアプリケーション ロジックによって調整されます。
失敗した タスク ステップの回復を管理します。 1 つ以上のステップが失敗した場合、アプリケーションは一連のステップで実行された作業を元に戻す必要がある場合があります。これらの作業は、最終的に一貫性のある操作を定義します。
回復性に関する考慮事項
回復性があるあるバックグラウンド タスクを作成して、アプリケーションに信頼性の高いサービスを提供します。 バックグラウンド タスクを計画および設計するときは、次の点を考慮してください。
バックグラウンド タスクは、データを破損したり、アプリケーションに不整合を導入したりすることなく、再起動を適切に処理する必要があります。 長時間実行または複数ステップのタスクの場合は、チェックポイントの使用を検討します。 チェックポイントを使用して、ジョブの状態を永続ストレージに保存するか、キュー内のメッセージとして保存し、アクションが予期せず失敗した場合に備えて再試行ロジックを構成します。
キューを使用してバックグラウンド タスクと通信する場合、キューは、アプリケーションが通常よりも高い負荷を受けているときにタスクに送信されるリクエストを格納するバッファとして機能します。 タスクは忙しくない時間帯に UI に追いつくことができ、再起動によってUIがブロックされることはありません。
スケーリングおよびパフォーマンスに関する考慮事項
バックグラウンド タスクは、システムに負荷がかかっているときにアプリケーションをブロックしたり操作を遅らせたりしないように、十分なパフォーマンスを提供する必要があります。 通常、バックグラウンド タスクをホストするコンピューティング インスタンスをスケーリングすると、パフォーマンスが向上します。 バックグラウンド タスクを計画および設計するときは、スケーラビリティとパフォーマンスに関連する次の点を考慮してください。
バックグラウンド タスクの結果がユーザーに表示される場合、バックグラウンド ジョブはユーザー エクスペリエンスに影響を与える可能性があります。 たとえば、バックグラウンド ジョブでは、ユーザーが通知を待ったり、ページを更新したり、タスクのステータスを手動で確認したりする必要がある場合があります。 これらの動作により、ユーザー操作の複雑さが増し、ユーザー エクスペリエンスに悪影響を与える可能性があります。 メールや Microsoft Teams 経由で通知を送信したり、UI でステータスの更新をチェックする機能を含めるなど、UI にデータを返信する代替手段を検討します。 経費フォームを送信する例では、ステータスを UI に返すのではなく、送信されたすべての経費フォームとそのステータスを一覧表示し、更新をトリガーする機能をアプリケーション内に用意することができます。
バックグラウンド ジョブは、特にバックグラウンド タスクが相互に依存している場合、または他のデータ ソースに依存している場合、データの同期とプロセスの調整に課題をもたらす可能性があります。 たとえば、バックグラウンド ジョブは、データの整合性の問題、競合状態、デッドロック、またはタイムアウトを処理する場合があります。
負荷によるパフォーマンスの低下を防ぐために、処理チェーンの単一点がボトルネックを引き起こさないようにロジックを実装することがあります。 ワークフロー アクション、ストレージ、アプリケーションとバックグラウンド タスクが依存するその他のサービスの最大スループットなど、その他の制限も考慮してください。
トレードオフ: バックグラウンド ジョブにより、システムにさらに多くのコンポーネントと依存関係が導入され、ソリューションの複雑さと メンテナンス コストが増加する可能性があります。 たとえば、バックグラウンド ジョブでは、別の監視サービスと再試行メカニズムが必要になる場合があります。
Power Platform の促進
次のセクションでは、バックグラウンド ジョブをホスト、実行、構成、管理するために使用できるサービスについて説明します。
Power Automate
Power Automate クラウド フロー はクラウドで実行されるワークフローです。 これらは、特定の人からの電子メールの到着などのイベントによってトリガーされる自動フローにすることができます。 これらは、モバイル デバイスからチームに送信するリマインダーのように、ボタンをクリックするだけで開始できるインスタント フローです。 これらは、SharePoint またはデータベースへの毎日のデータアップロードなど、特定の時間に実行されるスケジュールされたフローにすることができます。 または、デスクトップまたはモバイル デバイスから反復するタスクを自動化できます。
スループット、リクエスト、同時実行、ループ、デバッチ処理に関して、自動化フロー、スケジュール フロー、インスタント フローの制限 を理解します。 ワークフローを設計する際には、これらの制限を必ず考慮してください。
リスクの軽減とエラー処理の計画によりリスクを軽減します。
以下に、フローを使用してバックグラウンド ジョブを実行できる例をいくつか示します。 Power Automate
Microsoft Dataverse
Microsoft Dataverse 計算列とロールアップ:
数式列は、計算された値をテーブルに表示する列です。 Microsoft Dataverse
計算列は、ビジネス プロセスで使用する手動計算を自動化します。 たとえば、営業担当者は営業案件の売上高の期待値を知ることが必要になる場合があります。この期待値は、営業案件からの売上見込みに確率を乗じて得られた値に基づきます。 または、受注が特定の金額より大きい場合、値引きを自動的に適用することを望みます。 計算列には、単純な数学演算や greater than または if-else などの条件付き演算の結果のような値を含めることができます。
ロールアップ列は、主要ビジネス指標を監視することによって、ユーザーがデータを把握するのに役立ちます。 ロールアップ列には、指定した行に関連する行に対して計算された集計値が含まれています。 これには、メールや予定など定期的なテーブルと活動テーブルが含まれます。 より複雑なシナリオでは、行の階層にわたるデータを集計できます。 管理者またはカスタマイザーの場合は、Power Apps のカスタマイズ ツールを使用してコードを記述する必要なく、ロールアップ列を定義できます。
バックグラウンド操作 は、非同期で処理されるリクエストを送信できます Dataverse バックグラウンド操作は、リクエストの実行中に接続を維持したくない場合に役立ちます。
プラグインは、データ操作の処理中に発生した特定のイベントに対して 応答 内で実行されるカスタム イベント ハンドラーです。 Microsoft Dataverse
Microsoft Dataverse はまた、ローコード プラグインを通じて、より効率的なデータ アーキテクチャを実現し、クライアント側のワークロードを削減する強力なソリューションも提供しています。これらのプラグインは、再利用可能なリアルタイム ワークフローであり、Dataverse 内で特定のコマンド セットを実行し、サーバー側で実行され、カスタマイズされたイベント ハンドラーによってトリガーされます。
信頼性チェックリスト
完全なレコメンデーションのセットを参照してください。