Windows Azure Web ロールを実行していますが、ほとんどの日はトラフィックが非常に少ないのですが、実行する必要がある大量のバックグラウンド作業につながる可能性のある (予見可能な) イベントがいくつかあります。バックグラウンド作業は、多くのデータベース呼び出し (Azure SQL) と外部 Web サービスへの HTTP 呼び出しで構成されているため、実際には CPU を集中的に使用するわけではありませんが、データベースまたは Web サービスが応答するのを待機するスレッドが多数必要になります。バックグラウンド作業は、Web ロールへの通常の HTTP 要求によってトリガーされます。
これを調整するには 2 つのオプションがあると思いますが、どちらが優れているかはわかりません。
- オプション 1、スレッド:バックグラウンド作業の要求が届くと、Web ロールは必要な数のスレッドを開始します (または、個々の作業項目をスレッド プールのキューに入れます)。このオプションでは、これらのスレッドが大量のメモリを必要とする可能性があるため、ワークロードが重い場合はより大きなインスタンスを構成します。
- オプション 2、自己呼び出し:バックグラウンド作業の要求が来ると、それを受信する Web ロールは、バックグラウンド作業のすべての項目に対して自身への HTTP 要求を生成します。このオプションでは、複数の Web ロール インスタンスを構成できます。これは、Windows Azure のロード バランサーがインスタンス間で HTTP 要求のバランスを取るためです。
オプション 1 はやや単純ですが、1 つのインスタンスしかバックグラウンド作業を処理できないという欠点があります。複数の Azure インスタンスをバックグラウンド作業に参加させたい場合、ロード バランサーが作業の一部を他のインスタンスに委任できるように、役割からそれ自体に HTTP 要求を送信する以外に選択肢はありません。
多分他のオプションがありますか？
編集:オプション 2 に関するその他の考え: バックグラウンド作業の要求が来ると、それを受け取ったインスタンスは、何らかの種類のキュー (Windows Azure キューまたはタスクとして機能する SQL テーブル) で実行される作業を保存します。列）。次に、ロード バランサーがすべてのロール インスタンスを「アクティブ化」するように、それ自体に対して大量の HTTP 要求を生成します。次に、各インスタンスはキューからタスクをデキューしてタスクを実行し、すべてのタスクが完了するまで次のタスクをフェッチします。Web ロールを worker ロールとして時々使用するようなものです。
このアプローチには臭い (Web ロールをワーカー ロールとして悪用し、同じ Web ロールへの HTTP 要求) があることは承知していますが、本当の欠点はわかりません。
EDIT 2:アプリの正確な状況についてもう少し詳しく説明する必要があることがわかりました。
アプリは常にいくつかの小さなタスクを実行する必要があります。これらのタスクは通常、1 ～ 10 秒以上かかることはなく、多くの CPU 作業を必要としません。通常の日には 50 ～ 100 のタスクしかありませんが、「特別な日」 (正月はその 1 つです) には、1 ～ 2 の範囲内で実行する必要がある数 10,000 のタスクに入る可能性があります。時間ウィンドウ。タスクは Web ロールで実行され、毎分タスクを開始するCron ジョブがあります。そのため、Web ロールは新しいタスクを処理するためのリクエストを毎分受信するため、どのタスクを処理する必要があるかを確認し、それらをある種のキューに追加します (現在、これは OUTPUT INSERTED を使用した UPDATE を含む SQL テーブルですが、切り替える予定です)いつか Azure Queues に)。現在、同じインスタンスがタスクを処理しますそれらをキューに入れた直後ですが、数万のタスクの連続処理には時間がかかりすぎるため、これはスケーリングしません。これが、 「タスクが利用可能です」というイベントを最初のインスタンスから他のインスタンスにブロードキャストするメカニズムを探している理由です。