Azure Web PubSub

解決する課題

• チャットや共同編集、ライブダッシュボードなどリアルタイムな双方向通信を実装したいが、WebSocket サーバーの自前運用は負担が大きい
• 同時接続が数万・数十万に達したとき、接続のスケールと負荷分散を自前で設計したくない
• サーバーの再起動やデプロイのたびに接続が切れる問題を避けたい
• 接続のグルーピングや特定ユーザーへの配信といったルーティングを毎回作り込みたくない

これらを、WebSocket 接続の保持とファンアウトを肩代わりするマネージドサービスに集約して解決します。アプリ側はビジネスロジックに集中し、大量接続の維持は Web PubSub が担います。

主要概念と用語

• WebSocket: クライアントとサーバーの間に張りっぱなしの双方向通信路を作るプロトコル。Web PubSub の中心となる接続方式で、標準 WebSocket クライアントから直接つなげる
• ハブ（Hub）: 接続をまとめる論理的な名前空間。用途ごと（チャット用、通知用など）にハブを分けて管理する
• 接続（Connection）: 個々のクライアントの WebSocket セッション。一意の接続 ID を持つ
• グループ（Group）: 接続を束ねる単位。グループに対してメッセージを送ると、その所属接続すべてにファンアウトされる。チャットルームやトピックの実装に使う
• ユーザー（User）: 1人のユーザーに紐づく複数接続をまとめる識別子。ユーザー単位での送信や切断ができる
• イベントハンドラー（Event Handler）: 接続・切断・メッセージ受信などのイベントを、Webhook 形式でバックエンドに転送する仕組み。サーバー側のロジックを呼び出す入口
• サブプロトコル: 素の WebSocket に加え、PubSub 用の JSON サブプロトコルを使うと、クライアントから直接グループへの参加や発行ができる
• アクセストークン: クライアントが接続する際に使う署名付きトークン。接続先のハブや権限を埋め込む

仕様・制限・クォータ

• 接続方式: 標準 WebSocket が基本。クライアントは特別な SDK なしに接続でき、サーバー側は SDK やイベントハンドラーで連携する
• SKU と容量: Free は 1 ユニット・20 接続・2 万メッセージ/日。Standard と Premium P1 は 1 ユニットあたり 1,000 接続・100 万メッセージ/日で、通常最大 100 ユニット
• 大規模 SKU: Premium P2 は 100〜1,000 ユニットで、最大 100 万同時接続。リージョン内のサブスクリプション合計は既定 150 ユニット
• メッセージサイズ: 1メッセージのサイズには上限がある。大きなデータは直接流さず、参照（URL など）を渡してクライアントが取得する設計が無難
• イベントハンドラー: 接続ライフサイクルやメッセージを Webhook で受け取る。バックエンドは Abuse Protection の OPTIONS 要求へ WebHook-Allowed-Origin ヘッダーを含めて応答する
• 配信と再接続: 通常の接続は非永続。信頼サブプロトコルでは発行側が同じ ackId で再送し、Duplicate 応答を処理済みとして扱う。受信側は sequenceAck で連番を確認し同じ接続 ID を再開するが、切断が約 1 分を超えると再開できず損失し得る

内部の仕組み

横にスクロール

クライアントは、まずアプリのバックエンドからアクセストークン付きの接続 URL を受け取り、その URL に標準 WebSocket で接続します。接続要求は Web PubSub サービスが受け止め、TLS 終端や認証を行ったうえでセッションを保持します。アプリのバックエンドはこの大量接続を直接抱えません。

接続・切断・メッセージ受信などのイベントが発生すると、サービスは設定されたイベントハンドラー（Webhook）へ HTTP で転送します。バックエンドはここでメッセージを処理し、必要なら REST API や SDK を通じて、特定の接続・ユーザー・グループ・ハブ全体へメッセージを送り返します。

• 送信モデル: 「全員」「特定グループ」「特定ユーザー」「特定接続」のスコープを指定してファンアウトできる
• グループ参加: バックエンドが接続をグループへ追加する方式と、PubSub サブプロトコル利用時にクライアント自身が参加・発行する方式がある
• サービスが接続維持を担うため、バックエンドはステートレスに保てる。ただしメッセージを永続保存するサービスではなく、接続断時は信頼サブプロトコルで再開するか、正本から状態を再同期する

設計パターン / ベストプラクティス

