Azure SignalR Service

解決する課題

• チャット、通知、ライブダッシュボード、共同編集などサーバーからクライアントへ即時にデータを押し出す用途で、ポーリングでは遅延と負荷が大きい
• WebSocket の常時接続を大量に維持する必要があり、自前サーバーでは接続数がスケールの上限になりやすい
• 複数サーバーに分散したとき、どのサーバーにつながっている接続にもメッセージを届けるためのバックプレーン（Redis など）を運用するのが煩雑
• WebSocket が使えないネットワークやブラウザでのフォールバック制御を自前で実装したくない

これらを、接続の維持とスケールアウトを引き受けるマネージドサービスに委譲して解決します。アプリサーバーは接続そのものではなくメッセージの内容に集中できます。

主要概念と用語

• SignalR: サーバーからクライアントへリアルタイムにデータを送るための ASP.NET 系ライブラリ。Azure SignalR Service はその接続層をマネージド化したもの
• ハブ（Hub）: クライアントとサーバーがメソッドを呼び合う論理的な接点。1つのアプリに複数のハブを定義できる
• 接続（Connection）: 1クライアントとの常時接続。各接続には一意の接続 ID が割り当てられる
• グループ（Group）: 複数接続をまとめて同報配信するための論理グループ。チャットルームなどの単位に使う
• トランスポート: 実際の通信方式。WebSocket を最優先に、使えない場合は Server-Sent Events や Long Polling へ自動フォールバックする
• サービスモード: 動作形態。サーバーを介在させる Default、自前サーバーを持たず関数等で処理する Serverless、両立する Classic がある
• アップストリーム: Serverless モードでクライアントからのメッセージを Azure Functions などへ転送する仕組み
• ネゴシエート（negotiate）: クライアントが最初にアプリへ問い合わせ、接続先のサービス URL とアクセストークンを受け取るハンドシェイク

仕様・制限・クォータ

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

• SKU: 無料枠の Free、本番向けの Standard、より大規模・予測可能な性能の Premium といった階層がある
• ユニット: 容量はユニット数で表され、1ユニットあたりの同時接続数とメッセージ数の上限が決まる。ユニットを増やしてスケールアウトする
• 同時接続数: ユニット数に比例して上限が決まる。大量接続を見込む場合はユニットを積む設計にする
• プロトコル: WebSocket を中心に、Server-Sent Events / Long Polling へフォールバックする
• メッセージサイズ: 1メッセージのサイズには上限があり、大きなデータは分割するか別途ストレージ経由にする設計が基本
• 可用性ゾーン: 上位 SKU ではゾーン冗長に対応し、可用性を高められる

内部の仕組み

クライアントはまずアプリサーバーの negotiate エンドポイントにアクセスし、接続すべき SignalR Service の URL と短命のアクセストークンを受け取ります。その後クライアントはアプリサーバーではなくサービスへ直接常時接続を張ります。これにより、接続維持の負荷はサービス側が引き受け、アプリサーバーは接続数に縛られずにスケールできます。

サーバーからクライアントへメッセージを送るときは、アプリサーバーがサービスへ「この接続／このグループへ送れ」と指示し、サービスが対象の接続へファンアウトします。アプリサーバーが複数台に分散していても、サービスが接続の所在を一元管理するため、自前のバックプレーン（Redis など）が不要になります。

• Default モード: アプリサーバーがハブのロジックを持ち、サービスは接続層として振る舞う
• Serverless モード: 常時接続するアプリサーバーを持たず、クライアントからのメッセージはアップストリーム経由で Azure Functions などに渡して処理する。SignalR の出力バインドで送信する
• トランスポートは WebSocket を最優先し、確立できない環境では自動で代替方式に切り替わる

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

• negotiate はサーバー側で実装し、接続キーをクライアントへ直接埋め込まない。トークンは短命にして最小権限で発行する
• Serverless モード + Azure Functions で、自前サーバーを持たずにイベント駆動でリアルタイム配信する構成は運用負荷が小さい
• グループ設計を先に固める。ルームやユーザー単位でグループを切り、同報の宛先指定を単純化する
• メッセージは軽量に保つ。大きなペイロードは Blob などに置き、通知にはその参照だけを載せる
• 一斉配信が多いワークロードではユニット数とメッセージ上限を見積もり、余裕を持たせる
• 認証はアプリ側で済ませ、SignalR への接続トークンに**ユーザー識別子（クレーム）**を載せてユーザー単位の送信に活用する

運用・監視

• Azure Monitor / メトリクスで同時接続数、メッセージ数、インバウンド/アウトバウンドトラフィックを監視し、ユニット上限に対する余裕を把握する
• 接続数がユニット上限に近づくと新規接続が拒否されるため、しきい値アラートを設定する
• **診断ログ（接続・メッセージのトレース）**を有効にし、接続失敗やネゴシエートの不具合を調査できるようにする
• Premium の自動スケールを使うと、ピークに合わせてユニットを増減できる。トラフィックの波が大きいワークロードで有効
• フォールバックが多発する場合は、経路上のプロキシやファイアウォールが WebSocket を遮断していないか確認する

コスト

• 課金は主に SKU（Free / Standard / Premium） と ユニット数、稼働時間で決まる
• ユニットは同時接続数とメッセージ数の容量を表し、積むほど容量と費用が増える
• Serverless モードでもサービスのユニットは課金対象となるため、想定接続数に見合うユニットに抑える
• 検証は Free、本番は Standard 以上が目安。大規模・ゾーン冗長・自動スケールが必要なら Premium を検討する
• 具体的な単価や無料枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• アクセスキーまたは Microsoft Entra ID（マネージド ID） で認証する。可能ならキーよりマネージド ID を使い、キーの管理・ローテーション負荷を下げる
• クライアントへ渡す接続トークンは短命にし、negotiate で都度発行する。サービスのアクセスキーをクライアントに配らない
• 通信は TLS で保護される。重要データはメッセージに直接載せず参照に留める方針と併用する
• プライベートエンドポイントでサービスへのアクセスを仮想ネットワーク内に閉じ、パブリック公開を避ける構成も取れる
• ユーザー認証はアプリ側で完結させ、接続トークンに載せたクレームで送信先を制御する

関連サービス・比較

リアルタイム通信を扱う Azure サービスとの違い、および AWS の相当サービスを整理します。

同じくリアルタイム通信を扱う Azure Web PubSub は、SignalR に依存しない汎用の WebSocket pub/sub を提供します。既存の SignalR アプリや ASP.NET 資産があるなら SignalR Service、言語やフレームワークを問わず素の WebSocket を扱いたいなら Web PubSub が向きます。Serverless 構成では Azure Functions と組み合わせ、イベント発生時にリアルタイム配信をトリガーする使い方が一般的です。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# SignalR Service を作成（Standard、1ユニット、Default モード）
az signalr create \
  --resource-group demo-rg \
  --name demo-signalr-0628 \
  --location japaneast \
  --sku Standard_S1 \
  --unit-count 1 \
  --service-mode Default

# 接続文字列を確認（アプリサーバーが negotiate に使用）
az signalr key list \
  --resource-group demo-rg \
  --name demo-signalr-0628 \
  --query primaryConnectionString -o tsv

# Serverless モードへ切り替え（Functions 連携時）
az signalr update \
  --resource-group demo-rg \
  --name demo-signalr-0628 \
  --service-mode Serverless