次の方法で共有


Azure Web PubSub サービスのパフォーマンス ガイド

Azure Web PubSub サービスを使用する主な利点の 1 つは、スケール変更が容易であることです。 大規模なシナリオでは、パフォーマンスが重要な要素です。

このガイドでは、Web PubSub サービスのパフォーマンスに影響する要因について説明します。 さまざまなユースケース シナリオでの標準的なパフォーマンスについて説明します。

メトリックを使用した簡単な評価

パフォーマンスに影響を与える要因を確認する前に、まず、サービスの負荷を簡単に監視する方法を紹介しましょう。 ポータルには、サーバー負荷と呼ばれるメトリックがあります。

ポータル上の Azure Web PubSub のサーバー負荷メトリックのスクリーンショット。このメトリックは、サーバー負荷が約 8% の使用率であることを示しています。

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 にクライアント イベントを配信します。

アップストリーム 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 を使用した Web PubSub サービスの全体的なワークフローを示す図。

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

次のステップ

これらのリソースを使用して、独自のアプリケーションの構築を開始します。