バックグラウンド ジョブの開発に関する推奨事項

  • [アーティクル]

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:07 自己保存と自己復旧の手段を実装することで、ワークロードの回復性と回復性を強化します。 インフラストラクチャベースの信頼性パターンとソフトウェアベースの設計パターンを使用して、コンポーネントの障害や一時的なエラーを処理することで、ソリューションに機能を組み込みます。 システムに機能を組み込み、ソリューション コンポーネントの障害を検出し、ワークロードが引き続き完全または縮小された機能で動作している間に修正アクションを自動的に開始します。

関連ガイド:一時的な | 障害自己保存

このガイドでは、バックグラウンド ジョブを開発するための推奨事項について説明します。 バックグラウンド ジョブは、ユーザー操作を必要とせずに自動的に実行されます。 多くのアプリケーションでは、UI から独立して実行されるバックグラウンド ジョブが必要です。

バックグラウンド ジョブの例としては、バッチ ジョブ、集中的な処理タスク、実行時間の長いプロセス (ワークフローなど) などがあります。 アプリケーションはジョブを開始し、ユーザーからの対話型要求を処理します。 たとえば、アプリケーションでユーザーがアップロードする画像のサムネイルを生成する必要がある場合は、バックグラウンド ジョブを実行してサムネイルを生成し、ストレージに保存することができます。 ユーザーは、プロセスの完了を待つ必要はありません。 別の例として、顧客が注文を行い、注文を処理するバックグラウンド ワークフローを開始します。 バックグラウンド ジョブの実行中、顧客は引き続き Web アプリを参照します。 バックグラウンド ジョブが完了すると、保存されている注文データが更新され、注文を確認するメールが顧客に送信されます。

バックグラウンド ジョブは、アプリケーション UI の負荷を最小限に抑えるのに役立ちます。これにより、可用性が向上し、対話型の応答時間が短縮されます。

主要な設計戦略

バックグラウンド ジョブとして指定するタスクを選択するには、ユーザー操作なしでタスクを実行するかどうか、および UI がタスクの完了を待機する必要があるかどうかを検討します。 ユーザーまたは UI の実行中に待機する必要があるタスクは、通常、適切なバックグラウンド ジョブではありません。

バックグラウンド ジョブの種類

バックグラウンド ジョブの例を次に示します。

  • CPU に負荷のかかるジョブ (数学的計算、構造モデル分析など)。

  • 一連のストレージ トランザクションの実行やファイルのインデックス作成など、I/O 負荷の高いジョブ。

  • バッチ ジョブ (夜間のデータ更新、スケジュール設定された処理など)。

  • 注文フルフィルメントやプロビジョニング サービスやシステムなど、実行時間の長いワークフロー。

  • 処理のためにタスクをより安全な場所に転送する機密データ処理。 たとえば、機密データは、Web アプリ内で処理するより、 Gatekeeper パターン などのパターンに従い、保護された記憶域にアクセスできる分離されたバックグラウンド プロセスにデータを転送した方が賢明です。

トリガー

次を使用してバックグラウンド ジョブを開始します。

  • イベント ドリブン トリガー: イベント (通常はユーザー アクションまたはワークフロー内のステップ) によってタスクがトリガーされます。

  • スケジュール 駆動型トリガー: タイマーに基づくスケジュールによってタスクが呼び出されます。 ジョブは、定期的にスケジュールすることも、1 回の実行に対してスケジュールすることもできます。

イベント ドリブン トリガー

アクションは、バックグラウンド タスクを開始するイベント ドリブンの呼び出しをトリガーします。 イベント ドリブン トリガーの例を次に示します。

  • UI または別のジョブは、 Web-Queue-Worker アーキテクチャ スタイルで説明されているように、キューにメッセージを配置します。 メッセージには、注文を行った顧客など、以前に実行されたアクションに関するデータが含まれます。 バックグラウンド ジョブはこのキューを監視し、新しいメッセージの到着を検出します。 メッセージを読み取り、メッセージのデータをバックグラウンド ジョブの入力として使用します。 このパターンは、 非同期メッセージ ベースの通信と呼ばれます。

  • UI または別のジョブは、ストレージ内の値を保存または更新します。 バックグラウンド ジョブはストレージを監視し、変更を検出します。 データを読み取り、バックグラウンド ジョブの入力として使用します。

  • UI または別のジョブは、HTTPS URI や Web サービスとして公開される API などのエンドポイントに対して要求を行います。 要求の一部として、UI またはジョブはバックグラウンド タスクに必要なデータを転送します。 エンドポイントまたは Web サービスがバックグラウンド タスクを呼び出すときに、そのデータが入力として使用されます。

