Windows Azureアプリケーションに必要なインスタンス数

Question

Windows Azureが新しく、apprによって記入されるアンケートアプリケーションをホストしたいと考えています。 30,000人のユーザーが同時に盛り上がっています。

アプリケーションは1回、クライアントに送信される1つの.aspxページで構成され、25の質問があり、最後に指定された回答のまとめが表示されます。ユーザーが答えを与えて「次の質問」ボタンを押すと、指定された回答が.ashxハンドラを介してサーバーに送信されます。応答は次の質問と回答です。ラウンドアップは、完全なポストバック後にクライアントに送信されます。 回答はAzure Tableに保存され、各パーティションは最大450人のユーザーを保持できるようにパーティション化されています。

私は、このアプリケーションを稼働させるために開始する必要のあるWebロールインスタンスの数を推定することができるかどうか尋ねます。 （それが言うのが難しい場合は、5,5、または500のインスタンスを開始する可能性が高いですか？）

良い方法はありますか：20の小さなインスタンスまたは5つの大きなインスタンス？

ありがとうございました！

Answer 1

もっとも明白な答え：これは自分自身でテストし、アプリケーションがどのように機能しているかを確認することで最も効果的です。パフォーマンスカウンタやその他の診断プログラムをWindows Azureから簡単に取得できます。たとえば、テスト中にMicrosoft SCOM（System Center Operations Manager）を使用して環境を監視することができます。 Site Hammerは、Windows Azure用の簡単な負荷テストツールです（MSDNコードギャラリー）。

私はいくつかの推測を分かち合います：負荷の種類を考えると、小さなパーティションではなく、特にストレージが既にパーティション化されているため。あなたが本当に30Kの訪問者を同時に持っていて、質問を読む間に15秒の間隔をあけようとするなら、答えを投稿する&あなたは毎秒2,000リクエストを見ています。 10ノードはその負荷を処理するのに十分な大きさでなければなりません。これは単なる見積もりであり、アーキテクチャーのあらゆる洞察が欠けていることを覚えておいてください。これらのタイプの負荷の場合、キャッシングは非常に良いアイデアです。各ノードが処理できる負荷が大幅に増加します。

しかし、私があなたに与えることができる最良のアドバイスは、あなたが積極的に監視していることを確認することです。追加のインスタンスをスピンアップするのに30分もかかりませんので、環境を監視しているときにいつでも通知されることを確認したら、セットアップを簡単にアップグレードできます。 20以上のインスタンスを利用できるようにするには、カスタマーサポートに連絡する必要があることに注意してください（これは、あなたが過度の消費から保護するためのデフォルトの制限です）。

Answer 2

賢人のアドバイスのほかに、tijmenvdkがあなたに与えた、インスタンスサイズに関する私の意見を追加しましょう。一般に、あなたのアプリをサポートする最小のサイズで行ってから、増加したトラフィックを処理するためにスケールアウトしてください。このように、スケールダウンすると、最小計算コストは​​低く抑えられます。 （稼働時間のSLAを得るのに最低限2つのインスタンスが常に必要なので）ベースラインとして一対の超大型インスタンスを実行した場合、低コストの環境でも時間当たり0.12×8×2 =交通時間。小規模なインスタンスを使用する場合、1時間あたり0.12 x 1 x 2 = $ 0.24になります。

は

関連するCPU、メモリ、およびローカル9non耐久性）ディスク・ストレージとして各VMのサイズなので、あなたのアプリがで効率的に動作する最小サイズのユニットを選択します。負荷/パフォーマンステストでは

、あなたもお勧めしますLoadstormのようなホスティングされたソリューションを検討してください。

Answer 3

現実にはどのように要求が同時に発生していますか？ 彼らはまったく同じ時刻にアドレスを入力しますか？

これは、あなたのアプリをローカルにプロファイリングすると、AzureのCPU、ネットワーク、およびメモリの使用量を見積もることができます。次に、必要なインスタンス数を調べるのではなく、要件を減らす方法を見てみましょう。これらのヒントを適用し、ローカルに再度プロファイルします。

ほとんどのパフォーマンスに関するヒントには、CPU、メモリ、または帯域使用のトレードオフがありますが、その考え方は均等にスケーリングできることを確認することです。アプリケーションのメモリが不足していても、CPUとネットワークの負荷がある場合は、

を1ページの調査で使用する場合は、html、css & jsが縮小されていることを確認してください。

可能であればそれらを組み合わせて、本当にスケーラビリティを得るには、静的ファイル（css、js &イメージ）をCDNにプッシュします。これにより、Webサーバーが処理しなければならない要求の数が減り、必要なWebサーバーの数が少なくなります。

ashxはどのように応答を返しますか？すなわち、html、xmlまたはjsonを送信していますか？ 個人的には、JSONを返すようにしました。ネットワーク帯域幅はそれほど必要ではなく、ほとんどの場合、サーバー側の処理がより少なくなります。 tijmenvdkが既に書き込みにキューを使用して言及した

使用Asyncronous APIのAzureストレージにアクセスするには（これはAzureストレージを拡張するために、CPUを有効にする=戻ってくるまで、より多くの要求を処理するIISスレッドを解放するためにIO完了ポートを使用しています）

。質問のリストは変わるのですか？そうでなければキャッシュするので、アプリケーションは起動時に1回だけテーブルストレージから読み込み、最終的な後処理のために各クライアントに対して1回はメモリとCPUを節約して読み込みます。

これらのヒントはすべて、単一のサーバーまたはWebファーム環境の通常のWebアプリケーションにも同様に適用できます。

私が作ろうとしているのは、測定できないもの、改善できないもの、測定、改善、コストのすべてが手に入るものです。動的スケーリングはコストを削減しますが、アプリケーションが測定されておらず、リソース使用率が最適化されていれば、必要なインスタンス数を尋ねることは無意味です。