4

クラウド サービスを効果的にスケーリングするための適切な構成を特定するのに苦労しています。管理ポータルのスケール セクションを使用するだけで、プログラム的には何も使用しないと思いますか? Web ロールの現在の構成は

中規模の VM (4 GB RAM) 自動スケーリング - CPUインスタンスの範囲 - 1 ～ 10ターゲット CPU - 50 ～ 80一度に 1 つのインスタンスずつスケールアップおよびスケールダウンするスケールアップおよびダウンの待機時間 - 5 分

http://loader.io/サイトを使用して、並行リクエストを API に送信することで負荷テストを行いました。また、50 ～ 100 人のユーザーしかサポートできませんでした。その後、タイムアウト（10秒）エラーが発生しました。私のアプリは何百万人ものユーザーを大規模にターゲットにする予定なので、サーバーの負荷に対応するために効率的にスケーリングする方法がよくわかりません。

問題は 5 分 (非常に高いと思います) のスケールアップ時間である可能性があると思います。管理ポータルでは、最低のオプションは 5 分なので、どうすればそれを短縮できますか?

助言がありますか？

4

2 に答える 2

6

Azure の自動スケーリング エンジンは、60 分間の CPU 使用率の平均を 5 分ごとに調べます。これは、5 分ごとに、CPU 使用率が高すぎるかどうかを判断してスケールアップする機会があることを意味します。

より堅牢なものが必要な場合は、次のことを検討することをお勧めします。

  • CPU 使用率が Web サイトのスケーリングの適切な指標になることはめったにありません。CPU 使用率ではなく、Requests/sec または requests/current を調べます。
  • より頻繁に (1 分ごとに) スケーリングする必要性を検討することを検討してください。Azure portal ではこれを実行できません。これに は、 WASABiまたは AzureWatchが必要です。
  • 使用パターンに応じて、より短い平均時間を見て判断を下すことを検討してください (つまり、60 分ではなく 20 分の平均)。繰り返しますが、ここでの選択肢は WASABi または AzureWatch です。
  • 最新の平均自体だけでなく、指標の増加の /rate/ を確認することを検討してください。IE: 過去 20 分間で 1 秒あたりのリクエスト数が 20% 増加しました。繰り返しますが、Azure 自動スケーリング エンジンはこれを行うことができません。WASABi (これを行う可能性があります) または確実にこれを行うことができる AzureWatch のいずれかを検討してください。

WASABiは、Microsoft のアプリケーション ブロック (つまり、DLL) であり、自分で構成、ホスト、および監視する必要があります。それは非常に柔軟で、オープンソースであるため、どの機能もオーバーライドできます。

AzureWatchは、Azure ロール/仮想マシン/Web サイト/SQL Azure などを監視/自動スケーリング/修復するサード パーティのマネージド サービスです。お金はかかりますが、汚い仕事はすべて他人に任せます。

私は最近、3つの製品の比較についてブログを書きました

開示: 私は AzureWatch と提携しています

HTH

于 2013-08-09T16:39:25.933 に答える
0

最小時間が 5 分であるもう 1 つの理由は、Azure が追加のマシンをクラウド サービスに割り当て、ソフトウェアをそれらにレプリケートするのに時間がかかるためです。(WebApps にはその「問題」はありません) SaaS 管理者としての私の仕事では、クラウド サービスの場合、スケーリング後のこのランプアップ時間は、ソフトウェア パッケージで約 3 ～ 5 分であることがわかりました。

Azure portal 内でスケーリングを構成する場合は、CPU 範囲を大幅に下げることをお勧めします。Igorek が述べたように、Azure のスケーリングは過去 60 分間の平均を調べます。クラウド サービスがほとんどの時間 5% の CPU で実行されている場合、突然ピークに達して 99% で実行される場合、平均が上昇してスケール設定がトリガーされるまでに時間がかかります。80% のままにしておくと、スケーリングが非常に遅くなります。RL の例: CPU を集中的に使用する計算を実行するポータルを管理しています。通常の使用では、クラウド サービスは 2 ～ 5% の CPU で実行される傾向がありますが、まれに 99% まで上昇し、しばらくその状態が続くことがありました。

私の最初のスケーリングの試みは 2 つのインスタンスで、平均 CPU が 80% のときに 2 でスケールアップしましたが、平均 CPU がそれほど速く上がらなかったため、イベントがトリガーされるまでに約 40 分かかりました。現在、平均 CPU が 25% を超えたときにすべてがスケールするように設定されており、サービスが 10 ～ 12 分後にスケールアップすることがわかります。25% が魔法の数字だと言っているのではありません。「60 分間の平均」で作業していることを念頭に置いてください。

2 つ目は、Azure ポータルには限られたスケーリング オプションのセットしか表示されず、Powershell/REST を使用するとスケーリングをより詳細に設定できることです。たとえば、平均を計算する 60 分の間隔を短くすることができます。

于 2016-09-26T11:00:36.553 に答える