イベント ドリブン呼び出しに適したその他のタスクの例としては、画像処理、ワークフロー、リモート サービスへの情報の送信、電子メール メッセージの送信、マルチテナント アプリケーションでの新しいユーザーのプロビジョニングなどがあります。

スケジュール ドリブン トリガー

タイマーは、バックグラウンド タスクを開始するスケジュール駆動型の呼び出しをトリガーします。 スケジュール駆動型トリガーの例を次に示します。

  • アプリケーション内またはアプリケーションのオペレーティング システムの一部としてローカルに実行されるタイマーは、バックグラウンド タスクを定期的に呼び出します。

  • Azure Logic Apps などの別のアプリケーションで実行されるタイマーは、API または Web サービスに定期的に要求を送信します。 その API または Web サービスによってバックグラウンド タスクが呼び出されます。

  • 別のプロセスまたはアプリケーションは、時間の遅延後または特定の時刻にバックグラウンド タスクを呼び出すタイマーを開始します。

スケジュール駆動型の呼び出しに適したその他のタスクの例としては、バッチ処理ルーチン (最近の動作に基づいて顧客の関連製品リストを更新するなど)、定期的なデータ処理タスク (インデックスの更新や累積結果の生成など)、日次レポートのデータ分析、データ保持クリーンアップ、データ整合性チェックなどがあります。

1 つのインスタンスとして実行する必要があるスケジュール駆動型タスクを使用する場合は、次の考慮事項を確認してください。

  • Windows のスケジュールされたタスクを使用する仮想マシン (VM) などのスケジューラを実行するコンピューティング インスタンスがスケーリングされている場合は、スケジューラの複数のインスタンスを実行しています。 スケジューラの複数のインスタンスは、タスクの複数のインスタンスを開始できます。 詳細については、「ソフトウェア システムにおけるべき等の意味」を参照してください。

  • タスクがスケジューラ イベント間の期間より長く実行される場合、スケジューラは、前のタスクの実行中にタスクの別のインスタンスを開始する可能性があります。

結果を返す

バックグラウンド ジョブは、UI またはバックグラウンド ジョブを呼び出したプロセスとは別のプロセス、または別の場所で非同期的に実行されます。 理想的には、バックグラウンド ジョブは 起動操作と忘れ 操作です。 ランタイムの進行状況は、UI または呼び出し元のプロセスには影響しません。つまり、呼び出し元のプロセスはタスクの完了を待機しません。 UI と呼び出し元のプロセスでは、タスクがいつ終了したのを検出できません。

バックグラウンド タスクが、進行状況または完了を示すために呼び出し元のタスクと通信する必要がある場合は、メカニズムを実装する必要があります。 次に例を示します。

  • UI または呼び出し元タスクからアクセスできるストレージに状態インジケーター値を書き込みます。この値を監視またはチェックできます。 バックグラウンド タスクが呼び出し元に返すその他のデータは、同じストレージに配置できます。

  • UI または呼び出し元が監視する応答キューを確立します。 バックグラウンド タスクは、状態を示すメッセージをキューに送信できます。 バックグラウンド タスクが呼び出し元に返すデータは、メッセージに配置できます。 Azure Service Busの場合は、 プロパティと CorrelationId プロパティをReplyTo使用してこの機能を実装します。

  • UI や呼び出し元がステータス情報を取得する目的でアクセスできる API またはエンドポイントをバックグラウンド タスク側で公開する。 応答には、バックグラウンド タスクが呼び出し元に返すデータを含めることができます。

  • 定義済みのポイントまたは完了時に状態を示すために、API を介して UI または呼び出し元にコールバックするようにバックグラウンド タスクを構成します。 ローカルで発生したイベント、またはパブリッシュとサブスクライブのメカニズムを使用できます。 要求またはイベント ペイロードには、バックグラウンド タスクが呼び出し元に返すデータを含めることができます。

バックグラウンド ジョブのパーティション分割

