0

Azure キューと Web ジョブを使用してデータをフェッチすることにより、数千のリモート XML および JSON データ ファイルの繰り返しデータ集約のソリューションを見つけようとしています。

基本的に、Azure の Web サイト/アプリでは、何らかの入力エンドポイント URL が (パラメーターとしてデータ URL を使用して) 呼び出されます。Web ジョブのバックグラウンド ジョブをトリガーし (または、継続的に実行し、新しい作業のためにキューを定期的にチェックすることができます)、データ URL を取得し、完了時に外部エンドポイント URL をコールバックする必要があります。

現在の主な関心事は、ボリュームとそのパフォーマンス/スケーリング/価格設定のオーバーヘッドです。10 ～ 60 分ごとに約 10,000 の URL が取得されます (ほとんどの URL は 60 分ごとに取得されます)。大量のバックグラウンド ジョブが繰り返されるこのシナリオに関して、いくつか質問があります。

  1. Azure WebJobs (またはワーカー?) は、この量のバックグラウンド処理の適切なオプションであり、それに応じてスケーリングできますか?

  2. この種のボリュームの場合、どの Azure Web サイト レベルが最も適しているでしょうか ( http://azure.microsoft.com/en-us/pricing/details/app-service/で比較)? それとも、この規模で機能するのはクラウドまたは VM だけですか?

提案やヒントをいただければ幸いです。

4

1 に答える 1

1

  1. はい、Azure WebJobs はこれに対する理想的なソリューションです。Azure Web ジョブは、Web アプリ (以前の Web サイト) に合わせて拡張されます。したがって、Web アプリ インスタンスを増やすと、Web ジョブ インスタンスも増えます。これを防ぐ方法はありますが、それがデフォルトの動作です。自動スケーリングをセットアップして、指定した CPU またはその他のパフォーマンス ルールに基づいて Web アプリを自動的にスケーリングすることもできます。
    また、Web フロント エンド (WFE) がデプロイされている Web アプリとは別の Web アプリに Web ジョブをデプロイすることで、Web フロント エンド (WFE) とは別に Web ジョブをスケーリングすることもできます。これには、WFE が使用しているマシン リソース (CPU、RAM) を占有しないという利点があり、Web ジョブ インスタンスを適切なレベルに柔軟にスケーリングできます。これがあなたがすべきことだと言っているのではありません。この戦略が状況に適している (または必要である) かどうかを判断するには、いくつかの負荷テストを行う必要があります。

  2. Web アプリについては、少なくとも Basic レベルを検討する必要があります。これにより、必要に応じて 3 つのインスタンスにスケールアウトでき、Free プランと Shared プランにある CPU とネットワーク I/O の制限も取り除かれます。

キューに関しては、WebJobs SDK を使用して、キューをポーリングする代わりにJobHost (SDK から) が Web ジョブ関数を呼び出すようにすることをお勧めします。これは非常に洗練されたソリューションであり、インフラストラクチャ コードを記述してキューからメッセージを取得したり、メッセージの可視性を管理したり、メッセージを削除したりする必要がなくなります。 、Azure WebJobs SDK Queuesテンプレートによって作成されるサンプル コードを見てください。

ここに画像の説明を入力

于 2015-04-22T21:48:33.157 に答える