Webサイト、データベース、およびバックグラウンドスケジューラをAzureプラットフォームに移動しようとしています。
Webとワーカーの役割でクラウドサービスを使用する必要があります。今私の質問は、役割のタイプごとに個別のインスタンスが必要ですか、それとも1つのインスタンスが複数のタイプの役割をホストできるかということです。
Webサイト、データベース、およびバックグラウンドスケジューラをAzureプラットフォームに移動しようとしています。
Webとワーカーの役割でクラウドサービスを使用する必要があります。今私の質問は、役割のタイプごとに個別のインスタンスが必要ですか、それとも1つのインスタンスが複数のタイプの役割をホストできるかということです。
Webとワーカーの役割のインスタンスを組み合わせることはできません。どちらでもかまいません。ただし、Webロールにバックグラウンド処理を実行させることは可能であるため、バックグラウンドワークロードをホストできます。
いくつかのオプションについては、このSOの質問を参照してください
それは毎朝タスクを実行することについて話します。明らかに、アプリケーションに応じて、より頻繁に実行できます。
ただし、これにはスケーラビリティの制限があることに注意してください。トラフィックが増加したら、それを別々のWebロールとワーカーロールに分割するのが理にかなっています。
実際、バックグラウンドワークロードが軽い場合でも、最初から別のアーキテクチャを選択し、バックグラウンド処理にXSインスタンスを使用する方が理にかなっている場合があります。
技術的には、両方のタイプの役割を持つことはできません。ただし、Web ロールはワーカー ロールとまったく同じで、IIS が構成されているだけです。したがって、それらを 1 つの Web ロールにマージできます。IIS は別のプロセスで実行され、ロール エントリ ポイントRun()
は「バックエンド」処理のために無限ループを実行します。この同様の質問を参照してください。
これにより、スケーリングがより複雑になります。個別のロールの全体的な考え方 (1 つの Web ロールと 1 つのワーカー ロールだけでなく、ソリューションに適している場合は、たとえば 4 つのワーカー ロールと 2 つの Web ロールを持つことができることを思い出してください) は、それらを個別にスケーリングできるということです。
2 つのロールを 1 つにマージすると、それらを微調整できなくなります。ほとんどの場合、これは正しくありません。メトリックを変更する必要があるだけです。
たとえば、1 分間に 1,000 件の HTTP リクエストごとに 1 つの Web ロール インスタンスを実行し、バックエンド キュー内の 10 件のリクエストごとに 1 つのワーカー ロール インスタンスを実行するとします。これは、1,000 個の HTTP リクエストごとに、バックエンド キュー内の 10 個のアイテムと同じ量の処理能力が必要であることを意味します。したがって、両方のパラメーターを取り、多数のインスタンスを推測する新しいメトリックを作成します。毎分 5,000 のリクエストがあり、バックエンド キューに 20 のリクエストがある場合、マージされた役割のインスタンスが 7 つ必要です。
これはすべてのアプリケーションで機能するわけではありませんが、ほとんどのアプリケーションではこのアプローチを問題なく使用できます。おまけとして、現在の負荷が別のロールにかかっているため、いずれかのロールがアイドル状態になるケースを回避できます。