既存のコンピューティング インスタンスにバックグラウンド ジョブを含める場合は、これらの変更がコンピューティング インスタンスとバックグラウンド ジョブの品質属性にどのように影響するかを検討してください。 既存のコンピューティング インスタンスとタスクを併置するか、別のコンピューティング インスタンスに分割するかを決定するには、次の要因を考慮してください。

  • 可用性: バックグラウンド タスクでは、アプリケーションの他の部分、特にユーザー操作を直接含む UI やパーツと同じレベルの可用性が必要ない場合があります。 バックグラウンド タスクでは、待機時間、再試行された接続エラー、および操作をキューに入れることができるため、可用性に影響するその他の要因に対する許容度が高くなる可能性があります。 ただし、キューをブロックし、アプリケーション全体に影響を与える可能性のあるバックアップ要求を防ぐのに十分な容量が必要です。

  • スケーラビリティ: バックグラウンド タスクには、UI やアプリケーションの対話型部分と比較して、スケーラビリティ要件が異なる可能性があります。 需要のピークに合わせて UI をスケーリングする必要がある場合があります。 未処理のバックグラウンド タスクは、ビジー時間が短く、コンピューティング インスタンスの数が少ない場合に実行できます。

  • 回復性: バックグラウンド タスクのみをホストするコンピューティング インスタンスが失敗した場合、アプリケーション全体に致命的な影響を与えない可能性があります。 これらのタスクの要求は、タスクが使用可能になるまでキューに入れるか延期できます。 コンピューティング インスタンスまたはタスクが適切な間隔で再起動できる場合は、アプリケーション ユーザーに影響を与えない可能性があります。

  • セキュリティ: バックグラウンド タスクには、UI やアプリケーションの他の部分と比較して、セキュリティ要件や制限が異なる場合があります。 タスクに別のセキュリティ環境を指定するには、別のコンピューティング インスタンスを使用します。 セキュリティと分離を最大化するために、Gatekeeper などのパターンを使用して、バックグラウンド コンピューティング インスタンスを UI から分離することもできます。

  • パフォーマンス: タスクのパフォーマンス要件に特に一致するバックグラウンド タスクのコンピューティング インスタンスの種類を選択します。 タスクに UI と同じ処理機能が必要ない場合は、低コストのコンピューティング オプションを使用できます。 または、タスクにより多くの容量とリソースが必要な場合は、より大きなインスタンスを使用することもできます。

  • 管理容易性: バックグラウンド タスクの開発とデプロイのリズムは、メインアプリケーション コードや UI とは異なる場合があります。 更新とバージョン管理を簡略化するには、バックグラウンド タスクを別のコンピューティング インスタンスにデプロイします。

  • コスト: バックグラウンド タスクを実行するためにコンピューティング インスタンスを追加すると、ホスティング コストが増加します。 より多くの容量と追加コストのトレードオフを慎重に検討してください。

詳細については、「 リーダー選挙パターン 」と 「競合コンシューマー パターン」を参照してください。

競合

バックグラウンド ジョブのインスタンスが複数ある場合、データベースやストレージなどのリソースやサービスへのアクセスが競合する可能性があります。 この同時アクセスにより、リソースの競合が発生し、サービスの可用性の競合が発生し、ストレージ内のデータの整合性が損なわれる可能性があります。 ペシミスティック ロックアプローチを使用して、リソースの競合を解決します。 この方法により、タスクの競合するインスタンスがサービスに同時にアクセスしたり、データが破損したりするのを防ぐことができます。

競合を解決するもう 1 つの方法は、バックグラウンド タスクをシングルトンとして定義し、1 つのインスタンスのみが実行されるようにすることです。 ただし、この方法により、複数インスタンス構成で提供される信頼性とパフォーマンスの利点がなくなります。 この欠点は、UI が複数のバックグラウンド タスクをビジー状態に保つために十分な作業を提供する場合に特に当てはまります。

バックグラウンド タスクが自動的に再起動できることと、需要のピークを処理するのに十分な容量があることを確認します。 十分なリソースを持つコンピューティング インスタンスを割り当てるか、需要が減少したときに実行する要求を格納するキューメカニズムを実装するか、これらの手法を組み合わせて使用します。

調整

バックグラウンド タスクは複雑な場合があり、複数のタスクを実行する必要があります。 これらのシナリオでは、タスクを、複数のコンシューマーが実行できる小さな個別のステップまたはサブタスクに分割するのが一般的です。 多くの場合、個々のステップは複数のジョブで再利用できるため、マルチステップ ジョブの方が効率的で柔軟性が高くなります。 また、手順の順序を簡単に追加、削除、または変更することもできます。

