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

Azure Web PubSub Service を使用する主な利点の 1 つは、Web PubSub アップストリーム アプリケーションのスケーリングが容易なことです。 大規模なシナリオでは、パフォーマンスが重要な要素です。

このガイドでは、Web PubSub アップストリーム アプリケーションのパフォーマンスに影響を及ぼす要素を紹介します。 さまざまなユースケース シナリオでの標準的なパフォーマンスについて説明します。

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

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

Screenshot of the Server Load metric of Azure Web PubSub on Portal. The metrics shows Server Load is at about 8 percent usage.

Azure Web PubSub サービスのコンピューティング負荷を示します。 独自のシナリオでテストし、このメトリックを確認して、スケールアップするかどうかを決定できます。 サーバーの負荷が 70% を下回ると、Azure Web PubSub サービス内の待機時間は低いままになります。

Note

ユニット 50 またはユニット 100 を使用していて、シナリオが小さなグループ (グループ サイズ <20) に送信メイン場合は、参照のために小さなグループに送信チェック必要があります。 このようなシナリオでは、サーバー負荷に含まれない大きなルーティング コストがあります。

パフォーマンスを評価するための詳細な概念を次に示します。

用語の定義

インバウンド: Azure Web PubSub Service への受信メッセージ。

アウトバウンド: Azure Web PubSub Service からの送信メッセージ。

帯域幅: 1 秒あたりの全メッセージの合計サイズ。

概要

Azure Web PubSub Service には、さまざまなパフォーマンス容量に対する 7 つの Standard レベルが定義されています。 このガイドでは、次の疑問にお答えします。

  • 各レベルの標準的な Azure Web PubSub Service パフォーマンスはどの程度か

  • 目的とするメッセージ スループット要件を Azure Web PubSub Service で満たせるか (例: 毎秒 100,000 件のメッセージ送信)

  • 特定のシナリオにおいて、どのレベルが自分に合っているか。 または、適切なレベルを選ぶにはどうすればよいか

こうした疑問に答えるために、このガイドではまず、パフォーマンスに影響する要素を大まかに説明します。 次に、Web PubSub サブプロトコル経由でのグループへの送信アップストリームREST API という一般的なユース ケースの最大受信および送信メッセージを階層ごとに示します。

このガイドですべてのシナリオ (さまざまなユース ケース、メッセージ サイズ、メッセージの送信パターンなどを含む) をカバーすることはできません。 ただし、パフォーマンスの制限を理解するための基本的な情報が提供されています。

パフォーマンスの分析情報

このセクションでは、パフォーマンス評価手法について説明してから、パフォーマンスに影響するすべての要素を列挙します。 最終的には、パフォーマンス要件を評価するうえで役立つ手法をお伝えします。

方法

"スループット" と "待ち時間" は、パフォーマンス チェックの 2 つの代表的な要素です。 Azure Web PubSub Service では、各 SKU レベルに独自のスループット スロットリング ポリシーがあります。 このポリシーで定義される "最大許容スループット (インバウンドおよびアウトバウンド帯域幅)" は、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、メモリ、ネットワーク帯域幅の使用量が増加します。 結果的に、パフォーマンスは低下します。

まとめると、インバウンドとアウトバウンドのキャパシティは、次の要素の影響を受けます。

  • SKU レベル (CPU やメモリ)

  • 接続の数

  • メッセージ サイズ

  • メッセージ送信速度

  • ユースケース シナリオ (ルーティング コスト)

適切な SKU を見つける

インバウンド/アウトバウンドのキャパシティを評価したり、特定のユース ケースに適したレベルを見つけたりするには、どうすればよいのでしょうか。

