Azure Web PubSub

解決する課題

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

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

主要概念と用語

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

仕様・制限・クォータ

代表的な考え方です（SKU により異なり、具体値は変動するため定性的に示します）。

• 接続方式: 標準 WebSocket が基本。クライアントは特別な SDK なしに接続でき、サーバー側は SDK やイベントハンドラーで連携する
• SKU: Free と Standard の階層があり、上位ほどユニット数を増やして同時接続数とメッセージ処理能力を拡張できる。スケールはユニット追加で水平に伸ばす
• 同時接続数 / メッセージ数: ユニットあたりの上限があり、ユニットを増やすことで上限が拡大する。具体的な数値は SKU・ユニット構成で変わる
• メッセージサイズ: 1メッセージのサイズには上限がある。大きなデータは直接流さず、参照（URL など）を渡してクライアントが取得する設計が無難
• イベントハンドラー: 接続ライフサイクルやメッセージを Webhook で受け取る。バックエンドは Abuse Protection（到達性検証）に応答する必要がある

内部の仕組み

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

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

• 送信モデル: 「全員」「特定グループ」「特定ユーザー」「特定接続」のスコープを指定してファンアウトできる
• グループ参加: バックエンドが接続をグループへ追加する方式と、PubSub サブプロトコル利用時にクライアント自身が参加・発行する方式がある
• サービスがステートフルな接続維持を担うため、バックエンドはステートレスに保て、デプロイや再起動で接続が切れにくい

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

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

運用・監視

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

コスト

• 課金は主に SKU（Free / Standard） とユニット数で決まる。ユニットを増やすほど同時接続・メッセージ枠が拡大し、コストも上がる
• 検証・小規模は Free、本番のスケールが必要なら Standard でユニットを調整する
• メッセージ量や接続数が変動する用途では、ピークに合わせた過剰なユニット確保にならないよう監視値からサイジングする
• 具体的な単価や無料枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• クライアントには短命なアクセストークンを払い出し、接続文字列やアクセスキーを直接埋め込まない
• トークンにハブ・ロール・権限を埋め込み、参加や発行できるグループを最小限に絞る
• イベントハンドラーの Webhook は **Abuse Protection（到達性検証）**に応答し、想定外の呼び出し元からの受信を防ぐ
• アクセスキー認証だけでなく 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 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

# 動作確認用にクライアントアクセス URL を払い出す（chat ハブ）
az webpubsub client-access-uri \
  --resource-group demo-rg \
  --name demo-wps-0628 \
  --hub-name chat

# イベントハンドラーを設定（受信イベントを 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"