複数のタスクとステップを調整するのは困難な場合がありますが、ソリューションをガイドするための一般的なパターンは 3 つあります。

  • タスクを複数の再利用可能なステップに分解します。 アプリケーションは、処理する情報に対してさまざまな複雑さのさまざまなタスクを実行する必要がある場合があります。 このようなアプリケーションを実装するための簡単で柔軟性のないアプローチは、この処理をモノリシック モジュールとして実行することです。 ただし、このアプローチにより、コードのリファクタリング、最適化、またはアプリケーションで同じ処理の一部が他の場所で必要な場合に再利用する機会が減る可能性があります。 詳細については、「パイプとフィルターのパターン」を参照してください。

  • タスクの手順のオーケストレーションを管理します。 アプリケーションは、多くの手順を構成するタスクを実行する場合があり、その一部はリモート サービスを呼び出したり、リモート リソースにアクセスしたりする場合があります。 個々のステップは互いに独立している場合がありますが、タスクを実装するアプリケーション ロジックによって調整されます。 詳細については、「Scheduler Agent Supervisor パターン」を参照してください。

  • 失敗したタスク ステップの回復を管理します。 1 つ以上のステップが失敗した場合、アプリケーションは一連のステップで実行される作業を元に戻す必要があります。これにより、最終的に一貫性のある操作が定義されます。 詳細については、「 補正トランザクション パターン」を参照してください。

回復性に関する考慮事項

回復力のあるバックグラウンド タスクを作成して、アプリケーションに信頼性の高いサービスを提供します。 バックグラウンド タスクを計画および設計するときは、次の点を考慮してください。

  • バックグラウンド タスクでは、データを破損させたり、アプリケーションに不整合を発生させたりすることなく、再起動を適切に処理する必要があります。 実行時間の長いタスクまたは複数ステップのタスクの場合は、 チェックポイントの使用を検討してください。 チェックポイントを使用して、ジョブの状態を永続ストレージに保存するか、キュー内のメッセージとして保存します。 たとえば、キュー内のメッセージに状態情報を格納し、タスクの進行状況でこの状態情報を増分更新できます。 タスクは、最初から再起動するのではなく、最後の既知のチェックポイントから処理できます。

    Service Bus キューの場合は、この目的でメッセージ セッションを使用します。 メッセージ セッションでは、 SetState メソッドと GetState メソッドを使用して、アプリケーションの処理状態を保存して取得します。 信頼性の高いマルチステップ プロセスとワークフローの設計の詳細については、「 Scheduler Agent Supervisor パターン」を参照してください。

  • バックグラウンド タスクとのやり取りにキューを使っている場合、普段よりも高い負荷がアプリケーションにかかっているときにはキューがバッファーとして働き、タスクに送られた要求を溜めておくことができます。 タスクはビジー状態の少ない期間中に UI に追いつく可能性があり、再起動しても UI はブロックされません。 詳細については、「キュー ベースの負荷平準化パターン」を参照してください。 一部のタスクが他のタスクよりも重要な場合は、 優先度キュー パターン を実装して、これらのタスクが最初に実行されるようにすることを検討してください。

メッセージ

メッセージによって開始されるバックグラウンド タスク、またはメッセージを処理して不整合を処理するバックグラウンド タスク (順不同で到着したメッセージ、エラーを繰り返し発生させるメッセージ (有害メッセージ)、複数回配信されるメッセージなど) を構成します。 次の推奨事項を検討してください。

  • 既存のデータ値に基づいてデータを変更するメッセージなど、メッセージを特定の順序で処理する必要がある場合があります。たとえば、既存の値に値を追加する場合などです。 メッセージは、送信された順序で常に到着するとは限りません。 また、バックグラウンド タスクのインスタンスによって、各インスタンスの負荷が異なるため、メッセージが異なる順序で処理される場合があります。

    特定の順序で処理する必要があるメッセージの場合は、シーケンス番号、キー、またはバックグラウンド タスクがメッセージを正しい順序で処理するために使用できる別のインジケーターを含めます。 Service Bus の場合は、メッセージ セッションを使用して、配信の正しい順序を保証します。 メッセージの順序が重要でないように、プロセスを設計する方が効率的です。 詳細については、「 メッセージシーケンスとタイムスタンプ」を参照してください。

  • 通常、バックグラウンド タスクはキュー内のメッセージをピークし、他のメッセージ コンシューマーから一時的に非表示にします。 タスクがメッセージを正常に処理すると、メッセージが削除されます。 バックグラウンド タスクがメッセージを処理するときに失敗した場合、ピーク タイムアウトの有効期限が切れると、そのメッセージがキューに再び表示されます。 タスクの別のインスタンスがメッセージを処理するか、元のインスタンスの次の処理サイクルでメッセージを処理します。

    メッセージがコンシューマーで一貫してエラーを引き起こす場合は、タスク、キュー、およびキューがいっぱいになったときに最終的にアプリケーション自体をブロックします。 キューから有害メッセージを検出して削除することが重要です。 Service Bus を使用する場合は、有害メッセージを関連付けられている 配信不能キューに自動的または手動で移動します。

  • キューは 少なくとも 1 回 の配信メカニズムですが、同じメッセージを複数回配信する場合があります。 バックグラウンド タスクがメッセージを処理した後、キューから削除する前に失敗した場合、メッセージは再び処理できます。

    バックグラウンド タスクはべき等である必要があります。つまり、タスクが同じメッセージを複数回処理しても、アプリケーションのデータにエラーや不整合が発生することはありません。 格納されている値が特定の新しい値に設定されている場合など、一部の操作は当然べき等です。 ただし、一部の操作では不整合が発生します。たとえば、格納されている値がメッセージの最初の送信時と同じであることを確認せずに、既存の格納値に値が追加された場合などです。 重複したメッセージを自動的に削除するように Service Bus キューを構成します。 詳細については、「 べき等メッセージ処理」を参照してください。

  • Azure Storage キューや Service Bus キューなどの一部のメッセージング システムでは、キューからのメッセージの読み取り回数を示すデキューカウント プロパティがサポートされています。 このデータは、繰り返されるメッセージや有害メッセージを処理するのに役立ちます。 詳細については、「 非同期メッセージングの入門 パターンと べき等性パターン」を参照してください。

