サードパーティなしでスケールするAzureアプリケーションのパターンは何ですか？

Question

自分のAzure Webロールを自己完結してスケーラブルにしたいと思っています。

これまでに見たスケーリングのすべてのソリューションには、サードパーティが含まれています。Azureの役割を監視してスケールする特別なサービス、または手動スケーリングのアプリケーションかもしれません。私が望むのは、スケーリングの開始時期とスケーリングを決定する決定的な役割を果たす特別なコードです。

私は次の問題を見ています。第1に、各時点で1つのロールインスタンスのみが存在し、スケーリングの混乱が生じないようにスケーリングするタイミングとスケーリング方法を決定する必要があります。第二に、その特定のインスタンスが何らかの理由で死亡した場合、別のインスタンスをある妥当な期間内に選択しなければならない。そして最後に、すべてのものがあまりにも多くのオーバーヘッドを導入すべきではない。

このような自己完結型スケーリングを実装するためのパターンはありますか？

Answer 1

確実に自動スケールコードをウェブの役割に配置できます。複数のインスタンスがスケールロジックを実行しないようにするには、1つの手法でBLOBリースの形式で「ミューテックス」を使用します（BLOBライターは1つしか使用できません）。

• いずれの場合も、よく知られているBLOBのリースを取得しようとするコードがあります。
• リースを取得した人は、スケールコードを実行します（おそらく、予定されているチェックのいくつかのタイプ、おそらくオートスケールアプリケーションブロック@tjrobinsonを使用しています）。
• 誰かが例外を取得し、定期的に再度試みます。何らかの理由でリースを保有するインスタンスが死亡した場合、別のインスタンスはすぐに失われたリースを取得し、自動スケールコードの実行を開始することができます。

Answer 2

あなたが公式のMicrosoftのソリューションに取得します最も近いの一部であるThe Autoscaling Application Blockあるマイクロソフトエンタープライズライブラリ自動スケーリングアプリケーションブロック （わさび）は、あなたのWindows Azureのに自動スケーリングの振る舞いを追加することができますMicrosoft Enterprise Library 5.0 Integration Pack for Windows Azure

アプリケーション。ブロックをWindows Azureで、または からオンプレミスのアプリケーションでホストすることを選択できます。オートスケーリングアプリケーションブロックは、変更なしで使用することができます。 です。 Windows Azure アプリケーションで自動スケーリングの動作を定義して監視するために必要なすべての機能を提供します（ ）。それはあなたの構成設定を管理するためのグラフィカルなエンタープライズライブラリの設定ツールを使用することができます

• ：

  エンタープライズライブラリ自動スケーリングアプリケーションブロックは 次の機能が含まれています。

• ブロックで使用されるストレージの場所とロギングのメカニズムを設定できます。
• カスタムオートスケーリングルールと アクションを追加することで、ブロックを拡張できます。

Answer 3

WASABiのリリース前であっても、Windows Azure上でprovisioning libをしばらく実行しています。

私たちのために最高の仕事をしているパターンは、これまでのところ、次の側面が含まれています

• あなたのスケーリングメトリックを定義する（例のためのメモリやCPU使用率別名）いずれかの低レベルのメトリックを信用してはいけません、ワークロード（および必要なVMの数）を定義する単純ではあるが関連性の高いメトリックを作成します。
• すべてのVM間で厳密な対称性を維持します（マスタまたはスレーブなし）。すべてのVMは、プロビジョニング対象のVMの数を変更する可能性があります。
• 各VMには自動スケーリングを扱うバックグラウンドスレッドがあります。 99.999％の時間、このスレッドは何もしていません。毎分、スレッドはblob leaseを取得し、プロビジョニングロジックを実行しようとします。 blobリースを即座に取得できない場合は、あきらめて、別のVMが既にそこにあります。
• AzureでVMをインスタンシエートすると約5分かかり、すぐに1時間かかる。私はちょっとであることをお勧めします怠惰 deinstanciationに来ると30分ほど待って、10分後にinstinstiatingでメリットはありません。
• プロビジョニングAPIがの場合、その時間内に呼び出し元のスレッドがVM上の何もブロックしていないことを確認してください。
• 稼働時間を改善するには、VMの最小数を2にしてください。