Azure SignalR Service のパフォーマンス ガイド
Azure SignalR Service を使用する主要な利点の 1 つは、SignalR アプリケーションのスケーリングの容易さです。 大規模なシナリオでは、パフォーマンスが重要な要素です。
この記事では、次の内容について説明します。
- SignalR アプリケーションのパフォーマンスに影響を及ぼす要素。
- さまざまなユースケース シナリオでの標準的なパフォーマンス。
- パフォーマンス レポートの生成に使用できる環境とツール。
メトリックを使用した簡単な評価
Azure portal でサービスを簡単に監視できます。 SignalR インスタンスの [メトリック] ページから、[サーバー負荷] メトリックを選択すると、サービスの "負荷" を確認できます。
このグラフは、SignalR サービスのコンピューティング負荷を示しています。 シナリオをテストし、このメトリックを確認して、スケールアップするかどうかを決定できます。 SignalR サービス内の待機時間は、サーバーの負荷が 70% を下回ると低いままになります。
Note
ユニット 50 以上を使用していて、シナリオが小さなグループ (グループ サイズ <20) または単一の接続に送信メイン場合は、参照のために小規模グループに送信するか、接続に送信チェック必要があります。 このようなシナリオでは、サーバー負荷に含まれない大きなルーティング コストがあります。
用語の定義
インバウンド: Azure SignalR Service への受信メッセージ。
アウトバウンド: SignalR Service からの送信メッセージ。
帯域幅: 1 秒あたりの全メッセージの合計サイズ。
既定モード: Azure SignalR Service インスタンスが作成されるときの既定の動作モード。 Azure SignalR Service は、アプリ サーバーがクライアント接続を受け入れる前に、アプリ サーバーとの接続を確立することを想定しています。
サーバーレス モード: Azure SignalR Service がクライアント接続のみを受け付けるモード。 サーバー接続は許可されません。
概要
Azure SignalR Service には、さまざまなパフォーマンス キャパシティに対する 7 つの Standard レベルが定義されています。 このガイドでは、次の疑問にお答えします。
各レベル (ユニット) の一般的な Azure SignalR Service のパフォーマンスは何ですか?
目的とするメッセージ スループット要件を Azure SignalR Service で満たせるか (例: 毎秒 100,000 件のメッセージ送信)
特定のシナリオでは、適切なレベルを選択するにはどうすればよいですか?
自分にはどのようなアプリ サーバー (VM サイズ) が適しているか。 それらをいくつデプロイすべきか
こうした疑問に答えるために、このガイドではまず、パフォーマンスに影響する要素を大まかに説明します。 その後、エコー、ブロードキャスト、グループへの送信、接続への送信 (ピアツーピア チャット) という代表的なユース ケースについて、各レベルの最大インバウンドおよびアウトバウンド メッセージ数を示します。
このガイドですべてのシナリオ (さまざまなユース ケース、メッセージ サイズ、メッセージの送信パターンなどを含む) をカバーすることはできません。 しかし、役に立ついくつかの手法が得られます。
- インバウンドまたはアウトバウンド メッセージのおおよその要件を評価する。
- パフォーマンス表をチェックして適切なレベルを見つける。
パフォーマンスの分析情報
このセクションでは、パフォーマンス評価手法について説明してから、パフォーマンスに影響するすべての要素を列挙します。 最終的には、パフォーマンス要件を評価するうえで役立つ手法をお伝えします。
方法
"スループット" と "待ち時間" は、パフォーマンス チェックの 2 つの代表的な要素です。 Azure SignalR Service では、各 SKU レベルに独自のスループット スロットリング ポリシーがあります。 このポリシーで定義される "最大許容スループット (インバウンドおよびアウトバウンド帯域幅)" は、99% のメッセージでの待ち時間が 1 秒未満であるときに達成される最大スループットです。
待ち時間とは、接続でメッセージを送信してから、Azure SignalR Service からの応答メッセージを受信するまでの時間です。 echo を例に取り上げます。 すべてのクライアント接続では、メッセージにタイム スタンプが追加されます。 クライアントには、アプリ サーバーのハブから元のメッセージが返されます。 したがって、伝達の遅延はクライアント接続ごとに簡単に計算されます。 ブロードキャスト、グループへの送信、接続への送信におけるすべてのメッセージには、タイム スタンプが追加されます。
数千のコンカレント クライアント接続をシミュレートするために、複数の VM が Azure の仮想プライベート ネットワークに作成されます。 これらの VM はすべて、同じ Azure SignalR Service インスタンスに接続します。
Azure SignalR Service の既定モードでは、クライアント VM と同じ仮想プライベート ネットワークにアプリ サーバー VM がデプロイされます。 リージョン間の待ち時間を排除するために、すべてのクライアント VM とアプリ サーバー VM は、同じリージョンの同じネットワークにデプロイされます。
パフォーマンスの要素
次の要因が SignalR のパフォーマンスに影響します。
- SKU レベル (CPU やメモリ)
- 接続の数
- メッセージ サイズ
- メッセージ送信速度
- トランスポートの種類 (WebSocket、Server-Sent-Event、Long-Polling)
- ユースケース シナリオ (ルーティング コスト)
- アプリ サーバーとサービス接続 (サーバー モードの場合)
コンピューター リソース
理論上、Azure SignalR Service のキャパシティは、コンピューティング リソース (CPU、メモリ、ネットワーク) によって制限されます。 たとえば、Azure SignalR Service への接続数が増えると、そのサービスで使用されるメモリが増えます。 メッセージ トラフィックが大きくなると (各メッセージが 2,048 バイトを超えるなど)、Azure SignalR Service のトラフィック処理に費やされる CPU サイクルが増えます。 一方、Azure のネットワーク帯域幅によっても、最大トラフィックに制限が課されます。
トランスポートの種類
パフォーマンスに影響する要素としては、他にもトランスポートの種類があります。 3 つのタイプは次のとおりです。
- WebSocket: WebSocket は、単一の TCP 接続における双方向かつ全二重の通信プロトコルです。
- Server-Sent-Event: Server-Sent-Event は、サーバーからクライアントにメッセージをプッシュする一方向のプロトコルです。
- Long-Polling: Long-Polling では、クライアントが HTTP 要求を通じてサーバーから情報を定期的にポーリングする必要があります。
同じ条件下の同じ API では、WebSocket のパフォーマンスが最も高く、Server-Sent-Event がそれより遅く、Long-Polling が最も低速です。 Azure SignalR Service では、既定で WebSocket が推奨されます。
メッセージ ルーティングのコスト
メッセージ ルーティングのコストによっても、パフォーマンスが制限されます。 Azure SignalR Service は、メッセージ ルーターの役割を果たしており、これによって一連のクライアントまたはサーバーから他のクライアントまたはサーバーにメッセージがルーティングされます。 シナリオや API が異なれば、必要なルーティング ポリシーも異なります。
エコーでは、クライアントがそれ自体にメッセージを送信するため、ルーティングの宛先もそれ自体です。 ルーティング コストは、このパターンが最も低くなります。 一方、ブロードキャストとグループへの送信、接続への送信の場合、内部の分散データ構造を通じて、Azure SignalR Service によってターゲット接続が検索される必要があります。 この処理が加わることで、CPU、メモリ、ネットワーク帯域幅の使用量が増加します。 結果的に、パフォーマンスは低下します。
既定モードでは、アプリ サーバーも、特定のシナリオにおいてボトルネックになる可能性があります。 Azure SignalR SDK は、ハートビート シグナルを通じてすべてのクライアントとのライブ接続を維持しながら、ハブを呼び出す必要があります。
サーバーレス モードでは、クライアントが HTTP POST でメッセージを送信します。これは WebSocket ほど効率的ではありません。
プロトコル
もう 1 つの要因は、プロトコル (JSON と Messagepack) です。 MessagePack の方がサイズが小さく、配信速度も JSON より高速です。 ただし、MessagePack でパフォーマンスが改善されない場合もあります。 Azure SignalR Service は、クライアントからサーバーまたはその反対のメッセージの転送中に、メッセージ ペイロードをデコードしないため、そのパフォーマンスがプロトコルの影響を受けることはありません。
適切な SKU を見つける
インバウンド/アウトバウンドのキャパシティを評価したり、特定のユース ケースに適したレベルを見つけたりするには、どうすればよいのでしょうか。
アプリ サーバーは十分に高性能で、パフォーマンスのボトルネックにならないと仮定しましょう。 このとき、各レベルについて、インバウンドとアウトバウンドの最大帯域幅をチェックします。
簡単な評価
簡単な評価を行う場合は、以下の既定の設定を想定します。
- トランスポートの種類は WebSocket である。
- メッセージ サイズは 2,048 バイトである。
- メッセージは 1 秒おきに送信される。
- Azure SignalR Service が既定モードである。
レベルには、それぞれ固有の最大インバウンド帯域幅と最大アウトバウンド帯域幅があります。 インバウンドまたはアウトバウンド接続がその制限を超えると、滑らかなユーザー エクスペリエンスは保証されません。
エコーでは、ルーティング コストが最も少ないので、最大インバウンド帯域幅が得られます。 ブロードキャストでは、最大アウトバウンド メッセージ帯域幅が定義されます。
次の 2 つの表で強調されている値を "超えない" ようにしてください。
| エコー | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| インバウンド帯域幅 | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1,000 MB (メガバイト)ps | 2,000 MB (メガバイト)ps |
| アウトバウンド帯域幅 | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2,000 MBps |
| Broadcast | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| インバウンド帯域幅 | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| アウトバウンド帯域幅 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MB (メガバイト)ps | 2,000 MB (メガバイト)ps | 4,000 MB (メガバイト)ps |
"インバウンド帯域幅" と "アウトバウンド帯域幅" は、1 秒あたりのメッセージ サイズの合計です。 その計算式は次のとおりです。
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
inboundConnections: メッセージを送信する接続の数。
outboundConnections: メッセージを受信する接続の数。
messageSize: 1 つのメッセージのサイズ (平均値)。 1,024 バイト未満の小さなメッセージは、1,024 バイトのメッセージと同様の影響をパフォーマンスに及ぼします。
sendInterval: 1 件のメッセージの送信時間。 通常はメッセージあたり 1 秒で、これは毎秒 1 件のメッセージが送信されることを意味します。 間隔が小さいほど、一定時間に送信されるメッセージの数が増えることになります。 たとえば、メッセージあたり 0.5 秒であれば、毎秒 2 件のメッセージが送信されます。
Connections: レベルごとに Azure SignalR Service で確保されている最大しきい値。 それよりも接続数が増えると、接続スロットリングの対象となります。
Note
ユニット サイズが 100 を超える SKU プレミアム_P2にスケールアップする必要があります。
複雑なユース ケースの評価
より大きいメッセージ サイズまたは異なる送信速度
実際のユース ケースはもっと複雑です。 送信されるメッセージのサイズは 2,048 バイトを超えるかもしれません。また、メッセージの送信速度は、1 秒あたり 1 メッセージとは限りません。 ユニット 100 のブロードキャストを例として、そのパフォーマンスを評価する方法を見てみましょう。
次の表は、ブロードキャストの実際のユース ケースを示します。 ただし、メッセージ サイズ、接続数、メッセージ送信速度は、前セクションで仮定したものと異なります。 問題は、メッセージ サイズ、接続数、メッセージ送信速度のうち、2 つしかわからない場合に、それらの項目をどうすれば推測できるかです。
| Broadcast | メッセージ サイズ | 同時受信メッセージ | つながり | 送信間隔 |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100,000 | 5 秒 |
| 2 | 256 KB | 1 | 8,000 | 5 秒 |
前の数式に基づいて、次の数式が簡単に得られます。
outboundConnections = outboundBandwidth * sendInterval / messageSize
ユニット 100 の場合、最大送信帯域幅は前の表から 400 MB (メガバイト)です。 メッセージ サイズが 20 KB の場合、最大アウトバウンド接続は 400 MB * 5 / 20 KB = 100,000 となり、実際の値と一致します。
混在するユース ケース
実際のユース ケースでは、基本的な 4 つのユース ケース (エコー、ブロードキャスト、グループへの送信、接続への送信) が混在するのが一般的です。 キャパシティを評価するために使用する手法は、次のとおりです。
- 混在するユース ケースを 4 つの基本的なユース ケースに分割します。
- 前述の数式を使用して、最大インバウンドおよびアウトバウンドのメッセージ帯域幅を別々に計算します。
- その帯域幅の計算を足し合わせて、最大インバウンド/アウトバウンド帯域幅の合計を求めます。
そのうえで、最大インバウンド/アウトバウンド帯域幅の表から適切なレベルを選択してください。
Note
数百または数千の小さなグループへとメッセージを送信する場合や、数千のクライアントどうしが互いにメッセージを送信する場合、ルーティング コストの影響が大きくなります。 この影響を考慮に入れるようにしてください。
クライアントにメッセージを送信するユース ケースでは、アプリ サーバーがボトルネックになっていないことを確認してください。 次の「ケース スタディ」セクションでは、必要なアプリ サーバーの数および構成すべきサーバー接続の数についてのガイドラインを提供します。
ケース スタディ
以降のセクションでは、エコー、ブロードキャスト、グループへの送信、接続への送信という、WebSocket トランスポートの代表的なユース ケースを見ていきます。 このセクションでは、各シナリオについて、Azure SignalR Service の現在のインバウンドおよびアウトバウンド キャパシティを示します。 また、パフォーマンスに影響を及ぼす主な要素についても説明します。
既定モードでは、アプリ サーバーによって Azure SignalR Service とのサーバー接続が 5 つ作成されます。 アプリ サーバーでは、既定で Azure SignalR Service SDK が使用されます。 次のパフォーマンス テスト結果では、サーバー接続が 15 個 (ブロードキャストおよび大きなグループへのメッセージ送信ではそれ以上) に増やされます。
ユース ケースが異なると、アプリ サーバーの要件が異なります。 ブロードキャストでは、必要なアプリ サーバーは少数です。 エコーと接続への送信では、必要なアプリ サーバーの数が多くなります。
すべてのユース ケースで、既定のメッセージ サイズは 2,048 バイトであり、メッセージの送信間隔は 1 秒です。
既定のモード
既定モードには、クライアント、Web アプリ サーバー、Azure SignalR Service が関係します。 各クライアントが 1 つの接続を表します。
エコー
まず、Web アプリが Azure SignalR Service に接続します。 次に、その Web アプリに対して多数のクライアントが接続します。そこで、アクセス トークンとエンドポイントを使用して、クライアントが Azure SignalR Service にリダイレクトされます。 その後、クライアントは、Azure SignalR Service との WebSocket 接続を確立します。
すべてのクライアントは、接続の確立後、タイム スタンプが含まれているメッセージを 1 秒おきに特定のハブに送信し始めます。 そのメッセージは、ハブによって元のクライアントにエコーバックされます。 各クライアントはエコーバックされたメッセージを受信すると、待ち時間を計算します。
次の図の 5 から 8 (赤色で強調表示されたトラフィック) はループになっています。 ループが既定の期間 (5 分) 実行されて、全メッセージの待ち時間の統計が得られます。
エコーの動作から、最大インバウンド帯域幅が最大アウトバウンド帯域幅と等しいことが確定されます。 詳細については、次の表を参照してください。
| エコー | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 1 秒あたりのインバウンド/アウトバウンド メッセージ数 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| インバウンド/アウトバウンド帯域幅 | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2,000 MBps |
このユース ケースでは、アプリ サーバーに定義されているハブを各クライアントが呼び出します。 ハブはただ、元のクライアント側で定義されたメソッドを呼び出します。 このハブは、エコーの場合に最も軽量となります。
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
このシンプルなハブであっても、エコーのインバウンド メッセージの負荷が増大すると、アプリ サーバーに対するトラフィック負荷が目立つようになります。 このトラフィック負荷に対応するには、大きな SKU レベルのアプリ サーバーが多数必要です。 次の表は、各レベルのアプリ サーバー数の一覧を示します。
| エコー | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| アプリ サーバー数 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Note
アプリ サーバーの CPU やメモリ、クライアント接続数、メッセージ サイズ、メッセージ送信速度、SKU レベルが、エコーの全体的なパフォーマンスに影響を及ぼします。
Broadcast
ブロードキャストでは、メッセージを受信した Web アプリがすべてのクライアントにそれをブロードキャストします。 ブロードキャストするクライアントが増えるほど、すべてのクライアントを対象にしたメッセージ トラフィックも増えます。 次の図を参照してください。
少数のクライアントがブロードキャストしています。 インバウンド メッセージ帯域幅は小さいものの、アウトバウンド帯域幅は非常に大きくなります。 クライアント接続またはブロードキャスト レートが増えるにつれて、アウトバウンド メッセージ帯域幅が大きくなります。
次の表は、最大クライアント接続数、インバウンド/アウトバウンド メッセージ数、帯域幅をまとめたものです。
| Broadcast | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 1 秒あたりのインバウンド メッセージ数 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 1 秒あたりのアウトバウンド メッセージ数 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| インバウンド帯域幅 | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| アウトバウンド帯域幅 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2,000 MBps | 4,000 MB (メガバイト)ps |
メッセージを送信するブロードキャスト クライアントは、4 つ以下です。 インバウンド メッセージの量が少ないため、エコーと比べて、必要なアプリ サーバーの数は少なくなります。 SLA とパフォーマンスの両方を考慮しても、アプリ サーバーは 2 つで十分です。 ただし、特にユニットが 50 を超える場合は、不均衡を回避するために、既定のサーバー接続を増やす必要があります。
| Broadcast | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| アプリ サーバー数 | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Note
Azure SignalR Service へのサーバー接続で不均衡が生じるのを避けるために、各アプリ サーバーで既定のサーバー接続を 5 から 40 に増やしてください。
クライアント接続数、メッセージ サイズ、メッセージ送信速度、SKU レベルが、ブロードキャストの全体的なパフォーマンスに影響を及ぼします。
グループへの送信
グループへの送信ユース ケースは、トラフィック パターンがブロードキャストと似ています。 その違いは、クライアントが特定のグループにメッセージを送信するためには、それらが Azure SignalR Service との WebSocket 接続を確立した後でグループに参加する必要がある点です。 次の図に、そのトラフィック フローを示します。
グループ メンバーとグループの数が、パフォーマンスに影響を及ぼす 2 つの要素です。 分析を単純化するために、2 種類のグループを定義します。
小さいグループ: 各グループの接続数は 10 です。 グループ数は (最大接続数)/10 に等しくなります。 たとえば、ユニット 1 の場合、接続数が 1,000 の場合、1000 / 10 = 100 グループになります。
大きいグループ: グループ数は常に 10 です。 グループ メンバー数は (最大接続数)/10 に等しくなります。 たとえば、ユニット 1 の場合、接続数が 1,000 の場合、すべてのグループには 1000 / 10 = 100 メンバーが含まれます。
グループへの送信では、Azure SignalR Service へのルーティング コストが発生します。それが分散データ構造を通じてターゲット接続を探す必要があるためです。 送信接続が増えると、コストが増えます。
小さいグループ
多数の小さなグループに対してメッセージを送信する場合、ルーティング コストが著しく大きくなります。 現在、Azure SignalR Service の実装はユニット 50 のルーティング コスト制限に達しています。 CPU とメモリの追加は役に立たないため、ユニット 100 は設計上さらに改善できません。 インバウンド帯域幅をさらに増やす必要がある場合は、カスタマー サポートにお問い合わせください。
| 小さなグループへの送信 | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| グループ メンバー数 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| グループ数 | 100 | 200 | 1,000 | 5,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| 1 秒あたりのインバウンド メッセージ数 | 200 | 400 | 2,000 | 10,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| インバウンド帯域幅 | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| 1 秒あたりのアウトバウンド メッセージ数 | 2,000 | 4,000 | 20,000 | 100,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| アウトバウンド帯域幅 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2,000 MBps |
多数のクライアント接続がハブを呼び出しているので、アプリ サーバー数もパフォーマンスに関して非常に重要です。 次の表では、推奨されるアプリ サーバー数を示します。
| 小さなグループへの送信 | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| アプリ サーバー数 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Note
アプリ サーバーの CPU やメモリ、クライアント接続数、メッセージ サイズ、メッセージ送信速度、ルーティング コスト、SKU レベルが、小さなグループへの送信の全体的なパフォーマンスに影響を及ぼします。
グループ数、表に示されているグループ メンバー数は 、ハード制限ではありません。 これらのパラメーター値は、安定したベンチマーク シナリオを確立するために選択されます。 たとえば、各コネシトンを個別のグループに割り当てても問題ありません。 この構成では、パフォーマンスが接続に送信されるのに 近くなります。
大きなグループ
大きなグループへの送信では、ルーティング コストの制限に達する前にアウトバウンド帯域幅がボトルネックになります。 次の表は、最大アウトバウンド帯域幅を一覧にしたものです。これはブロードキャストの場合とほぼ同じです。
| 大きなグループへの送信 | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| グループ メンバー数 | 100 | 200 | 500 | 1,000 | 2,000 | 5,000 | 10,000 | 20,000 |
| グループ数 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 1 秒あたりのインバウンド メッセージ数 | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| インバウンド帯域幅 | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| 1 秒あたりのアウトバウンド メッセージ数 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| アウトバウンド帯域幅 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2,000 MBps | 4,000 MB (メガバイト)ps |
送信接続数は 40 以下です。 アプリ サーバーへの負荷は小さいので、推奨される Web アプリは少数です。
| 大きなグループへの送信 | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| アプリ サーバー数 | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Note
Azure SignalR Service へのサーバー接続で不均衡が生じるのを避けるために、各アプリ サーバーで既定のサーバー接続を 5 から 40 に増やしてください。
クライアント接続数、メッセージ サイズ、メッセージ送信速度、ルーティング コスト、SKU レベルが、大きなグループへの送信の全体的なパフォーマンスに影響を及ぼします。
接続への送信
接続への送信ユース ケースでは、クライアントが Azure SignalR Service との接続を確立する際、各クライアントが特殊なハブを呼び出して、それぞれの接続 ID を取得します。 パフォーマンス ベンチマークでは、すべての接続 ID を収集してそれらをシャッフルし、それらをすべてのクライアントに送信先として再割り当てします。 クライアントは、パフォーマンス テストが完了するまで、ターゲット接続にメッセージを送信し続けます。
接続への送信のルーティング コストは、小さなグループへの送信のコストと似ています。
接続の数が増えると、ルーティング コストが重要な要素になり、全体的なパフォーマンスが制限されます。 特に、ユニット 20 は、サービスがルーティングのボトルネックに達するしきい値をマークします。 ユニット数をさらに増やすと、ルーティング機能を強化するプレミアム_P2 (ユニット >=100) に移行しない限り、パフォーマンスが向上することはありません。
次の表は、接続への送信ベンチマークを繰り返し実行した後の統計的概要です。
| 接続への送信 | ユニット 1 | ユニット 2 | ユニット 20 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 20,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 1 秒あたりのインバウンド/アウトバウンド メッセージ数 | 1,000 | 2,000 | 20,000 | 20,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| インバウンド/アウトバウンド帯域幅 | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Note
ユニット 20 以降の 1 秒あたりの受信/送信メッセージの停滞にもかかわらず、接続を増やす容量は増え続けています。 実際のビジネス シナリオでは、ボトルネックとなるのは、多くの場合、同時メッセージ送信アクティビティではなく、接続の数です。 ベンチマーク テストのように、すべての接続が高頻度で積極的にメッセージを送信することは珍しいことです。
このユース ケースでは、アプリ サーバー側に高い負荷がかかります。 推奨されるアプリ サーバー数については、次の表を参照してください。
| 接続への送信 | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| アプリ サーバー数 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Note
アプリ サーバーの CPU やメモリ、クライアント接続数、メッセージ サイズ、メッセージ送信速度、ルーティング コスト、SKU レベルが、接続への送信の全体的なパフォーマンスに影響を及ぼします。
ASP.NET SignalR
Azure SignalR Service が提供するパフォーマンス キャパシティは、ASP.NET SignalR と同じです。
サーバーレス モード
サーバーレス モードには、クライアントと Azure SignalR Service が関係します。 各クライアントが 1 つの接続を表します。 クライアントは、REST API を通じて別のクライアントにメッセージを送信するか、またはすべてにメッセージをブロードキャストします。
REST API を使用して高密度のメッセージを送信することは、WebSocket の使用ほど効率的ではありません。 毎回、新しい HTTP 接続を作成しなければならず、サーバーレス モードでは、それが余分なコストとなります。
REST API を使用してブロードキャストする
すべてのクライアントが Azure SignalR Service との WebSocket 接続を確立します。 その後、一部のクライアントが REST API を通じてブロードキャストを開始します。 メッセージの送信 (インバウンド) は、すべて HTTP POST を通じて行われます。これは WebSocket と比べて効率的でありません。
| REST API を使用してブロードキャストする | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 1 秒あたりのインバウンド メッセージ数 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 1 秒あたりのアウトバウンド メッセージ数 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| インバウンド帯域幅 | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| アウトバウンド帯域幅 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MB (メガバイト)ps | 2,000 MB (メガバイト)ps | 4,000 MB (メガバイト)ps |
REST API を通じてユーザーに送信する
ベンチマークでは、すべてのクライアントにユーザー名を割り当てたうえで、Azure SignalR Service への接続を開始します。 クライアントは、Azure SignalR Service との WebSocket 接続を確立した後、HTTP POST を通じて他のクライアントにメッセージを送信し始めます。
| REST API を通じてユーザーに送信する | ユニット 1 | ユニット 2 | ユニット 10 | ユニット 50 | ユニット 100 | ユニット 200 | ユニット 500 | ユニット 1000 |
|---|---|---|---|---|---|---|---|---|
| つながり | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 1 秒あたりの受信/送信メッセージ数 | 200 | 400 | 2,000 | 10,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| 受信/送信帯域幅 | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
パフォーマンス テスト環境
上記のすべてのユース ケースについて、Azure 環境でパフォーマンス テストを実施しました。 最大で、200 個のクライアント VM と 100 個のアプリ サーバー VM を使用しました。 次に、いくつかの詳しい情報を記載します。
クライアント VM サイズ: StandardDS2V2 (vCPU × 2、メモリ 7 GB)
アプリ サーバー VM サイズ: StandardF4sV2 (vCPU × 4、メモリ 8 GB)
Azure SignalR SDK サーバー接続数: 15
パフォーマンス ツール
Azure SignalR Service のパフォーマンス ツールは、GitHub にあります。
次のステップ
この記事では、代表的なユースケース シナリオにおける Azure SignalR Service のパフォーマンスの概要を紹介しました。
サービスの内部とそのスケーリングについて詳しくは、次のガイドを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示