スケーリングとパフォーマンスの考慮事項

バックグラウンド タスクは、システムが負荷がかかっているときにアプリケーションをブロックしたり、操作を遅延させたりしないように、十分なパフォーマンスを提供する必要があります。 通常、バックグラウンド タスクをホストするコンピューティング インスタンスをスケーリングすると、パフォーマンスが向上します。 バックグラウンド タスクを計画および設計するときは、スケーラビリティとパフォーマンスに関連する次の点を考慮してください。

  • Azure Virtual Machinesと Azure App Service のWeb Apps機能は、デプロイをホストできます。 自動スケーリング (スケールアウトとスケールインの両方) がサポートされています。 自動スケーリングは、需要と負荷、または定義済みのスケジュールによって決まります。 自動スケーリングを使用すると、実行時コストを最小限に抑えながら、アプリケーションに十分なパフォーマンス機能があることを確認できます。

  • 一部のバックグラウンド タスクでは、UI やコンポーネント (データ アクセス層など) など、アプリケーションの他の部分とは異なるパフォーマンス機能があります。 そのシナリオでは、UI タスクとバックグラウンド タスクを個別にスケーリングして負荷を管理できるように、バックグラウンド タスクを別のコンピューティング サービスで一緒にホストします。 複数のバックグラウンド タスクのパフォーマンス機能が大幅に異なる場合は、それらを分割し、各種類を個別にスケーリングします。 この手法により、ランタイム コストが増加する可能性があります。

  • 負荷の下でのパフォーマンスの損失を防ぐために、処理チェーンの 1 つのポイントがボトルネックを引き起こさないように、ストレージ キューやその他のリソースをスケーリングする必要がある場合もあります。 ストレージの最大スループットや、アプリケーションやバックグラウンド タスクが依存するその他のサービスなど、他の制限事項を考慮してください。

  • スケーリング用のバックグラウンド タスクを設計する。 たとえば、バックグラウンド タスクでは、メッセージを監視したり、適切なキューにメッセージを送信したりするために、使用されているストレージ キューの数を動的に検出する必要があります。

  • 既定では、WebJob は関連付けられた Web Apps インスタンスでスケーリングされます。 ただし、Web ジョブを 1 つのインスタンスとしてのみ実行する場合は、JSON データ { "is_singleton": true }を含む Settings.job ファイルを作成できます。 このメソッドは、関連付けられた Web アプリのインスタンスが複数ある場合でも、Azure で WebJob の 1 つのインスタンスのみを実行するように強制します。 この手法は、1 つのインスタンスとしてのみ実行する必要があるスケジュールされたジョブに役立ちます。

  • バックグラウンド ジョブでは、特にバックグラウンド タスクが互いまたは他のデータ ソースに依存している場合に、データ同期とプロセス調整の課題が発生する可能性があります。 たとえば、バックグラウンド ジョブでは、データ整合性の問題、競合状態、デッドロック、タイムアウトが処理される場合があります。

  • バックグラウンド タスクの結果がユーザーに表示される場合、バックグラウンド ジョブはユーザー エクスペリエンスに影響を与える可能性があります。 たとえば、バックグラウンド ジョブでは、ユーザーが通知を待機したり、ページを更新したり、タスクの状態を手動でチェックしたりする必要がある場合があります。 これらの動作により、ユーザー操作の複雑さが増し、ユーザー エクスペリエンスに悪影響を及ぼす可能性があります。