• トークン発行はバックエンドで行う。クライアントに接続文字列やキーを直接渡さず、短命なアクセストークンを払い出す
• グループ設計をトピックに対応づける。チャットルームや購読対象ごとにグループを切り、配信スコープを明確にする
• クライアントからの直接発行は慎重に。PubSub サブプロトコルでクライアント発行を許す場合、誰がどのグループに送れるかをトークンの権限で制御する
• バックエンドはステートレスに。接続状態はサービスが持つ前提にし、アプリ層は水平スケールできるようにする
• メッセージは小さく、参照渡しに。本体は別ストアに置き、通知にはイベント種別と参照を載せる
• 再接続を前提に設計。ネットワーク断は起こるものとして、クライアント側で再接続と状態復元を実装する
• 信頼サブプロトコルの確認応答を正しく実装。発行の再試行では同じ ackId を使い、受信後は sequenceAck を返す。再開期限やサービス内バッファを超えた場合は正本から再同期する

運用・監視

• Azure Monitor / メトリクスで同時接続数、送受信メッセージ数、エラー率を監視し、ユニットのスケール判断に使う
• イベントハンドラー（Webhook）の応答を監視する。バックエンドが遅延・失敗するとイベント処理が滞るため、エンドポイントの可用性とレイテンシを見る
• 接続数の上限到達に注意し、ユニットの自動・手動スケールを計画する
• 接続が安定しない場合は、トークンの有効期限切れ、Webhook の Abuse Protection 応答不備、ネットワーク経路を疑う

コスト

• 課金は主に SKU（Free / Standard / Premium） とユニット数、2 KiB 単位の送信メッセージ数で決まる。Standard 以上は 1 ユニットあたり 100 万メッセージ/日の無料枠を含む
• 検証・小規模は Free、本番のスケールが必要なら Standard でユニットを調整する
• メッセージ量や接続数が変動する用途では、ピークに合わせた過剰なユニット確保にならないよう監視値からサイジングする
• 具体的な単価や無料枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• クライアントには短命なアクセストークンを払い出し、接続文字列やアクセスキーを直接埋め込まない
• トークンにハブ・ロール・権限を埋め込み、参加や発行できるグループを最小限に絞る
• イベントハンドラーの Webhook は Abuse Protection の OPTIONS 要求へ WebHook-Allowed-Origin ヘッダーを返し、許可する接続元を明示する
• アクセスキー認証だけでなく Microsoft Entra ID（Azure AD） によるマネージド ID 認証を使うと、キー管理の負担を減らせる
• 通信は TLS で保護される。重要データはメッセージ本体に載せず参照渡しにする方針と併用する

関連サービス・比較

同じくリアルタイム通信を担う Azure SignalR Service との違い、および AWS の相当サービスを整理します。SignalR Service は ASP.NET Core SignalR のホスティングに最適化され、独自のクライアントライブラリ（自動再接続やトランスポート切替を含む）を前提とします。Web PubSub は素の WebSocket を中心に、言語やフレームワークを問わず接続できる点が特徴です。

Azure 内では、サーバーレスの Functions とイベントハンドラーを組み合わせ、接続やメッセージ受信をトリガーにバックエンド処理を呼び出す構成がよく使われます。サービス間のイベント連携には Event Grid、デバイスへのプッシュ通知には Notification Hubs と、用途で使い分けます。

ハンズオン / CLI例

# az webpubsubはAzure CLI 2.56.0以降のwebpubsub拡張機能
# リソースグループを作成
az group create --name demo-rg --location japaneast

# Web PubSub サービスを作成
az webpubsub create \
  --resource-group demo-rg \
  --name demo-wps-0628 \
  --location japaneast \
  --sku Standard_S1

# サービスのキー・接続文字列を確認（バックエンドが利用）
az webpubsub key show \
  --resource-group demo-rg \
  --name demo-wps-0628 -o json

# イベントハンドラーを設定（受信イベントを Webhook へ転送）
az webpubsub hub create \
  --resource-group demo-rg \
  --name demo-wps-0628 \
  --hub-name chat \
  --event-handler url-template="https://example.com/eventhandler" user-event-pattern="*" system-event="connected" system-event="disconnected"

# chat ハブへ対話型クライアントで接続して動作確認
az webpubsub client start \
  --resource-group demo-rg \
  --name demo-wps-0628 \
  --hub-name chat \
  --user-id demo-user