3

ユーザー アプリケーション (Azure アプリ) が perfmon データを DB に送信できる REST API が 1 つあります。ここで、この REST API のロード テストを行うために、500個の Webrole とそれぞれの 10 個のインスタンス (合計 5000 個のインスタンス) の 1 つのシミュレーター アプリケーションを構築しました。この大量の負荷を処理するためのベスト プラクティスを備えた REST API。

以下は、REST API をスケーリングするための私のテスト ケースです。

中 - 6 インスタンス => 300 インスタンスのリクエストを処理できます

特大 - 2 インスタンス => 300 インスタンスのリクエストを処理できます

さて、私の質問は、このタイプの負荷は、水平方向のスケーリングまたは垂直方向のスケーリングで処理できるということですか? 中サイズまたは小サイズのインスタンスの数を増やす必要があるか、または特大サイズのインスタンスを使用する必要があることを意味しますか?

また、この REST API はデータを SQL Azure データベース (5 GB Web エディション) に投稿する予定ですが、リクエストの処理に関して何か制限はありますか?

上記の場合、すべてのアプリケーションが同じリージョンで考慮されます

4

3 に答える 3

2

6 つのミディアム インスタンス = 12 コア、2 つの XL インスタンス = 16 コアです。価格的には、XL を 2 つではなく、M を 6 つ使用することをお勧めします。

さらに、動的にスケーリングする場合、XL では 8 コアまでしかスケーリングできませんが、ミディアムでは 2 コアまでスケーリングできます。私はミディアム インスタンスを使用しますが、可能であれば小さいものでも構いません。そして、水平スケーリング (別名スケールアウト) をターゲットにします - インスタンス数の増加/減少。

また、SQL に送信する前に何らかの種類のデータをバッファリングすることを検討し、Windows Azure SQL データベース (WASD) と直接通信しないようにします。このタイプの負荷では、WASD への 1 秒ごとのヒットが、負荷が高いために一時的なエラーに遭遇する可能性が非常に高くなります。データをキュー (Azure Storage キューまたは Azure Service Bus キュー) にバッファリングし、Worker ロール (複数のインスタンスを持つ可能性があります) を持ち、キュー メッセージをバッチで処理することを検討してください。

このタイプ スケールは、CQRS パターンでの応答性と信頼性が高くなる可能性が非常に高くなります。CQRS と Windows Azure の詳細と参照実装については、CQRS Journey Projectを参照してください。

于 2012-08-08T12:30:48.137 に答える
1

これはコメントでしたが、私は部屋を使い果たしました。

PERFMON データを受信する REST API の速度と規模を考慮して設計している場合、なぜ QUEUE の呼び出しではなく SQL の呼び出しで API を遅くするのでしょうか?

SQL が 1 つのキューの処理を続けることができない場合、SQL は 6 つの REST サービスからの呼び出しにも追いつくことができなくなります。最後に、SQL 挿入はディスク IO によって制限されます。適切に設計されていれば、単一のプロセスが SQL と同じ速さでデータを SQL に送信できます。

1 分間に 50,000 回の挿入は大変なことなので、インデックスの設計方法と挿入の設計方法を検討してください。確かに、断片化するインデックスは必要ありません。生データにシーケンシャル キーがある場合は、それを PK として使用できます。それ以外の場合は、Iden を PK として使用します。

挿入をバッチ処理すると、スループットを向上させることができます。バッチ処理によって必ずしもレイテンシが増加するわけではありません。次の挿入の準備ができていて、キューに 1 つしかない場合は、1 のバッチを挿入します。挿入にはスイート スポットがあります (100 ～ 1000 など)。

私がしていることは、フォアグラウンドで挿入を構築してから、非同期を挿入することです。非同期挿入よりも高速に挿入を構築できる場合、SQL は完全にロードされています。構文をメモリ内に構築し、ディスク構築に挿入するため、構文を構築するための複雑な処理がない限り、構文は高速になります。はい、フェデレーションを使用してディスク IO を分割しますが、その挿入を最適化することから始めます。ドラッパーが人気です。テーブル値パラメーターをよく使用します。insert into table values() は最速のオプションではありませんが、50,000 / 分に追いつく可能性があります。

REST API をキューで保護します。次に、そのキューの処理を最適化します。

Azure Table Storage と言えますが、合計で 1 秒あたり 5,000 エンティティ、および 500 エンティティ/秒/パーティションに制限されています。これらのスループットの制限により、ATS を高度にスケーラブルと呼ぶことはできないと思います。

于 2012-08-09T16:13:10.033 に答える
0

これは、ストレージのスケールアウトの問題であり、可能な限りリアルタイムに近づけたいと考えているようです。

その場合、SQL フェデレーションがうまくいかない場合は、それぞれが 1 つ以上のユーザー アプリケーション用に予約されている複数のデータベースを使用するテナント ベースのアプローチが機能する可能性があります。

于 2012-08-11T23:21:21.550 に答える