トレードオフ: バックグラウンド ジョブでは、システムにより多くのコンポーネントと依存関係が導入されるため、ソリューションの複雑さとメンテナンス コストが増加する可能性があります。 たとえば、バックグラウンド ジョブには、個別のキュー サービス、ワーカー サービス、監視サービス、再試行メカニズムが必要な場合があります。

Azure ファシリテーション

次のセクションでは、バックグラウンド ジョブのホスト、実行、構成、管理に使用できる Azure サービスについて説明します。

ホスト環境

バックグラウンド タスクをホストできる Azure プラットフォーム サービスがいくつかあります。

  • Web Appsと WebJobs: App Serviceの WebJobs 機能を使用して、Web アプリで実行できるさまざまなスクリプトまたはプログラムに基づくカスタム ジョブを実行します。

  • Azure Functions: 長時間実行されないバックグラウンド ジョブには関数アプリを使用します。 また、使用率の低いApp Serviceプランでワークロードをホストする場合は、関数アプリを使用することもできます。

  • Virtual Machines: Windows サービスを使用している場合、または Windows タスク スケジューラを使用する場合は、専用 VM でバックグラウンド タスクをホストします。

  • Azure Batch: Batch は、VM のマネージド コレクションで実行するコンピューティング集中型の作業をスケジュールするために使用できるプラットフォーム サービスです。 自動的にコンピューティング リソースを拡張できます。

  • Azure Kubernetes Service (AKS): AKS は、Azure 上の Kubernetes 用のマネージド ホスティング環境を提供します。

  • Azure Container Apps: Container Apps を使用すると、コンテナーに基づくサーバーレス マイクロサービスを構築できます。

次のセクションでは、最適なオプションを選択するのに役立つ各オプションに関する考慮事項について説明します。

Web Appsと Web ジョブ

WebJobs 機能を使用して、カスタム ジョブを Web アプリでバックグラウンド ジョブとして実行できます。 WebJob は、Web アプリのコンテキストで継続的なプロセスとして実行されます。 WebJob は、Logic Apps からのトリガー イベントや、ストレージ BLOB やメッセージ キューの変更などの外部要因に応答して実行することもできます。 Web ジョブは、オンデマンドで開始および停止し、正常にシャットダウンできます。 継続的に実行されている Web ジョブが失敗した場合は、自動的に再起動されます。 再試行アクションとエラー アクションを構成できます。

Web ジョブを構成する際の注意事項を次に示します。

  • ジョブがイベント ドリブン トリガーに応答する場合は、それを [継続的に実行] に構成します。 スクリプトまたはプログラムは、site/wwwroot/app_data/jobs/continuous という名前のフォルダーに格納されます。

  • ジョブがスケジュール駆動型トリガーに応答する場合は、スケジュールに従って 実行するように構成します。 スクリプトまたはプログラムは、"site/wwwroot/app_data/jobs/triggered" という名前のフォルダーに格納されます。

  • ジョブを構成するときに [ オンデマンドで実行 ] オプションを選択した場合、ジョブの開始時 に [スケジュールで実行 ] オプションと同じコードが実行されます。

WebJob は、Web アプリのサンドボックスで実行されます。 環境変数にアクセスでき、接続文字列などの情報を Web アプリと共有できます。 WebJob は、WebJob を実行するマシンの一意識別子にアクセスできます。 という名前AzureWebJobsStorageの接続文字列は、アプリケーション データのストレージ キュー、BLOB、およびテーブルへのアクセスを提供します。 また、メッセージングと通信のために Service Bus にアクセスすることもできます。 という名前AzureWebJobsDashboardの接続文字列は、WebJob アクション ログ ファイルへのアクセスを提供します。