レベルには、それぞれ固有の最大インバウンド帯域幅と最大アウトバウンド帯域幅があります。 インバウンドまたはアウトバウンド トラフィックがその制限を超えると、滑らかなユーザー エクスペリエンスは保証されません。

  inboundBandwidth = inboundConnections * messageSize / sendInterval
  outboundBandwidth = outboundConnections * messageSize / sendInterval
  • inboundConnections: メッセージを送信する接続の数。
  • outboundConnections: メッセージを受信する接続の数。
  • messageSize: 1 つのメッセージのサイズ (平均値)。 1,024 バイト未満の小さなメッセージは、1,024 バイトのメッセージと同様の影響をパフォーマンスに及ぼします。
  • sendInterval: メッセージを送信する間隔。 たとえば、1 秒は、毎秒 1 つのメッセージを送信することを意味します。 間隔が小さいほど、一定時間に送信されるメッセージの数が増えることになります。 たとえば、0.5 秒は、毎秒 2 つのメッセージを送信することを意味します。
  • Connections: レベルごとに Azure Web PubSub Service で確保されている最大しきい値。 しきい値を超える接続は調整されます。

アップストリームは十分に高性能で、パフォーマンスのボトルネックにならないと仮定しましょう。 このとき、各レベルについて、インバウンドとアウトバウンドの最大帯域幅をチェックします。

ケース スタディ

次のセクションでは、Web PubSub サブプロトコル経由でのグループへの送信CloudEvent のトリガーREST API の呼び出しという 3 つの一般的なユース ケースについて説明します。 このセクションでは、各シナリオについて、Azure Web PubSub Service の現在のインバウンドおよびアウトバウンド容量を示します。 また、パフォーマンスに影響を及ぼす主な要素についても説明します。

すべてのユース ケースで、既定のメッセージ サイズは 2,048 バイトであり、メッセージの送信間隔は 1 秒です。

Web PubSub サブプロトコルを経由でグループに送信する

このサービスは、json.webpubsub.azure.v1 と呼ばれる特定のサブプロトコルをサポートしています。これにより、クライアントはアップストリーム サーバーへのラウンド トリップではなく、発行/サブスクライブを直接実行できます。 このシナリオは、サーバーが関与せず、すべてのトラフィックがクライアントとサービス間の WebSocket 接続を経由するため、効率的です。

Diagram showing the send to group workflow.

グループ メンバーとグループの数が、パフォーマンスに影響を及ぼす 2 つの要素です。 分析を単純化するために、2 種類のグループを定義します。

  • 大きいグループ: グループ数は常に 10 です。 グループ メンバー数は (最大接続数)/10 に等しくなります。 たとえば、Unit1 で接続数が 1,000 の場合、各グループのメンバー数は 100 (= 1,000/10) です。
  • 小さいグループ: 各グループの接続数は 10 です。 グループ数は (最大接続数)/10 に等しくなります。 たとえば、Unit1 で接続数が 1,000 の場合、グループ数は 100 (= 1,000/10) です。

グループへの送信では、Azure Web PubSub Service へのルーティング コストが発生します。それが分散データ構造を通じてターゲット接続を探す必要があるためです。 送信接続が増えると、コストが増えます。

大きなグループ

大きなグループへの送信では、ルーティング コストの制限に達する前にアウトバウンド帯域幅がボトルネックになります。 次の表は、最大アウトバウンド帯域幅の一覧です。

大きなグループへの送信 Unit1 Unit2 Unit5 Unit10 Unit20 Unit50 Unit100
つながり 1,000 2,000 5,000 10,000 20,000 50,000 100,000
グループ メンバー数 100 200 500 1,000 2,000 5,000 10,000
グループ数 10 10 10 10 10 10 10
1 秒あたりのインバウンド メッセージ数 30 30 30 30 30 30 30
インバウンド帯域幅 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps 60 KBps
1 秒あたりのアウトバウンド メッセージ数 3,000 6,000 15,000 30,000 60,000 150,000 300,000
アウトバウンド帯域幅 6 MBps 12 MBps 30 MBps 60 MBps 120 MBps 300 MBps 600 MBps
小さいグループ

多数の小さなグループに対してメッセージを送信する場合、ルーティング コストが著しく大きくなります。 現在、Azure Web PubSub の実装では、Unit50 でルーティング コストの制限に達します。 CPU やメモリを増やしても効果はなく、よって Unit100 を選んでも、仕様上、それ以上の向上は見込めません。 インバウンド帯域幅をさらに増やす必要がある場合は、カスタマー サポートにお問い合わせください。

