このガイドでは、バックグラウンド ジョブの開発に関するレコメンデーションについて説明します。 バックグラウンド ジョブは、ユーザーの操作を必要とせずに自動的に実行されます。 多くのアプリケーションでは、UI とは無関係に実行されるバックグラウンド ジョブが必要です。
バックグラウンド ジョブの例としては、バッチ ジョブ、集中的な処理タスク、ワークフローなどの長時間実行されるプロセスなどがあります。 アプリケーションはジョブを開始し、ユーザーからの対話型要求を処理します。 たとえば、アプリケーションでユーザーがアップロードする画像のサムネイルを生成する必要がある場合は、バックグラウンド ジョブを実行してサムネイルを生成し、ストレージに保存することができます。 ユーザーはプロセスが完了するまで待つ必要はありません。 別の例として、顧客は注文を行い、注文を処理するバックグラウンド ワークフローを開始します。 バックグラウンド ジョブの実行中、顧客は引き続き Web アプリを参照します。 バックグラウンド ジョブが完了すると、保存されている注文データが更新され、注文を確認する電子メールが顧客に送信されます。
アプリケーション UI の負荷を最小限に抑え、可用性を向上させ、対話型の応答時間を短縮するバックグラウンド ジョブ。
バックグラウンド ジョブとして指定するタスクを選択するには、タスクがユーザーの操作なしで実行されるかどうか、および UI がタスクの完了を待機する必要があるかどうかを考慮します。 ユーザーまたは UI が実行中に待機する必要があるタスクは、通常、適切なバックグラウンド ジョブではありません。
バックグラウンド ジョブの必要性を評価する
バックグラウンド ジョブの例は次のとおりです。
数学的計算や構造モデル分析などの CPU 負荷の高いジョブ。
一連のストレージ トランザクションの実行やファイルのインデックス作成など、I/O 集中型ジョブ。
夜間のデータ更新やスケジュールされた処理などのバッチ ジョブ。
注文処理やサービスおよびシステムのプロビジョニングなどの長時間実行されるワークフロー。
タスクをより安全な場所に転送して処理する機密データ処理。 たとえば、Web アプリ内で機密データを処理したくない場合があります。 代わりに、 Gatekeeper パターン などのパターンを使用して、保護されたストレージにアクセスできる分離されたバックグラウンド プロセスにデータを転送できます。
適切なトリガーを選択する
バックグラウンド ジョブを開始するには:
イベント ドリブン トリガー: イベント (通常はユーザー アクションまたはワークフロー内のステップ) によってタスクがトリガーされます。
スケジュール駆動型トリガー: タイマーに基づくスケジュールによってタスクが呼び出されます。 ジョブは定期的に、または 1 回の実行としてスケジュールできます。
イベント駆動型トリガー
アクションは、バックグラウンド タスクを開始するイベント駆動型の呼び出しをトリガーします。 イベント駆動型トリガーの例は次のとおりです:
UI または別のジョブは、 WebQueue-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 の場合は、
ReplyToプロパティとCorrelationIdプロパティを使用して、この機能を実装します。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がブロックされることはありません。 詳細については、「 Queue-Based 負荷平準化パターン」を参照してください。 一部のタスクが他のタスクよりも重要な場合は、 優先度キュー パターン を実装して、これらのタスクが最初に実行されるようにすることを検討してください。
Messages
メッセージによって開始されるバックグラウンド タスク、またはメッセージを処理して不一致を処理するバックグラウンド タスク (順不同で到着したメッセージ、エラーが繰り返し発生するメッセージ (有害メッセージ)、複数回配信されるメッセージなど) を構成します。 次の推奨事項を検討してください。
既存のデータ値に基づいてデータを変更するメッセージなど、メッセージを特定の順序で処理する必要がある場合があります。たとえば、既存の値に値を追加する場合などです。 メッセージは、送信された順序で常に到着するとは限りません。 また、バックグラウンド タスクのインスタンスによって、各インスタンスの負荷が異なるため、メッセージが異なる順序で処理される場合があります。
特定の順序で処理する必要があるメッセージの場合は、シーケンス番号、キー、またはバックグラウンド タスクがメッセージを正しい順序で処理するために使用できる別のインジケーターを含めます。 Service Bus の場合は、メッセージ セッションを使用して、配信の正しい順序を保証します。 メッセージの順序が重要でないように、プロセスを設計する方が効率的です。 詳細については、メッセージの シーケンス処理とタイムスタンプを参照してください。
通常、バックグラウンド タスクはキュー内のメッセージをチェックし、他のコンシューマーから一時的に見えなくなります。 タスクがメッセージを正常に処理すると、メッセージが削除されます。 バックグラウンド タスクがメッセージを処理するときに失敗した場合、ピーク タイムアウトの有効期限が切れると、そのメッセージがキューに再び表示されます。 タスクの別のインスタンスがメッセージを処理するか、元のインスタンスの次の処理サイクルでメッセージを処理します。
メッセージがコンシューマーで一貫してエラーを引き起こす場合は、タスク、キュー、およびキューがいっぱいになったときに最終的にアプリケーション自体をブロックします。 キューから有害メッセージを検出して削除することが重要です。 Service Bus を使用する場合は、有害メッセージを関連付けられている 配信不能キューに自動的または手動で移動します。
キューは 少なくとも 1 回 の配信メカニズムですが、同じメッセージを複数回配信する場合があります。 バックグラウンド タスクがメッセージを処理した後、キューから削除する前に失敗した場合、メッセージは再度処理できます。
バックグラウンド タスクはべき等である必要があります。つまり、タスクが同じメッセージを複数回処理しても、アプリケーションのデータにエラーや不整合が発生することはありません。 いくつかの操作は元々冪等であり、たとえば格納された値が特定の新しい値に設定される場合などがそれに当たります。 ただし、一部の操作では不整合が発生します。たとえば、格納されている値がメッセージの最初の送信時と同じであることを確認せずに、既存の格納された値に値を追加した場合などです。 重複したメッセージを自動的に削除するように Service Bus キューを構成します。 詳細については、「Idempotent message processing」を参照してください。
Azure Storage キューや Service Bus キューなどの一部のメッセージング システムでは、キューからのメッセージの読み取り回数を示すデキューカウント プロパティがサポートされています。 このデータは、繰り返しメッセージや有害メッセージを処理するのに役立ちます。 詳細については、「 非同期メッセージングの入門 パターンと べき等性パターン」を参照してください。
ジョブをスケーラブルにする
バックグラウンド タスクは、システムに負荷がかかっているときにアプリケーションをブロックしたり操作を遅らせたりしないように、十分なパフォーマンスを提供する必要があります。 通常、バックグラウンド タスクをホストするコンピューティング インスタンスをスケーリングすると、パフォーマンスが向上します。 バックグラウンド タスクを計画および設計するときは、スケーラビリティとパフォーマンスに関連する次の点を考慮してください。
Azure Virtual Machines と Azure App Service の Web Apps 機能は、デプロイをホストできます。 スケール アウトとスケールインの両方で、自動スケーリングがサポートされます。 自動スケーリングは、需要と負荷、または定義済みのスケジュールによって決まります。 自動スケーリングを使用すると、実行時のコストを最小限に抑えながら、アプリケーションに十分なパフォーマンス機能があることを確認できます。
一部のバックグラウンド タスクでは、UI やコンポーネント (データ アクセス 層など) など、アプリケーションの他の部分とは異なるパフォーマンス機能があります。 そのシナリオでは、UI タスクとバックグラウンド タスクを個別にスケーリングして負荷を管理できるように、バックグラウンド タスクを個別のコンピューティング サービスで一緒にホストします。 複数のバックグラウンド タスクのパフォーマンス機能が大幅に異なる場合は、それらを分割し、各種類を個別にスケーリングします。 この手法により、実行時コストが増加する可能性があります。
負荷がかかっているパフォーマンスの損失を防ぐために、処理チェーンの 1 つのポイントがボトルネックを引き起こさないように、ストレージ キューやその他のリソースをスケーリングすることが必要になる場合もあります。 ストレージの最大スループットや、アプリケーションやバックグラウンド タスクが依存するその他のサービスなど、その他の制限事項を考慮してください。
スケーリング用のバックグラウンド タスクを設計する。 たとえば、バックグラウンド タスクでは、メッセージを監視したり、適切なキューにメッセージを送信したりするために、使用されているストレージ キューの数を動的に検出する必要があります。
既定では、Web ジョブは、関連付けられている Web Apps インスタンスに合わせてスケーリングされます。 ただし、Web ジョブを 1 つのインスタンスとしてのみ実行する場合は、JSON データ
{ "is_singleton": true }を含む Settings.job ファイルを作成できます。 このメソッドは、関連付けられている Web アプリのインスタンスが複数ある場合でも、Azure で Web ジョブのインスタンスを 1 つだけ実行するように強制します。 この手法は、1 つのインスタンスとしてのみ実行する必要があるスケジュールされたジョブに役立ちます。バックグラウンド ジョブは、特にバックグラウンド タスクが相互に依存している場合、または他のデータ ソースに依存している場合、データの同期とプロセスの調整に課題をもたらす可能性があります。 たとえば、バックグラウンド ジョブは、データの整合性の問題、競合状態、デッドロック、またはタイムアウトを処理する場合があります。
バックグラウンド タスクの結果がユーザーに表示される場合、バックグラウンド ジョブはユーザー エクスペリエンスに影響を与える可能性があります。 たとえば、バックグラウンド ジョブでは、ユーザーが通知を待ったり、ページを更新したり、タスクのステータスを手動で確認したりする必要がある場合があります。 これらの動作により、ユーザー操作の複雑さが増し、ユーザー エクスペリエンスに悪影響を与える可能性があります。
トレードオフ: バックグラウンド ジョブは、システムに多くのコンポーネントと依存関係をもたらし、ソリューションの複雑性とメンテナンス コストを増大させる可能性があります。 たとえば、バックグラウンド ジョブには、個別のキュー サービス、ワーカー サービス、監視サービス、再試行メカニズムが必要な場合があります。
Azure ファシリテーション
以降のセクションでは、バックグラウンド ジョブのホスト、実行、構成、管理に使用できる Azure サービスについて説明します。
ホスト環境
バックグラウンド タスクをホストできる Azure プラットフォーム サービスがいくつかあります。
Web Apps と WebJobs: App Service の WebJobs 機能を使用して、Web アプリで実行できるさまざまなスクリプトまたはプログラムに基づくカスタム ジョブを実行します。
Azure Functions: 長時間実行されないバックグラウンド ジョブには関数アプリを使用します。 使用率の低い App Service プランでワークロードをホストする場合は、関数アプリを使用することもできます。
Azure Logic Apps: 複数のサービスとシステム間のオーケストレーションを必要とするバックグラウンド ジョブにロジック アプリを使用します。
仮想マシン: Windows サービスを使用している場合、または Windows タスク スケジューラを使用する場合は、専用 VM でバックグラウンド タスクをホストします。
Azure Batch: Batch は、コンピューティング集中型の作業を VM のマネージド コレクションで実行するようにスケジュールするために使用できるプラットフォーム サービスです。 コンピューティング リソースを自動的にスケーリングできます。
Azure Kubernetes Service (AKS):AKS は、Azure 上の Kubernetes 用のマネージド ホスティング環境を提供します。
Azure Container Apps: Container Apps を使用すると、コンテナーに基づくサーバーレス マイクロサービスを構築できます。
次のセクションでは、最適なオプションの選択に役立つ、これらの各オプションに関する考慮事項について説明します。
Web Apps と WebJobs
Web ジョブ機能を使用して、Web アプリでカスタム ジョブをバックグラウンド ジョブとして実行できます。 Web ジョブは、Web アプリのコンテキストで継続的なプロセスとして実行されます。 Web ジョブは、Logic Apps からのトリガー イベントや、ストレージ BLOB やメッセージ キューの変更などの外部要因に応答して実行することもできます。 Web ジョブは、必要に応じて開始および停止し、正常にシャットダウンできます。 継続的に実行されている Web ジョブが失敗すると、自動的に再起動されます。 再試行アクションとエラー アクションを構成できます。
Web ジョブを構成する場合:
ジョブがイベント ドリブン トリガーに応答する場合は、 継続的に実行するように構成します。 スクリプトまたはプログラムは、site/wwwroot/app_data/jobs/continuous という名前のフォルダーに格納されます。
ジョブがスケジュールドリブン トリガーに応答する場合は、スケジュール に従って実行するように構成します。 スクリプトまたはプログラムは、site/wwwroot/app_data/jobs/triggered という名前のフォルダーに格納されます。
ジョブを構成するときに [ オンデマンドで実行 ] オプションを選択した場合は、ジョブの開始時 に [スケジュール時に実行 ] オプションと同じコードが実行されます。
Web ジョブは、Web アプリのサンドボックス内で実行されます。 環境変数にアクセスでき、接続文字列などの情報を Web アプリと共有できます。 WebJob は、それを実行するコンピュータの固有の識別子にアクセスできます。
AzureWebJobsStorageという名前の接続文字列は、アプリケーション データのストレージ キュー、BLOB、およびテーブルへのアクセスを提供します。 また、メッセージングと通信のために Service Bus にアクセスすることもできます。
AzureWebJobsDashboardという名前の接続文字列は、WebJob アクション ログ ファイルへのアクセスを提供します。
Web ジョブには、次の特性があります。
セキュリティ: Web アプリのデプロイ資格情報は、Web ジョブの保護を提供します。
サポートされるファイルの種類: コマンド スクリプト (.cmd)、バッチ ファイル (.bat)、PowerShell スクリプト (.ps1)、Bash シェル スクリプト (.sh)、PHP スクリプト (.php)、Python スクリプト (.py)、JavaScript コード (.js)、実行可能プログラム (.exe および.jar) を使用して Web ジョブを定義します。
デプロイ: Azure portal、 Visual Studio、または WebJobs SDK を使用してスクリプトと実行可能ファイルをデプロイすることも、次の場所に直接コピーすることもできます。
トリガーされた展開の場合: site/wwwroot/app_data/jobs/triggered/<ジョブ名>
継続的デプロイの場合: site/wwwroot/app_data/jobs/continuous/<job name>
ログ ファイル:
Console.Outは、INFOとして扱われるか、マークされます。Console.ErrorはERRORとして扱われます。 ポータルを使用して、監視と診断の情報にアクセスします。 Web サイトから直接ログ ファイルをダウンロードします。 ログ ファイルは、次の場所に保存されます。トリガーされたデプロイの場合: Vfs/data/jobs/triggered/<ジョブ名>
継続的デプロイの場合: Vfs/data/jobs/continuous/<job name>
構成: ポータル、REST API、PowerShell を使用して Web ジョブを構成します。 webJob スクリプトと同じルート ディレクトリにある settings.job という名前の構成ファイルを使用して、Web ジョブの構成情報を提供します。 例えば次が挙げられます。
{ "stopping_wait_time": 60 }{ "is_singleton": true }
Web Apps と WebJobs に関する考慮事項
既定では、Web ジョブは Web アプリを使用してスケーリングされます。 1 つのインスタンスで実行するように Web ジョブを構成するには、
is_singleton構成プロパティをtrueに設定します。 単一インスタンス Web ジョブは、インデックスの再作成やデータ分析など、同時に複数のインスタンスとしてスケーリングまたは実行したくないタスクに役立ちます。Web ジョブが Web アプリのパフォーマンスに与える影響を最小限に抑えるには、実行時間の長い Web ジョブまたはリソースを集中的に使用する Web ジョブをホストする空の Web アプリ インスタンスを新しい App Service プランに作成します。
Azure Functions
Azure Functions はサーバーレスであり、短期間実行されるイベント ドリブン トリガーに最適です。 指定した時刻に実行するように関数を構成する場合は、Azure Functions を使用してタイマー トリガーを使用してスケジュールされたジョブを実行することもできます。
複雑なワークフローと実行時間の長いプロセスを調整するには、Azure Durable Functions を使用します。 Durable Functions を使用すると、サーバーレス環境でステートフル ワークフローを定義できます。これは、調整と状態管理を必要とするバックグラウンド ジョブに特に役立ちます。
Azure Functions に関する考慮事項
イベントに応答してバックグラウンド タスクが短時間実行される場合は、従量課金プランでタスクを実行することを検討してください。 ランタイムは最大時間に構成できます。 長時間実行される関数は、より多くのコストがかかります。 より多くのメモリを消費する CPU 負荷の高いジョブは、コストが高くなる可能性があります。 タスクの一部としてサービスに追加のトリガーを使用する場合は、個別に課金されます。
Premium プランは、短くても継続的に実行されるタスクが複数ある場合に適しています。 このプランは、より多くのメモリと CPU を必要とするため、コストが高くなります。 利点として、仮想ネットワーク統合などの他の機能を使用できます。
専用プランは、ワークロードが既に専用プランで実行されている場合に、バックグラウンド ジョブに適しています。 使用率の低い VM がある場合は、同じ VM で専用プランを実行し、コンピューティング コストを共有できます。
詳細については、以下を参照してください。
Azure Logic Apps
Azure Logic Apps は、ワークフローを自動化し、さまざまなサービスを統合するための強力なプラットフォームを提供します。 これらは、複数のサービスとシステム間でオーケストレーションを必要とするバックグラウンド ジョブをホストするのに特に適しています。
Azure Logic Apps には、ワークフローを作成するためのビジュアル デザイナー、さまざまなサービスを統合するためのコネクタの膨大なライブラリ、イベント ドリブン トリガー、複雑な調整のためのステートフル ワークフロー、一時的な障害からの回復性と回復性を確保するための組み込みのエラー処理と再試行があります。
Azure Logic Apps に関する考慮事項
Logic Apps は、非同期や準長期実行の API 呼び出しなど、応答が低遅延でなくてもよいシナリオで最適に動作します。 ユーザー インターフェイスをブロックする呼び出しなど、低待機時間が必要な場合は、Azure Functions や Azure App Service にデプロイされた Web API などの別のテクノロジを使用します。
Azure Logic Apps は従量課金制の価格モデルに従います。この価格モデルは、実行されたアクションの数と使用されたコネクタに基づいて課金されます。 効率的なワークフローを設計し、Logic Apps で使用されるアクションとコネクタの数を最小限に抑えることで、コストを最適化します。
Logic Apps は、受信要求の数とワークフローの複雑さに基づいて自動的にスケーリングされます。 ただし、特にバックグラウンド ジョブに高頻度のトリガーや大量のデータが含まれる場合は、Logic Apps の調整制限とクォータに注意してください。
詳細については、以下を参照してください。
Virtual Machines
バックグラウンド タスクを実装して、Web Apps にデプロイされないようにすることができます。 たとえば、Windows サービス、サード パーティのユーティリティ、または実行可能プログラムを使用してタスクを実装できます。 また、アプリケーションをホストする環境とは異なるランタイム環境用に記述されたプログラムを使用することもできます。 たとえば、Windows または .NET アプリケーションから実行する Unix または Linux プログラムを使用できます。 Azure VM 用の複数のオペレーティング システムから選択し、その VM でサービスまたは実行可能ファイルを実行します。
詳細については、以下を参照してください。
別の VM でバックグラウンド タスクを開始するには、次の操作を行います。
アプリケーションから直接タスクをオンデマンドで実行するために、タスクが公開するエンドポイントに要求を送信します。 要求は、タスクに必要なデータを転送します。 エンドポイントによってタスクが呼び出されます。
選択したオペレーティング システムのスケジューラまたはタイマーを使用して、スケジュールに従って実行するようにタスクを構成します。 たとえば、Windows では、Windows タスク スケジューラを使用してスクリプトとタスクを実行できます。 VM に SQL Server がインストールされている場合は、SQL Server エージェントを使用してスクリプトとタスクを実行します。
Logic Apps を使用してタスクを開始するには、タスクが監視するキューにメッセージを追加するか、タスクが公開する API に要求を送信します。
バックグラウンド タスクを開始する方法の詳細については、前のトリガーのセクション を 参照してください。
仮想マシンに関する考慮事項
Azure VM にバックグラウンド タスクをデプロイする場合は、次の点を考慮してください。
バックグラウンド タスクを別の Azure VM でホストし、開始、デプロイ、スケジュール、リソース割り当てを柔軟かつ正確に制御できるようにします。 ただし、バックグラウンド タスク専用に VM をデプロイすると、ランタイム コストが増加します。
ポータルにタスクを監視する機能はなく、失敗したタスクの自動再起動機能もありません。 ただし、 Azure Resource Manager コマンドレット を使用して VM の状態を監視し、管理することができます。 コンピューティング ノード内のプロセスとスレッドを制御する機能はありません。 通常、VM を使用する場合は、タスク内のインストルメンテーションから、および VM のオペレーティング システムからデータを収集するメカニズムを実装する必要があります。 この目的には、 Azure 用 System Center 管理パック を使用できます。
HTTP エンドポイントを介して公開される監視プローブを作成することを検討してください。 正常性チェックを実行し、運用情報と統計を収集するように、これらのプローブのコードを構成できます。 また、プローブを使用してエラー情報を照合し、管理アプリケーションに返すこともできます。
詳細については、以下を参照してください。
Azure Batch
数十、数百、または数千の VM にわたって大規模で並列のハイ パフォーマンス コンピューティング (HPC) ワークロードを実行する必要がある場合は、 Batch を検討してください。
Batch を使用して、VM の準備、VM へのタスクの割り当て、タスクの実行、進行状況の監視、ワークロードに対応した VM の自動スケールアウトを行います。 Batch では、ジョブのスケジュール設定も提供され、Linux および Windows VM もサポートされます。
バッチに関する考慮事項
Batch は、本質的に並列ワークロードに適しています。 Batch を使用すると、最後に reduce ステップを使用して並列計算を実行したり、ノード間でのメッセージの受け渡しを必要とする並列タスクに対して メッセージパッシング インターフェイス (MPI) アプリケーション を実行したりできます。
Batch ジョブは、ノードまたは VM のプールで実行されます。 プールは、必要な場合にのみ割り当ててから、ジョブの完了後に削除できます。 ノードがアイドル状態にならないためこの方法で使用率を最大化できますが、作業が完了するためにノードの割り当てを待つ必要があります。 または、プールを事前に作成することもできます。 この方法では、ジョブの開始にかかる時間が最小限に抑えられますが、ノードがアイドル状態になることがあります。
詳細については、以下を参照してください。
Azure Kubernetes Service
AKS を使用してホストされている Kubernetes 環境を管理し、コンテナー化されたアプリケーションを簡単にデプロイおよび管理できるようにします。
コンテナーは、バックグラウンド ジョブの実行に役立ちます。 次のような利点があります。
コンテナーでは、高密度ホスティングがサポートされます。 各 VM に複数のコンテナーを配置しながら、コンテナー内のバックグラウンド タスクを分離できます。
コンテナー オーケストレーターを使用して、内部負荷分散を実行し、内部ネットワークを構成し、その他の構成タスクを実行します。
必要に応じて、コンテナーを開始および停止できます。
Azure Container Registry を使用すると、Azure の境界内にコンテナーを登録して、セキュリティ、プライバシー、近接性の利点を提供できます。
AKS に関する考慮事項
AKS では、コンテナー オーケストレーターの使用方法を理解する必要があります。
詳細については、以下を参照してください。
Azure 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 は、コンテナー マイクロサービスの構築に最適です。
詳細については、以下を参照してください。
関連リンク
- 補正トランザクション パターン
- 競合コンシューマー パターン
- リーダーの選択パターン
- パイプとフィルターのパターン
- 優先順位キュー パターン
- Queue-Based 負荷平準化パターン
- Scheduler Agent Supervisor パターン
信頼性チェックリスト
完全なレコメンデーションのセットを参照してください。