Web ジョブには、次の特性があります。

  • セキュリティ: Web アプリのデプロイ資格情報は、WebJobs の保護を提供します。

  • サポートされているファイルの種類: コマンド スクリプト (.cmd)、バッチ ファイル (.bat)、PowerShell スクリプト (.ps1)、Bash シェル スクリプト (.sh)、PHP スクリプト (.php)、Python スクリプト (.py)、JavaScript コード (.js)、実行可能プログラム (.exe および .jar) を使用して WebJobs を定義します。

  • デプロイ: スクリプトと実行可能ファイルは、Azure portal、Visual Studio、または WebJobs SDK を使用して展開することも、次の場所に直接コピーすることもできます。

    • トリガーされた展開の場合: site/wwwroot/app_data/jobs/triggered/<job name>

    • 継続的デプロイの場合: site/wwwroot/app_data/jobs/continuous/<job name>

  • ログ ファイル: Console.Out として扱われるか、 INFOマークされます。 Console.Error は として ERROR扱われます。 ポータルを使用して、監視と診断情報にアクセスします。 Web サイトからログ ファイルを直接ダウンロードします。 ログ ファイルは、次の場所に保存されます。

    • トリガーされたデプロイの場合: Vfs/data/jobs/triggered/<job name>

    • 継続的配置の場合: Vfs/data/jobs/continuous/<job name>

  • 構成: ポータル、REST API、PowerShell を使用して Web ジョブを構成します。 webJob スクリプトと同じルート ディレクトリにある settings.job という名前の構成ファイルを使用して、WebJob の構成情報を提供します。 例:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Web Appsと Web ジョブに関する考慮事項

  • 既定では、Web アプリをスケーリングすると Web ジョブもスケーリングされます。 1 つのインスタンスで実行するように WebJobs を構成するには、構成プロパティを is_singleton に true設定します。 単一インスタンス Web ジョブは、インデックスの再作成やデータ分析など、同時に複数のインスタンスとしてスケーリングまたは実行したくないタスクに役立ちます。

  • Web ジョブが Web アプリのパフォーマンスに及ぼす影響を最小限に抑えるには、実行時間の長い Web ジョブまたはリソースを大量に消費する Web ジョブをホストする新しいApp Serviceプランで空の Web アプリ インスタンスを作成します。

Azure Functions

Azure Functionsは WebJobs に似ています。 Azure Functionsはサーバーレスであり、短期間実行されるイベント ドリブン トリガーに最適です。 指定した時刻に実行するように関数を構成する場合は、Azure Functionsを使用して、タイマー トリガーを使用してスケジュールされたジョブを実行することもできます。

Azure Functionsは、関数が予期しないタイムアウトを引き起こす可能性があるため、実行時間の長い大規模なタスクには推奨されません。 ただし、ホスティング プランによっては、スケジュール駆動型トリガーに関数を使用することを検討してください。

Azure Functionsに関する考慮事項

イベントに応答してバックグラウンド タスクが短時間実行される場合は、従量課金プランでタスクを実行することを検討してください。 ランタイムは最大時間に構成できます。 関数の実行時間が長いほどコストが高くなります。 より多くのメモリを消費する CPU 負荷の高いジョブは、コストが高くなる可能性があります。 タスクの一部としてサービスに追加のトリガーを使用すると、個別に課金されます。

Premium プランは、短くても継続的に実行される複数のタスクがある場合に適しています。 このプランでは、より多くのメモリと CPU が必要になるため、コストが高くなります。 利点として、仮想ネットワーク統合などの他の機能を使用できます。

専用プランは、ワークロードが既に専用プランで実行されている場合は、バックグラウンド ジョブに適しています。 使用率の低い VM がある場合は、同じ VM で専用プランを実行し、コンピューティング コストを共有できます。

詳細については、次を参照してください。

Virtual Machines

バックグラウンド タスクを実装して、Web Appsにデプロイされないようにすることができます。 たとえば、Windows サービス、サードパーティのユーティリティ、または実行可能プログラムを使用してタスクを実装できます。 アプリケーションをホストする環境とは異なるランタイム環境用に作成されたプログラムを使用することもできます。 たとえば、Windows または .NET アプリケーションから実行する Unix または Linux プログラムを使用できます。 Azure VM 用のいくつかのオペレーティング システムから選択し、その VM でサービスまたは実行可能ファイルを実行します。

詳細については、次を参照してください。

別の VM でバックグラウンド タスクを開始するには、次の操作を行います。

  • アプリケーションから直接タスクをオンデマンドで実行するために、タスクが公開するエンドポイントに要求を送信します。 要求は、タスクに必要なデータを転送します。 エンドポイントによってタスクが呼び出されます。

  • 選択したオペレーティング システムのスケジューラまたはタイマーを使用して、スケジュールに従って実行するようにタスクを構成します。 たとえば、Windows では、Windows タスク スケジューラを使用してスクリプトとタスクを実行できます。 VM にSQL Serverがインストールされている場合は、SQL Server エージェントを使用してスクリプトとタスクを実行します。

  • Logic Apps を使用してタスクを開始するには、タスクが監視するキューにメッセージを追加するか、タスクが公開する API に要求を送信します。

バックグラウンド タスクを開始する方法の詳細については、前のトリガーに関 するセクションを 参照してください。

Virtual Machinesに関する考慮事項

