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