私はWorkerRole短時間しか仕事をしないものをいくつか持っていますが、それらをそれぞれ単一のインスタンスに入れるのはお金の無駄です. それらを 1 つにマージすることもできますが、それは面倒です。遠い将来、負荷が増加したときに独立して動作することになっています。
WorkerRole「マルチ サイト」を作成できるのと同じ方法で「マルチ ロール」を作成する方法はありますWebRoleか?
.Run()否定的なケースでは、特定のフォルダーからアセンブリをロードし、リフレクションを使用して RoleEntryPoint 派生クラスを探し、インスタンスを作成し、または.OnStart()メソッドを呼び出すことができる「マスター ワーカー ロール」を作成できると思います。この「マスター ワーカー ロール」も、予期しない例外を再スローし、マスター ロールで が呼び出されたとき.OnStop()にすべての subを呼び出します。それはうまくいくでしょうか？何を知っておくべきですか？RoleEntryPoint.OnStop()
他の人が述べたように、これはインスタンスの使用率を最大化するための非常に一般的な手法です。ワーカー インフラストラクチャと実行したい実際の作業を抽象化する例と "フレームワーク" がある場合があります 。 (「実装の内部」までスクロールします)
作業をトリガーする最も一般的な方法は次のとおりです。
上記のコード サンプルは、#2 のさらなる抽象化を実装しており、#1 用に簡単に拡張できます。
ただし、キューとのやり取りはすべてポーリングに基づいていることに注意してください。ワーカーは、キューに新しいメッセージがあるとウェイクアップしません。新しいメッセージのキューを積極的に照会する必要があります。頻繁にクエリを実行すると Microsoft は満足しますが、おそらくあなたはそうではありません :-)。各クエリは、請求されるトランザクションとしてカウントされます (10,000 件 = $0.01)。ある種の遅延バックオフを使用してメッセージのキューをポーリングすることをお勧めします。また、バッチでメッセージを取得します。
最後に、これを極端に言えば、Web ロールとワーカー ロールを 1 つのインスタンスに結合することもできます。例については、http: //blog.smarx.com/posts/web-page-image-capture-in-windows-azureを参照してください。
複数の worker ロールにより、非常にクリーンな実装が提供されます。ただし、アイドル ロール インスタンスのコスト フットプリントは、単一のワーカー ロールよりもはるかに高くなります。
役割の組み合わせは、ISV と協力して Windows Azure を展開しているときによく見られるパターンです。頻繁にウェイクアップしてプロセスを実行するバックグラウンド スレッドを設定できます。もう 1 つの一般的な実装手法は、Azure Queue を使用して、実行するプロセスを表すメッセージを送信することです。必要に応じて複数のキューを持つことも、単一のコマンド キューを持つこともできます。いずれの場合も、各インスタンスで実行されるバックグラウンド スレッドで実行されるキュー リスナーを用意します。メッセージを最初に取得したものが処理します。それをさらに進めて、それらのメッセージをキューにプッシュする時間制限のあるプロセスを作成することもできます (おそらく 24 時間ごと、または 1 時間ごと)。
CPU とメモリの制限は別として、1 つのロールが持つことができるエンドポイントは最大 5 つだけであることを覚えておいてください (リモート デスクトップを使用している場合はそれより少なくなります)。
編集: 2011 年 9 月の時点で、デプロイ全体で 25 の入力エンドポイント (外部からアクセス可能) と 25 の内部エンドポイント (ロール間の通信に使用) があるため、ロールの構成はより柔軟になりました。MSDN の記事はこちら
私は最近、Web Role のオーバーロードについてブログを書きましたが、これは多少関連しています。
単一の Worker Role 内で複数の Worker コンポーネントを実行する方法を見つけるために指摘されているソリューションには実際の問題はありませんが、最初に個別の Worker Role を定義することの全体的なポイントは分離であることを覚えておいてください。障害に直面して。すべてを 1 つのワーカー ロール インスタンスに押し込むと、動作の悪いワーカー コンポーネントの 1 つだけが、そのロール内の他のすべてのワーカー コンポーネントをダウンさせることができます。突然、多くのインフラストラクチャを作成して、コンポーネント間の分離とフォールト トレランスを提供しています。これは、Azure が提供するものとほぼ同じです。
繰り返しますが、ひとつのことを徹底的にやることが絶対だと言っているわけではありません。単一の Worker Role の下に複数のコンポーネントを配置することが理にかなっている場所があります (特に金銭的に)。そもそもなぜこのように設計されているのかを心に留め、アーキテクチャを計画する際にそれを適切に考慮に入れる必要があると簡単に言います。
「マルチロール」が混乱するのはなぜですか？各ワーカー ロールの実装を疎結合コンポーネントとして記述し、適切なすべてのコンポーネントからワーカー ロールを構成できます。
後で一部の責任を別のワーカー ロールに分離する必要がある場合は、このコンポーネントのみを使用して新しいワーカー ロールを作成し、同時に古いワーカー ロールから削除することができます。
必要に応じて、遅延バインディングを使用して、これを再コンパイルせずに行うこともできますが、多くの場合、それは努力する価値があるとは思いません.