Azure VM にバックグラウンド タスクをデプロイする場合は、次の点を考慮してください。

  • バックグラウンド タスクを別の Azure VM でホストし、開始、デプロイ、スケジュール、リソース割り当てを柔軟かつ正確に制御できるようにします。 ただし、バックグラウンド タスク専用に VM をデプロイすると、ランタイム コストが増加します。

  • ポータルでタスクを監視する機能はなく、失敗したタスクの自動再起動機能もありません。 ただし、Azure Resource Manager コマンドレットを使用して、VM の状態を監視して管理できます。 コンピューティング ノード内のプロセスとスレッドを制御する機能はありません。 通常、VM を使用する場合は、タスクのインストルメンテーションから、および VM のオペレーティング システムからデータを収集するメカニズムを実装する必要があります。 この目的のために、 System Center Management Pack for Azure を使用できます。

  • HTTP エンドポイントを介して公開される監視プローブを作成することを検討してください。 正常性チェックを実行し、運用情報と統計を収集するように、これらのプローブのコードを構成できます。 また、プローブを使用してエラー情報を照合し、管理アプリケーションに返すこともできます。

詳細については、次を参照してください。

Batch

大規模で並列なハイ パフォーマンス コンピューティング (HPC) ワークロードを数十、数百、または数千の VM にわたって実行する必要がある場合は、 Batch を検討してください。

Batch を使用して、VM の準備、VM へのタスクの割り当て、タスクの実行、進行状況の監視、ワークロードに応じて VM の自動スケールアウトを行います。 Batch では、ジョブのスケジュール設定も提供され、Linux VM と Windows VM もサポートされます。

バッチに関する考慮事項

Batch は、本質的に並列ワークロードに適しています。 Batch を使用すると、最後に reduce ステップを使用して並列計算を実行したり、ノード間でメッセージを渡す必要がある並列タスクに対して メッセージパッシング インターフェイス (MPI) アプリケーション を実行したりできます。

Batch ジョブは、ノードまたは VM のプールで実行されます。 プールは、必要な場合にのみ割り当ててから、ジョブの完了後に削除できます。 この方法では、ノードがアイドル状態ではなく、ジョブがノードの割り当てを待機する必要があるため、使用率が最大化されます。 または、プールを事前に作成することもできます。 この方法により、ジョブの開始にかかる時間が最小限に抑えられますが、ノードがアイドル状態になる可能性があります。

詳細については、次を参照してください。

Azure Kubernetes Service

AKS を使用してホストされている Kubernetes 環境を管理し、コンテナー化されたアプリケーションを簡単にデプロイおよび管理できるようにします。

コンテナーは、バックグラウンド ジョブを実行する場合に便利です。 次の利点があります。

  • コンテナーは、高密度のホストをサポートします。 各 VM に複数のコンテナーを配置して、コンテナー内のバック グラウンド タスクを分離できます。

  • コンテナー オーケストレーターを使用して、内部負荷分散を実行し、内部ネットワークを構成し、その他の構成タスクを実行します。

  • 必要に応じてコンテナーを開始および停止できます。

  • Azure Container Registryを使用すると、Azure の境界内にコンテナーを登録して、セキュリティ、プライバシー、近接性の利点を提供できます。

AKS に関する考慮事項

AKS では、コンテナー オーケストレーターの使用方法を理解する必要があります。

詳細については、次を参照してください。

コンテナー アプリ

Container Apps を使用すると、コンテナーに基づくサーバーレス マイクロサービスを構築できます。 Container Apps:

  • 汎用コンテナー 、特にコンテナーにデプロイされている多数のマイクロサービスにまたがるアプリケーションを実行するために最適化されています。

  • Kubernetes とオープン ソース テクノロジ ( Dapr、 Kubernetes Event-driven Autoscaling (KEDA)、 Envoy など) を利用します。

  • サービス検出やトラフィック分割などの機能によって Kubernetes スタイルのアプリやマイクロサービスをサポートします。

  • トラフィックに基づくスケーリングをサポートし、 キューなどのイベント ソース (スケールをゼロにするなど) からプルすることで、イベントドリブン アプリケーション アーキテクチャを有効にします。

  • 実行時間の長いプロセスをサポートし、 バックグラウンド タスクを実行できます。

Container Apps に関する考慮事項

Container Apps では、基になる Kubernetes API への直接アクセスは提供されません。 Kubernetes API とコントロール プレーンへのアクセスが必要な場合は、 AKS を使用します。 Kubernetes スタイルのアプリケーションをビルドする場合に、ネイティブ Kubernetes API とクラスター管理に直接アクセスする必要がない場合は、Container Apps を使用してフル マネージド エクスペリエンスを実現します。 Container Apps は、コンテナー マイクロサービスの構築に最適です。

詳細については、次を参照してください。

信頼性チェックリスト

推奨事項の完全なセットを参照してください。

信頼性チェックリスト