編集

Azure SignalR Service の FAQ

  • よく寄せられる質問

Azure SignalR Service は運用環境で利用できますか?

はい。ASP.NET Core SignalR と ASP.NET SignalR のサポートは両方ともすべて一般公開されています。

複数のアプリケーション サーバーが存在する場合、クライアント メッセージはすべてのサーバーに送信されますか? それとも 1 つのサーバーだけに送信されますか?

クライアントとアプリケーション サーバーとの間には 1 対 1 のマッピングが存在します。 クライアントからのメッセージは常に同じアプリケーション サーバーに送信されます。

このマッピングは、クライアントまたはアプリケーション サーバーが切断されるまで保持されます。

いずれかのアプリケーション サーバーがダウンした場合に、それを見つけたり、通知を受け取ったりするにはどうすればよいですか?

Azure SignalR Service によって、アプリケーション サーバーからのハートビートが監視されます。 指定された期間ハートビートを受信しなかった場合、アプリケーション サーバーはオフラインと見なされます。 このアプリケーション サーバーにマップされているすべてのクライアント接続が切断されます。

ASP.NET Core SignalR SDK から Azure SignalR Service SDK に切り替えると、カスタムの `IUserIdProvider` で例外がスローされるのはなぜですか?

ASP.NET Core SignalR SDK と Azure SignalR Service SDK では、IUserIdProvider を呼び出すときのパラメーター HubConnectionContext context が異なります。

ASP.NET Core SignalR の場合、HubConnectionContext context はすべてのプロパティに有効な値が指定された物理クライアント接続からのコンテキストです。

Azure SignalR Service SDK の場合、HubConnectionContext context は論理クライアント接続からのコンテキストです。 物理クライアントは Azure SignalR Service インスタンスに接続されるため、限られた数のプロパティのみが指定されます。

現在のところ、HubConnectionContext.GetHttpContext() と HubConnectionContext.User のみがアクセス可能です。 ソース コードを確認できます。

ASP.NET Core SignalR を使用して、サーバー側の Azure SignalR Service で使用可能な転送を構成できますか? たとえば、WebSocket 転送を無効にすることはできますか?

はい。 構成方法については、「トランスポート構成」を参照してください。

「ASP.NET Core SignalR の構成」に記載されているように、クライアント側の転送を構成することもできます。

Azure portal に表示されるメッセージ数や接続数などのメトリックの意味を教えてください。 集計の種類としてどれを選べばよいでしょうか?

これらのメトリックの計算の詳細については、「Azure SignalR Service でのメッセージと接続」を参照してください。

Azure SignalR Service リソースの概要ペインでは、適切な集計の種類が既に選択されています。 Azure Monitor でサポートされているメトリックを参照として使用できます。

`既定`、`サーバーレス`、`クラシック` の各サービス モードの意味は何ですか。 どのように選べばよいでしょうか?

新しいアプリケーションの場合、既定モードとサーバーレス モードのみを使用する必要があります。 主な違いは、サービスへのサーバー接続を確立するアプリケーション サーバー (例えば、AddAzureSignalR() を使用してサービスに接続する) があるかどうかです。 はいの場合は既定モードを使用し、それ以外の場合はサーバーレス モードを使用します。

クラシック モードは、既存のアプリケーションの下位互換性のために用意されているため、新しいアプリケーションには使用しないでください。

サービス モードの詳細については、「Azure SignalR Service のサービス モード」を参照してください。

サーバーレス モードでクライアントからメッセージを送信できますか?

SignalR インスタンスでアップストリーム エンドポイントを設定すると、クライアントからメッセージを送信できます。 アップストリーム エンドポイントは、SignalR Service からメッセージおよび接続イベントを受信できる一連のエンドポイントです。 アップストリーム エンドポイントが設定されていない場合、クライアントからのメッセージは無視されます。

詳細については、「アップストリーム エンドポイント」を参照してください。

アップストリーム エンドポイント機能は現在パブリック プレビュー段階です。

Azure SignalR Service を使用する場合と ASP.NET SignalR を使用する場合で、機能上の違いはありますか?

Azure SignalR Service を使用する場合、ASP.NET SignalR のいくつかの API と機能はサポートされません。

  • クライアントとハブとの間で任意の状態 (一般に HubState と呼ばれる) を渡す機能はサポートされません。
  • PersistentConnection クラスはサポートされません。
  • "Forever Frame の転送" はサポートされません。
  • クライアントがオフラインの場合、Azure SignalR Service ではクライアントに送信されたメッセージが再生されなくなりました。
  • Azure SignalR Service を使用する場合、1 つのクライアント接続のトラフィックは、接続期間中、常に 1 つのアプリ サーバー インスタンスにルーティングされます ("スティッキー" ともいう)。

ASP.NET SignalR のサポートは互換性に重点が置かれているため、ASP.NET Core SignalR の一部の新機能はサポートされません。 たとえば、MessagePack や Streaming は ASP.NET Core SignalR アプリケーションでのみ使用できます。

さまざまなサービス モード (Classic、Default、Serverless) に対して、Azure SignalR Service を構成できます。 ASP.NET では、Serverless モードはサポートされません。 また、データプレーンの REST API もサポートされません。

データはどこに存在するか?

Azure SignalR Service では、顧客データは格納されません。 診断用の Azure Storage など、他の Azure サービスを Azure SignalR Service と併用する場合は、データ所在地を Azure リージョンで維持する方法に関するガイダンスについて、Azure プライバシーの概要に関するホワイト ペーパーをご覧ください。

Azure SignalR Service と Azure Web PubSub サービスのどちらを選択すればよいですか?

Azure SignalR Service と Azure Web PubSub サービスはどちらも、大規模で高可用性を備えたリアルタイムの Web アプリケーションを簡単に構築するのに役立ち、お客様はメッセージング インフラストラクチャの管理ではなくビジネス ロジックに集中できます。 一般に、既に SignalR ライブラリを使用してリアルタイム アプリケーションを構築している場合は、Azure SignalR Service を選択できます。 代わりに、WebSocket とパブリッシュ/サブスクライブ パターンに基づいてリアルタイム アプリケーションを構築する汎用ソリューションを探している場合は、Azure Web PubSub サービスを選択できます。 Azure Web PubSub サービスは Azure SignalR Service に代わるものではなく、またその逆でもなく、それぞれ対象とするシナリオが異なるのです。 次のガイダンスは、シナリオで使用するサービスを決定するのに役立ちます。

以下のような場合は、Azure SignalR Service の方が適しています。

  • ASP.NET または ASP.NET Core SignalR を既に使用していて、主に .NET を使用しているか、.NET エコシステム (Blazor など) と統合する必要がある。
  • お使いのプラットフォームで使用できる SignalR クライアントがある。
  • 多種多様なものをサポートする確立されたプロトコルが必要です。
    • 呼び出しパターン (RPC とストリーミング)
    • トランスポート (WebSocket、サーバー送信イベント、長いポーリング)
  • 接続有効期間の管理を代行するクライアントが必要です。

次のような状況には、Azure Web PubSub サービスの方が適しています。

  • WebSocket テクノロジに基づいてリアルタイム アプリケーションを構築するか、WebSocket を介してパブリッシュ/サブスクライブする必要がある。
  • 独自のサブプロトコルを構築したり、WebSocket を介して既存の高度なプロトコル (MQTT、WebSocket 経由の AMQP など) を使用したい。
  • 構成されたバックエンドを経由せずにクライアントにメッセージを送信するといった、軽量のサーバーを探している。