Azure Web PubSub サービスのパフォーマンス ガイド
Azure Web PubSub サービスを使用する主な利点の 1 つは、スケール変更が容易であることです。 大規模なシナリオでは、パフォーマンスが重要な要素です。
このガイドでは、Web PubSub サービスのパフォーマンスに影響する要因について説明します。 さまざまなユースケース シナリオでの標準的なパフォーマンスについて説明します。
メトリックを使用した簡単な評価
パフォーマンスに影響を与える要因を確認する前に、まず、サービスの負荷を簡単に監視する方法を紹介しましょう。 ポータルには、サーバー負荷と呼ばれるメトリックがあります。
Azure Web PubSub サービスのコンピューティング負荷を示します。 独自のシナリオでテストし、このメトリックを確認して、スケールアップするかどうかを決定できます。 サーバーの負荷が 70% を下回ると、Azure Web PubSub サービス内の待機時間は低いままになります。
Note
ユニット 50 以上を使用していて、かつシナリオが主に小さなグループ (グループ サイズ < 20) への送信の場合は、参照のために小さなグループへの送信を確認する必要があります。 このようなシナリオでは、サーバー負荷に含まれない大きなルーティング コストがあります。
パフォーマンスを評価するための詳細な概念を次に示します。
用語の定義
インバウンド: Azure Web PubSub Service への受信メッセージ。
アウトバウンド: Azure Web PubSub Service からの送信メッセージ。
帯域幅: 1 秒あたりの全メッセージの合計サイズ。
概要
このガイドでは、次の疑問にお答えします。
各ユニット サイズの標準的な Azure Web PubSub サービスのパフォーマンスはどの程度ですか?
目的とするメッセージ スループット要件を Azure Web PubSub Service で満たせるか (例: 毎秒 100,000 件のメッセージ送信)
特定のシナリオでは、適切なユニット サイズを選択するにはどうすればよいですか?
こうした疑問に答えるために、このガイドではまず、パフォーマンスに影響する要素を大まかに説明します。 次に、Web PubSub サブプロトコル経由でのグループへの送信、アップストリーム、REST API という一般的なユース ケースの最大受信および送信メッセージを示します。
このガイドですべてのシナリオ (さまざまなユース ケース、メッセージ サイズ、メッセージの送信パターンなどを含む) をカバーすることはできません。 ただし、パフォーマンスの制限を理解するための基本的な情報が提供されています。
パフォーマンスの分析情報
このセクションでは、パフォーマンス評価手法について説明してから、パフォーマンスに影響するすべての要素を列挙します。 最終的には、パフォーマンス要件を評価するうえで役立つ手法をお伝えします。
方法
"スループット" と "待ち時間" は、パフォーマンス チェックの 2 つの代表的な要素です。 最大許容スループット (インバウンドおよびアウトバウンド帯域幅) は、99% のメッセージでの待ち時間が 1 秒未満であるときに達成される最大スループットとして定義されます。 これはハード制限ではありません。
パフォーマンスの要素
理論上、Azure Web PubSub Service の容量は、計算リソース (CPU、メモリ、ネットワーク) によって制限されます。 たとえば、Azure Web PubSub Service への接続数が増えると、そのサービスで使用されるメモリが増えます。 メッセージ トラフィックが大きくなると (各メッセージが 2,048 バイトを超えるなど)、Azure Web PubSub Service のトラフィック処理に費やされる CPU サイクルが増えます。
メッセージ ルーティングのコストによっても、パフォーマンスが制限されます。 Azure Web PubSub Service には、一連のクライアント間でメッセージをルーティングするメッセージ ブローカーとしての役割があります。 シナリオや API が異なれば、必要なルーティング ポリシーも異なります。
echo の場合、クライアントからアップストリームにメッセージが送信され、そのメッセージはアップストリームからクライアントにエコー バックされます。 ルーティング コストは、このパターンが最も低くなります。 一方、ブロードキャストとグループへの送信、接続への送信の場合、内部の分散データ構造を通じて、Azure Web PubSub Service によってターゲット接続が検索される必要があります。 この処理が加わることで、CPU、メモリ、ネットワーク帯域幅の使用量が増加します。 結果的に、パフォーマンスは低下します。
まとめると、インバウンドとアウトバウンドのキャパシティは、次の要素の影響を受けます。
ユニット サイズ (CPU/メモリ)
接続の数
メッセージ サイズ
メッセージ送信速度
ユースケース シナリオ (ルーティング コスト)
適切なユニット サイズの決定
インバウンド/アウトバウンドの容量を評価し、特定のユース ケースに適したユニット サイズを見つけるには、どうすればよいですか?
ユニット サイズには、それぞれ固有の最大インバウンド帯域幅と最大アウトバウンド帯域幅があります。 インバウンドまたはアウトバウンド トラフィックがそのしきい値を超えると、円滑なユーザー エクスペリエンスは保証されません。
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections: メッセージを送信する接続の数。
- outboundConnections: メッセージを受信する接続の数。
- messageSize: 1 つのメッセージのサイズ (平均値)。 1,024 バイト未満の小さなメッセージは、1,024 バイトのメッセージと同様の影響をパフォーマンスに及ぼします。
- sendInterval: メッセージを送信する間隔。 たとえば、1 秒は、毎秒 1 つのメッセージを送信することを意味します。 間隔が小さいほど、一定時間に送信されるメッセージの数が増えることになります。 たとえば、0.5 秒は、毎秒 2 つのメッセージを送信することを意味します。
- 接続: ユニット サイズごとに Azure Web PubSub サービスで確保されている最大しきい値。 しきい値を超える接続は調整されます。
アップストリームは十分に高性能で、パフォーマンスのボトルネックにならないと仮定しましょう。 次に、各ユニット サイズについて、インバウンドとアウトバウンドの最大帯域幅をチェックします。
ケース スタディ
次のセクションでは、Web PubSub サブプロトコル経由でのグループへの送信、CloudEvent のトリガー、REST API の呼び出しという 3 つの一般的なユース ケースについて説明します。 このセクションでは、各シナリオについて、Azure Web PubSub Service の現在のインバウンドおよびアウトバウンド容量を示します。 また、パフォーマンスに影響を及ぼす主な要素についても説明します。
すべてのユース ケースで、既定のメッセージ サイズは 2,048 バイトであり、メッセージの送信間隔は 1 秒です。
Web PubSub サブプロトコルを経由でグループに送信する
このサービスは、json.webpubsub.azure.v1 と呼ばれる特定のサブプロトコルをサポートしています。これにより、クライアントはアップストリーム サーバーへのラウンド トリップではなく、発行/サブスクライブを直接実行できます。 このシナリオは、サーバーが関与せず、すべてのトラフィックがクライアントとサービス間の WebSocket 接続を経由するため、効率的です。
グループ メンバーとグループの数が、パフォーマンスに影響を及ぼす 2 つの要素です。 分析を単純化するために、2 種類のグループを定義します。
- 大きいグループ: グループ数は常に 10 です。 グループ メンバー数は (最大接続数)/10 に等しくなります。 たとえば、ユニット 1 で接続数が 1,000 の場合、各グループのメンバー数は 100 (= 1,000/10) です。
- 小さいグループ: 各グループの接続数は 10 です。 グループ数は (最大接続数)/10 に等しくなります。 たとえば、ユニット 1 で接続数が 1,000 の場合、グループ数は 100 (= 1,000/10) です。
グループへの送信では、Azure Web PubSub Service へのルーティング コストが発生します。それが分散データ構造を通じてターゲット接続を探す必要があるためです。 送信接続が増えると、コストが増えます。
大きなグループ
大きなグループへの送信では、ルーティング コストの制限に達する前にアウトバウンド帯域幅がボトルネックになります。 次の表は、最大アウトバウンド帯域幅の一覧です。
| 大きなグループへの送信 | ユニット 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 | 1,000 | 5,000 | 10,000 | 5,000 | 10,000 | 20,000 |
| グループ数 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 1 秒あたりのインバウンド メッセージ数 | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| インバウンド帯域幅 | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps |
| 1 秒あたりのアウトバウンド メッセージ数 | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| アウトバウンド帯域幅 | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1,200 MBps | 3,000 MBps | 6,000 MBps |
小さいグループ
多数の小さなグループに対してメッセージを送信する場合、ルーティング コストが著しく大きくなります。 現在、Azure Web PubSub の実装では、Unit50 でルーティング コストの制限に達します。 CPU やメモリを増やしても効果はないため、ユニット 100 にしても、仕様上、それ以上の向上は見込めません。 より多くのインバウンド帯域幅が必要な場合は、Premium_P2 (ユニット >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 |
Note
表に記載されているグループ数、グループ メンバー数は、ハード制限ではありません。 これらのパラメータ値は、安定したベンチマーク シナリオを確立するために選択されます。
クラウド イベントのトリガー
サービスは、CloudEvents HTTP プロトコルを使用して、アップストリームの Webhook にクライアント イベントを配信します。
すべてのイベントに対して、登録されたアップストリームへの HTTP POST 要求を形成し、HTTP 応答を期待します。
Note
Web PubSub は、アップストリーム イベントの配信に HTTP 2.0 もサポートしています。 次の結果は、HTTP 1.1 を使用してテストされています。 アプリ サーバーが HTTP 2.0 をサポートしている場合、パフォーマンスは向上します。
エコー
この場合、アプリ サーバーによって元のメッセージが http 応答に書き戻されます。 エコーの動作から、最大インバウンド帯域幅が最大アウトバウンド帯域幅と等しいことが確定されます。 詳細については、次の表を参照してください。
| エコー | ユニット 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 秒あたりのインバウンド/アウトバウンド メッセージ数 | 500 | 1,000 | 5,000 | 25,000 | 50,000 | 100,000 | 250,000 | 500,000 |
| インバウンド/アウトバウンド帯域幅 | 1 MBps | 2 MBps | 10 MBps | 50 MBps | 100 MBps | 200 MBps | 500 MBps | 1,000 MBps |
REST API
Azure Web PubSub には、クライアントを管理し、リアルタイム メッセージを配信するための強力な API が用意されています。
REST API を通じてユーザーに送信する
ベンチマークでは、すべてのクライアントにユーザー名を割り当てたうえで、Azure Web PubSub Service への接続を開始します。
| 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 秒あたりのインバウンド/アウトバウンド メッセージ数 | 180 | 360 | 1,800 | 9,000 | 18,000 | 36,000 | 90,000 | 180,000 |
| インバウンド/アウトバウンド帯域幅 | 360 KBps | 720 KBps | 3.6 MBps | 18 MBps | 36 MBps | 72 MBps | 180 MBps | 360 MBps |
REST API を使用してブロードキャストする
帯域幅は、大きなグループへの送信の場合の帯域幅と同じです。
| 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 秒あたりのインバウンド メッセージ数 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| 1 秒あたりのアウトバウンド メッセージ数 | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| インバウンド帯域幅 | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps |
| アウトバウンド帯域幅 | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1,200 MBps | 3,000 MB | 6,000MB |
次のステップ
これらのリソースを使用して、独自のアプリケーションの構築を開始します。