Azure SignalR サービスによる ASP.NET Core SignalR アプリケーションのスケーリング
SignalR のアプリの開発
SignalR は現在、Web アプリケーションで 使用するために 2 つのバージョン で使用できます。
- ASP.NET SignalR
- 新しい ASP.NET Core SignalR
ASP.NET Core SignalR は、以前のバージョンのリライトです。 その結果、ASP.NET Core SignalR は以前の SignalR バージョンと下位互換性がありません。 API および動作が異なります。 Azure SignalR Service では、両方のバージョンがサポートされています。
Azure SignalR Service を使用すると、実際の Web アプリケーションを複数のプラットフォーム (Windows、Linux、macOS) Azure アプリ Service、IIS、Nginx、Apache、Docker でホストできます。 独自のプロセスで自己ホストを使用することもできます。
アプリケーションの目標に次のものが含まれる場合は、Azure SignalR Service が最適な選択肢です。
- リアルタイムコンテンツアップデートでWebクライアントを更新するための最新機能をサポート
- 複数のプラットフォーム (Azure、Windows、Linux、macOS) で実行されている
- 異なる環境でのホスティング
なぜ SignalR を自分でデプロイしないのか
SignalR をバックエンド コンポーネントとしてサポートする独自の Azure Web アプリを Web アプリケーション全体にデプロイすることは、依然として有効なアプローチです。
Azure SignalR サービスを使用する主な理由の 1 つは、シンプルさです。 Azure SignalR サービスでは、パフォーマンス、スケーラビリティ、可用性などの問題を処理する必要がありません。 これらの問題は、99.9% のサービス レベル アグリーメントで対処されます。
また、WebSocket は、通常はリアルタイムのコンテンツ更新をサポートするための優先手法です。 ただし、多数の永続的な WebSocket 接続の負荷分散は、スケーリングの際に解決するのが複雑な問題になります。 一般的なソリューションでは、DNS 負荷分散、ハードウェア ロード バランサー、ソフトウェア負荷分散が使用されます。 Azure SignalR サービスがこの問題を処理します。
ASP.NET Core SignalR の場合、もう 1 つの理由は、Web アプリケーションを実際にホストするための要件がまったくない場合です。 Web アプリケーションのロジックでは、サーバーレス コンピューティングが使用される場合があります。 たとえば、Azure Functions トリガーでコードをオンデマンドでのみホストおよび実行できる可能性があります。 コードはオンデマンドでのみ実行され、クライアントとの長い接続がメインされないため、このシナリオは困難な場合があります。 Azure SignalR サービスでは、サービスが既に接続を管理しているため、このような状況に対処できます。 詳細については、Azure Functions で SignalR Service を使用する方法の概要を参照してください。 ASP.NET SignalR は別のプロトコルを使用するため、ASP.NET SignalR ではこのようなサーバーレス モードはサポートされていません。
スケーリングの方法
SignalR は、SQL Server、Azure Service Bus、または Azure Cache for Redis を使用してスケーリングするのが一般的です。 Azure SignalR サービスによってスケーリング アプローチが処理されます。 パフォーマンスとコストはこれらのアプローチと同等で、これらの他のサービスを扱う複雑さを伴いません。 行う必要があるは、サービスのユニット数の更新だけです。 各ユニットでは、最大 1000 のクライアント接続がサポートされます。