小さなグループへの送信 Unit1 Unit2 Unit5 Unit10 Unit20 Unit50 Unit100
つながり 1,000 2,000 5,000 10,000 20,000 50,000 100,000
グループ メンバー数 10 10 10 10 10 10 10
グループ数 100 200 500 1,000 2,000 5,000 10,000
1 秒あたりのインバウンド メッセージ数 400 800 2,000 4,000 8,000 15,000 15,000
インバウンド帯域幅 800 KBps 1.6 MBps 4 MBps 8 MBps 16 MBps 30 MBps 30 MBps
1 秒あたりのアウトバウンド メッセージ数 4,000 8,000 20,000 40,000 80,000 150,000 150,000
アウトバウンド帯域幅 8 MBps 16 MBps 40 MBps 80 MBps 160 MBps 300 MBps 300 MBps

Note

グループ数、表に示されているグループ メンバー数は 、ハード制限ではありません。 これらのパラメーター値は、安定したベンチマーク シナリオを確立するために選択されます。

クラウド イベントのトリガー

サービスは、CloudEvents HTTP プロトコルを使用して、アップストリームの Webhook にクライアント イベントを配信します。

The Upstream Webhook

すべてのイベントに対して、登録されたアップストリームへの HTTP POST 要求を形成し、HTTP 応答を期待します。

Note

Web PubSub は、アップストリーム イベントの配信に HTTP 2.0 もサポートしています。 次の結果は、HTTP 1.1 を使用してテストされています。 アプリ サーバーが HTTP 2.0 をサポートしている場合、パフォーマンスは向上します。

エコー

この場合、アプリ サーバーによって元のメッセージが http 応答に書き戻されます。 エコーの動作から、最大インバウンド帯域幅が最大アウトバウンド帯域幅と等しいことが確定されます。 詳細については、次の表を参照してください。

エコー Unit1 Unit2 Unit5 Unit10 Unit20 Unit50 Unit100
つながり 1,000 2,000 5,000 10,000 20,000 50,000 100,000
1 秒あたりのインバウンド/アウトバウンド メッセージ数 500 1,000 2,500 5,000 10,000 25,000 50,000
インバウンド/アウトバウンド帯域幅 1 MBps 2 MBps 5 MBps 10 MBps 20 MBps 50 MBps 100 MBps

REST API

Azure Web PubSub には、クライアントを管理し、リアルタイム メッセージを配信するための強力な API が用意されています。

Diagram showing the Web PubSub service overall workflow using REST APIs.

REST API を通じてユーザーに送信する

ベンチマークでは、すべてのクライアントにユーザー名を割り当てたうえで、Azure Web PubSub Service への接続を開始します。

REST API を通じてユーザーに送信する Unit1 Unit2 Unit5 Unit10 Unit20 Unit50 Unit100
つながり 1,000 2,000 5,000 10,000 20,000 50,000 100,000
1 秒あたりのインバウンド/アウトバウンド メッセージ数 180 360 900 1,800 3,600 9,000 18,000
インバウンド/アウトバウンド帯域幅 360 KBps 720 KBps 1.8 MBps 3.6 MBps 7.2 MBps 18 MBps 36 MBps

REST API を使用してブロードキャストする

帯域幅の制限は、大きなグループへの送信の場合と同じです。

REST API を使用してブロードキャストする Unit1 Unit2 Unit5 Unit10 Unit20 Unit50 Unit100
つながり 1,000 2,000 5,000 10,000 20,000 50,000 100,000
1 秒あたりのインバウンド メッセージ数 3 3 3 3 3 3 3
1 秒あたりのアウトバウンド メッセージ数 3,000 6,000 15,000 30,000 60,000 150,000 300,000
インバウンド帯域幅 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps
アウトバウンド帯域幅 6 MBps 12 MBps 30 MBps 60 MBps 120 MBps 300 MBps 600 MBps

次のステップ

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