Azure SignalR Service のサービス モード
サービス モードは、Azure SignalR Service での重要な概念です。 SignalR サービスでは現在、"既定"、"サーバーレス"、"クラシック" の 3 つのサービス モードがサポートされています。 SignalR Service リソースは、各モードで動作が異なります。 この記事では、シナリオに基づいて適切なサービス モードを選択する方法について説明します。
サービス モードを設定する
Azure portal で新しい SignalR リソースを作成するとき、サービス モードを指定するように求められます。
後から設定メニューでサービス モードを変更することもできます。
Azure SignalR CLI を使用してサービス モードを設定したり変更したりするには、az signalr create と az signalr update を使用します。
既定のモード
"既定モード" は、その名前が示すように SignalR Service の既定のサービス モードです。 既定モードでは、アプリケーションが一般的な ASP.NET Core SignalR または ASP.NET SignalR (非推奨) アプリケーションとして機能します。 ハブをホストする Web サーバー アプリケーション ("ハブ サーバー" と呼ばれます) があり、クライアントはこのハブ サーバーと全二重通信を行います。 ASP.NET Core SignalR と Azure SignalR Service の違いは、クライアントとハブ サーバーが直接接続するのではなく、クライアントとサーバーの両方が SignalR Service に接続し、このサービスをプロキシとして使用することです。 次の図は、既定モードの一般的なアプリケーション構造を示しています。
通常、既定モードは、SignalR Service で使用する SignalR アプリケーションがある場合に適しています。
既定モードでの接続ルーティング
既定モードでは、ハブ サーバーと SignalR Service の間に WebSocket 接続が存在します ("サーバー接続" と呼ばれます)。 これらの接続は、サーバーとクライアントの間でメッセージを転送するために使用されます。 新しいクライアントが接続されると、SignalR Service により、既存のサーバー接続を使用して、クライアントは 1 つのハブ サーバーにルーティングされます (複数のサーバーがあると仮定)。 クライアント接続はその有効期間中、同じハブ サーバーに固定されます。 この特性は、"接続の持続性" と呼ばれます。 クライアントによって送信されたメッセージは、常に同じハブ サーバーに送られます。 持続性の動作により、ハブ サーバー上の個々の接続に対して状態を安全に維持できます。 たとえば、サーバーとクライアントの間で何かをストリーミングしたい場合、データ パケットが異なるサーバーに送信されることを考慮する必要はありません。
重要
既定モードでは、最初にハブ サーバーがサービスに接続されてからでないと、クライアントが接続できません。 ネットワークの中断またはサーバーの再起動によってすべてのハブ サーバーが切断された場合、クライアント接続はエラーになり、サーバーが接続されていないことが示されます。 お客様ご自身の責任で、SignalR Service に接続されているハブ サーバーを常時少なくとも 1 台確保する必要があります。 たとえば、複数のハブ サーバーを使ってアプリケーションを設計し、それらが同時にオフラインにならないようにする、といった対策が考えられます。
この既定のルーティング モデルでは、ハブ サーバーがオフラインになると、そのサーバーにルーティングされる接続も切断されます。 ハブ サーバーがメンテナンスのためにオフラインになったら接続が切断されることを想定し、アプリケーションへの影響を最小限に抑えるために再接続処理を行う必要があります。
Note
既定モードでも、ハブ サーバーを経由したくない場合は、REST API と管理 SDK と関数バインドを使用して、クライアントにメッセージを直接送信できます。 既定モードでは、クライアント接続はやはりハブ サーバーによって処理され、アップストリームのエンドポイントはそのモードでは動作しません。
サーバーレス モード
既定モードとは異なり、サーバーレス モードでは、ハブ サーバーが実行されている必要はありません。モードに "サーバーレス" という名前が付いているのもそのためです。クライアント接続を維持する役割は SignalR Service が担います。 接続の持続性は保証されず、HTTP 要求は WebSocket 接続より効率が劣る場合があります。
サーバーレス モードは Azure Functions と連携することで、リアルタイム メッセージング機能を実現します。 クライアントは、Azure Functions 用の SignalR Service バインド ("関数バインド" と呼ばれます) を使用し、出力バインディングとしてメッセージを送信します。
サーバー接続がないため、サーバー SDK を使用してサーバー接続を確立しようとするとエラーが発生します。 SignalR Service は、サーバーレス モードでのサーバー接続の試行を拒否します。
サーバーレス モードに接続の持続性はありませんが、サーバー側アプリケーションからクライアントにメッセージをプッシュすることはできます。 サーバーレス モードでクライアントにメッセージをプッシュするには、次の 2 とおりの方法があります。
- REST API を 使用する (1 回限りの送信イベントの場合)。
- 複数のメッセージをより効率的に送信できるように、WebSocket 接続を使用する。 この WebSocket 接続は、サーバー接続とは異なります。
Note
REST API と WebSocket のどちらの方法も、SignalR Service Management SDK でサポートされています。 .NET 以外の言語を使用している場合でも、この仕様に従って、REST API を手動で呼び出すことができます。
また、サーバー アプリケーションでクライアントからメッセージと接続イベントを受信することもできます。 SignalR Service では、Web hook を使用して、構成済みのエンドポイント ("アップストリーム エンドポイント" と呼ばれます) にメッセージと接続イベントが配信されます。 アップストリーム エンドポイントは、サーバーレス モードでのみ構成できます。 詳細については、「アップストリーム エンドポイント」を参照してください。
次の図は、サーバーレス モードの動作を示しています。
クラシック モード
Note
クラシック モードは、主に、既定モードとサーバーレス モードが導入される前に作成されたアプリケーションとの下位互換性のために用意されています。 どうしても必要な場合以外はクラシック モードを使用しないでください。 新しいアプリケーションには、シナリオに応じて既定またはサーバーレスを使用してください。 クラシック モードを使用しなくても済むよう、既存のアプリケーションの再設計をお勧めします。
クラシックは、既定モードとサーバーレス モードの混合モードです。 クラシック モードでは、クライアント接続が確立されるときにハブ サーバーが接続されているかどうかによって接続の種類が決まります。 ハブ サーバーがある場合、クライアント接続はハブ サーバーにルーティングされます。 ハブ サーバーが使用できない場合、クライアントからサーバーへのメッセージをハブ サーバーに配信できない制限付きのサーバーレス モードでクライアント接続が確立されます。 クラシック モードのサーバーレス接続では、アップストリーム エンドポイントなど一部の機能がサポートされません。
なんらかの理由ですべてのハブ サーバーがオフラインになった場合に、接続がサーバーレス モードで行われます。 お客様ご自身の責任で、使用可能なハブ サーバーを常に少なくとも 1 台確保する必要があります。
適切なサービス モードを選択する
サービス モードの間にはどのような違いがあり、それらをどのように選択すればよいかわかったはずです。 既に説明したように、クラシック モードは新規のアプリケーションであれ、既存のアプリケーションであれ推奨されません。 ここでは、サービス モードの正しい選択と、既存のアプリケーションにおけるクラシック モードの廃止に役立つヒントを紹介します。
SignalR ライブラリの動作について既によく理解していて、セルフホステッドの SignalR から Azure SignalR Service の使用に移行したい場合は、既定モードを選択します。 既定モードはセルフホステッドの SignalR とまったく同じように機能します (SignalR ライブラリの同じプログラミング モデルを使用できます)。 SignalR Service はクライアントとハブ サーバーとの間のプロキシとして機能します。
新しいアプリケーションを作成していて、ハブ サーバーとサーバーの接続を維持したくない場合は、サーバーレス モードを選択します。 サーバーレス モードは Azure Functions と連携して動作するため、サーバーを管理する必要がありません。 REST API、Management SDK、関数バインドとアップストリーム エンドポイントを使用して全二重通信を行うことはきますが、プログラミング モデルは SignalR ライブラリとは異なります。
クライアント接続を提供するハブ サーバーと、クライアントにメッセージを直接プッシュするバックエンド アプリケーションの "両方" がある場合でも、既定モードを選択してください。 既定モードとサーバーレス モードの主な違いは、ハブ サーバーがあるかどうかと、クライアント接続のルーティング方法です。 REST API、管理 SDK、関数バインドは、両方のモードで使用できます。
1 つのシナリオに複数のサービス モードが実際に混在する場合は、ユース ケースを複数の SignalR Service インスタンスに分割し、用途に応じてサービス モードを設定することを検討してください。 クラシック モードを必要とする混在シナリオとしては、同じ SignalR リソースに 2 つの異なるハブがあるようなケースが考えられます。 一方のハブは従来の SignalR ハブとして使用され、もう一方のハブは Azure Functions で使用されます。 このような場合、既定モードのインスタンスとサーバーレス モードのインスタンスの 2 つのリソースに分割する必要があります。
次のステップ
既定モードとサーバーレス モードの使用方法の詳細については、次の記事を参照してください。