スケーリング ASP.NET SignalR ピークパフォーマンスのアプリケーション

概要

ASP.NETは、開発者に豊富な開発支援機能のセットを提供するため、リアルタイムWebアプリケーションを開発するための非常に人気のあるプラットフォームです。そのような機能のXNUMXつは、リアルタイムデータ処理ASP.NETアプリケーションを効率的に開発するのに役立つSignalRです。

SignalR（ "R"はリアルタイムを表します）は、ASP.NET Web開発者向けのよく知られたオープンソースライブラリであり、情報が利用可能になるとすぐにサーバー側から接続されているすべてのクライアントにコンテンツをプッシュできます。これにより、アプリケーションにリアルタイムWeb機能を追加するために必要な開発作業が簡素化されます。

なぜあなたは使うべきなのか ASP.NET SignalR?

SignalRを使用すると、ASP.NETアプリケーション内で、サーバー側のコードがコンテンツを接続されたシンクライアントに即座にプッシュできるようになります。これは、クライアントが新しいデータを要求するのを待つのではなく、コンテンツが利用可能になるためです。クライアントは、通常のHTTPポーリングメカニズムに依存する必要がなくなり、代わりに、SignalRはプッシュメカニズムを使用して新しいコンテンツをクライアントが利用できるようにします。これにより、アプリケーション全体のパフォーマンスとユーザーエクスペリエンスが向上します。

SignalRには非常にシンプルなAPIがあり、サーバー側から直接クライアントブラウザー内でクライアント側のJavaScript関数を呼び出すために非常に簡単に使用できます。リモートプロシージャコール（RPC）を使用してClientServer通信を呼び出し、クライアントサーバー接続管理に関する完全な.NETコードも提供します。

SignalRは、サーバーとクライアント間の完全な通信機能を処理します。これを自分で実装する必要はありません。メッセージを超高速で交換するために、SignalRにはトランスポート層が組み込まれています。あなたがする必要があるのは、SignalRリソースをASP.NETアプリケーションに導入し、そのメソッドの利用を開始することです。

参考までに、高レベルの図を示します。

SignalRはすべての接続を内部で処理し、バックエンドでは、クライアント（HTML5以降）でサポートされている場合はWebSocketが使用されます。 Web Socketsが利用できない場合は、必要に応じて自動的に古いトランスポートメカニズムにフォールバックします。これにより、開発作業が簡素化され、この通信コードを自分で作成して管理する必要がなくなります。

初めての作成 ASP.NET SignalR 申し込み

アプリケーションでSignalRを使用するのは、思ったよりはるかに簡単です。この場合、チャットハブの例を見てみましょう。 SignalRを追加して単純なASP.NETWebプロジェクトを作成することから始めることができます。これで、チャットハブプログラムの場合、SignalR接続と通信するための組み込みメソッドを含む汎用ハブクラスを呼び出すことができます。

インポートする方法は次のとおりです Microsoft.AspNet.SignalRハブ例を呼び出すサンプルプログラムのクラス 同報メッセージ 接続されているすべてのクライアント。

namespace SignalRChat
{
   public class ChatHub : Hub
   {
      public void Send(string name, string message)
      {
         // Call the broadcastMessage method to update clients.
         Clients.All.broadcastMessage(name, message);
      }
   }
}

図2：SignalRChatHubクラスの実装

次の例では、JavaScriptクライアントエンドでメソッドを定義しています。

//Add script to update the page and send messages.
   <script type="text/javascript">
      $(function () {
         //Declare a proxy to reference the hub.
         var chat = $.connection.chatHub;
		 
         // Create a function that the hub can call to broadcast messages.
         } chat.client.broadcastMessage = function (name, message) {
         // Html encode display name and message.
         ...
         });
   </script>

図3：JavaScriptの実装

ASP.NET SignalR 使用事例

リアルタイムWeb機能を使用しているASP.NETアプリケーションは、SignalRをアーキテクチャに組み込むための適切な候補です。つまり、これは、アプリケーションがサーバーからクライアントに多くの新しいコンテンツをプッシュし、データの変化に応じてユーザーがそれを消費する必要があるシナリオです。

同様に、SignalRを使用して、AJAXロングポーリングメカニズムを使用して新しいデータを取得するアプリケーションのパフォーマンスを向上させることができます。そのため、ASP.NETアプリケーションでデータが更新されるとすぐに、クライアント側のJavaScriptメソッドがSignalRによって自動的に呼び出され、データが要求されます。これにより、リアルタイムの更新がWebクライアントに即座に送信されます。

SignalRのいくつかの一般的な使用例を以下に示します。

チャットシステム
インターネットのもの（IoT）
ゲームアプリケーション
航空予約システム
証券取引所アプリケーション
もっと…

問題：SignalRは箱から出してスケーラブルではありません

ASP.NETアプリケーションにSignalRライブラリを実装することは賢明な選択ですが、線形にスケーリングできないことは、実際にはその目的全体を損なう可能性があります。理由は次のとおりです。

SignalRはWebソケットベースのモデルで動作しているため、単一サーバーの展開は正常に機能し、すべてのメッセージがWebサーバーに接続されたすべてのクライアントに送信されます。

ただし、アプリケーション要求の負荷の増加に基づいて、単一のサーバーがすぐに容量に達する可能性があります。この時点で、Webサーバーを追加し、「Webファーム」を作成してスケールアウトする必要があります。そうしている間、クライアントリクエストは分散されるため、別のWebサーバーにルーティングされることもあります。 Webソケットを介してXNUMXつのWebサーバーに接続されているクライアントは、別のWebサーバーから送信されたメッセージを受信しません。これにより、クライアントがSignalRメッセージを受信せず、同期がとれない状態が発生します。

これらのクライアントは、実際には、その機能がそれぞれのWebサーバーによってプッシュされるまで待機するため、待ち時間が長くなります。また、マルチサーバーベースのアプリケーションでは、すべてのWebサーバーが着信する新しいデータを呼び出す必要はありません。したがって、この新しいデータがそれぞれのクライアントにまったくプッシュされず、メッセージが完全に失われる可能性が高くなります。

例として、リアルタイムの株式市場アプリケーションを取り上げましょう。ここでは、数千の株式価値が毎秒変化しています。このようなシナリオでは、価格が変更されるたびに、エンドクライアントは正確で絶対的に正しい情報を必要とします。

株式市場は大量の大量のトランザクションデータを処理するため、すべての情報をすべてのユーザーにタイムリーにプッシュすることが非常に重要です。 Webファームがあると、一部のユーザーの待ち時間が長くなる可能性があり、一部のユーザーは重要な更新を完全に見逃す可能性があります。これにより、ユーザーエクスペリエンスが低下し、ビジネスに悪影響を及ぼします。

これらの問題に対処するために、Microsoftは、すべてのWebサーバーが同時に接続される中央メッセージストアとして一般的に定義できるバックプレーンを使用するオプションを提供しています。

SignalR backplane Webサーバーが接続して、接続されている独自のクライアントに送信するのではなく、最初にすべてのメッセージを自分自身に送信できるようにします。次に、バックプレーンはこれらのメッセージをインターンするすべてのWebサーバーにブロードキャストし、接続されたクライアントにこれらのメッセージを送信します。これにより、クライアントが接続されていないWebサーバーによって呼び出された場合でも、すべてのメッセージがすべてのエンドクライアントに送信されます。

SignalR backplane ディスク、データベース、メッセージバス、またはメモリ内分散キャッシュの場合があります。最も一般的に使用されるバックプレーンオプションとそれに関連する問題について説明します。

リレーショナルデータベースに関する問題 SignalR Backplane

SignalRは、大量のデータを処理するリアルタイムアプリケーションで使用されます。バックプレーンは、極端なメッセージ負荷とそれも高速で信頼性の高い方法で管理できる必要があります。リレーショナルデータベースは一般的にバックプレーンとして使用されますが、バックプレーンは本質的にスケーラブルである必要があるため、あまり適していません。

Webファーム内の10台のWebサーバーに展開されているASP.NETEコマースアプリケーションがある例を見てみましょう。これらの10個のWebサーバーはすべて、SignalRを介して個別のブラウザーベースのクライアントに接続されており、Webサーバーもこの場合はデータベースであるバックプレーンに接続されています。

Webサーバーの1つがそれぞれ10つのメッセージを生成して合計10のメッセージを生成する場合、これらの10のメッセージはバックプレーンに送信され、データベースはこれらすべてのメッセージを接続されている100のWebサーバーすべてにブロードキャストします。これにより、データベースによってブロードキャストされているメッセージの合計は最大XNUMXになります。

同じセットアップを想像してみてください。ただし、アプリケーションはおしゃべりで有名であり、サーバーは常に合計10000メッセージ（Webサーバーあたり1000メッセージ）を生成します。バックプレーンは、同時に100000メッセージ（10000 x 10）をブロードキャストする必要があります。リクエストの数が増えると、データベースがチョークダウンするのがいかに簡単であるかがわかります。

リレーショナルデータベースを使用する場合のいくつかの問題があります SignalR backplane:

通常、トランザクションの負荷は非常に高く、遅延要因を除外するには、より高速な配信が必要です。リレーショナルデータベースは低速であり、リアルタイムのデータ処理負荷のピーク時にも機能しなくなる可能性があります。
ディスクに基づいているため、リレーショナルデータベースは、高負荷で必要なスループットを達成するのに十分な速度で動作することはできません。
最も重要なことは、リレーショナルデータベースには、より多くの負荷を処理するためにサーバーを追加できない線形スケーリング機能が明らかに欠けていることです。

不具合 Redis as SignalR Backplane

XNUMX番目のオプションは使用することです Redis あなたのように SignalR backplane これは、リレーショナルデータベースで発生するパフォーマンスとスケーラビリティに関連する問題を解決しますが、適切な選択ではありません。これに関するいくつかの理由は次のとおりです。

Redis Linuxベースの分散キャッシュであり、ネイティブの.NETオプションではありません。 Linuxベースのシステムを使用して ASP.NET SignalR LinuxスタックとWindowsが必要な場合はあまり意味がなく、このセットアップを管理および監視するには個別の専門知識が必要になります。
.NET開発者は、このようなリアルタイムWebアプリケーションを開発している間、常に100％ネイティブの.Netスタックを待ち望んでいます。非ネイティブの.NETソリューションを次のように管理するのは直感に反します。 SignalR backplane 他のすべてのアプリケーションモジュールは100％ネイティブの.NETです。
の別の制限 Redis MicrosoftAzureプラットフォームに移植された.NETWindowsのバージョンには、ユーザーのレビューによると、バグがたくさんあります。 Redis Azureで独自の.NETWindows移植バージョンを使用することから。

これは作る Redis、互換性の観点からの.NET開発者間のあいまいな選択。

解決策：使用 NCache as SignalR Backplane

NCache は、によって開発されたインメモリ分散キャッシングシステムです。 Alachisoft バックプレーンとして使用するのに最も適切なオプションです。 NCache は、スケーラブルなメモリとCPU容量を提供するために一緒にプールされる安価なキャッシュサーバーのクラスターです。基本的に、複数のサーバーの論理容量には、次のように使用されるすべての機能が付属しています。 SignalR backplane.

使用についての最もよい部分 NCache あなたのように SignalR backplane それはXNUMXパーセントネイティブの.NETであり、ASP.NETアプリケーションで大きなコード変更を行う必要がないということです。これは、バックプレーンメッセージを管理する機能を提供するだけでなく、を使用してこれらのメッセージを監視することもできるプラグアンドプレイオプションのようなものです。 NCache パフォーマンス監視ツール。

NCache ASP.NETアプリケーションでバックプレーンとして使用されるSignalR拡張機能を提供します。

Webファーム内のすべてのWebサーバーはに登録されています NCache NCache Pub/Subメッセージングプラットフォーム。 Webサーバーは、SignalRメッセージの特定のトピックを登録します。 NCache 次に、これらのメッセージをすべてのWebサーバーにブロードキャストします。これは基本的に双方向のメッセージ送信構造であり、パブリッシャーはサブスクライバーになることができ、同様にその逆も可能です。

使い方 NCache として SignalR Backplane — 図5：使用 NCache として SignalR Backplane

プラグインします NCache SignalRベースのアプリケーションのバックプレーンとして、ステップバイステップの実装ガイドに記載されているXNUMX行のコードを導入するだけで済みます。

なぜ NCache バックプレーンはSQLServerよりも優れていますか？

ASP.NETアプリケーションで最高のユーザーエクスペリエンスを実現するには、 NCache 非常に高速で信頼性が高くスケーラブルなバックプレーンとして機能し、大量の通知を処理します。以下に、使用の主な利点をいくつか示します。 NCache バックプレーンとしてのRDBMの代わりに。

NCache 線形にスケーラブルです（高スループットと低遅延）
の最も重要な特徴 NCache バックプレーンは、最大のスループットと最小の遅延を提供することです。すべてのメッセージ処理をメモリ内に保持し、遅延が増加する可能性を排除することで、大量のデータを高速にシームレスに処理します。

すべてのメッセージを時間内に配信するには、 NCache キャッシュクラスター内の使用可能なすべてのサーバーに負荷を分散することにより、送信中に最大のスループットを提供します。また、実行時にサーバーを追加することもできます。

参考までに、パフォーマンスベンチマークの数値をいくつか示します。

図6：のパフォーマンス数値 NCache

これにより、アプリケーションアーキテクチャ内で全体的に線形のスケーラビリティが得られ、特に極端な負荷がかかった場合にアプリケーションのパフォーマンスが低下することを心配する必要はありません。
NCache 非常に信頼性が高い
のXNUMX番目の特徴 NCache バックプレーンはその非常に信頼性が高いです。特にミッションクリティカルなアプリケーションの場合に、メッセージの確実な配信を保証するために、 NCache バックプレーンとして使用できるため、サーバーがダウンしたり、メンテナンスのためにダウンしたりしてメッセージが失われることを心配する必要はありません。クラスターで使用される各キャッシュサーバーのバックアップを保持します。 SignalR backplane これは、サーバーがダウンした場合に自動的に使用可能になります。

の極端な信頼性 NCache これは、バックプレーンに接続されているすべてのWebサーバーにすべてのメッセージをブロードキャストするという特性に起因します。他のサーバーにデータをバックアップすることで、ミッションクリティカルなアプリケーションが重いペイロードを転送している間、データが失われる可能性がなくなります。
NCache 高可用性
のもう一つの重要な特徴 NCache バックプレーンはその高可用性です。と NCache あなたのとしてインストール SignalR backplane、メッセージが常にアクティブなキャッシュクラスタを介して転送されるようになると、システムの可用性が高くなります。

NCache アーキテクチャは、さまざまなキャッシングトポロジのXNUMXつに基づくことができる「AlwaysActiveCacheCluster」を通じて高可用性機能を保証します。たとえば、「Partition-replica」トポロジは、すべてのサーバーでアクティブなパーティションを提供し、各サーバーにはそのバックアップがあります。したがって、サーバーがダウンした場合、クライアントはそれを自動的に検出し、存続している他のノードへの接続をフェイルオーバーします。

のキャッシュクラスター NCache は、1台のサーバーのみが稼働している場合でも動作することができます。これは、XNUMX％の稼働時間のシナリオで最低限必要なものです。この機能は、サーバーが自然災害に見舞われた場合、またはメンテナンスのためにサーバーを意図的に停止した場合に効果があります。簡単に言えば、の実用的なキャッシングトポロジ NCache SignalRベースのアプリケーションで100％の稼働時間を達成するのに役立ちます。

図7：パーティション-レプリカキャッシングトポロジ

なぜ NCache よりも優れている Redis?

NCache よりも優れています Redis 機能の観点から。開発者が直面するすべての欠点を除外するには Redis 分散キャッシュシステム、 NCache これらのXNUMXつの最上級の機能があります。

ネイティブ.NET： NCache は100％ネイティブの.NETであるため、SignalRを使用するASP.NETアプリケーションに最適です。一方で、 Redis Linuxのバックグラウンドから来ており、ネイティブの.NETキャッシュではありません。
より速い Redis: NCache より実際に高速であります Redis. NCache クライアントキャッシュ機能は NCache パフォーマンスが大幅に向上します。
その他の機能： NCache 非常に重要な分散キャッシュ機能を多数提供します。 Redis ではない。詳細はこちらをご覧ください Redis vs NCache

実装 NCache SignalR Backplane

デプロイできます NCache あなたのように SignalR Backplane XNUMX行の変更だけで、以下のステップバイステップのチュートリアルに従って、アプリケーションにこれを装備できます。

NuGetパッケージをインストールします
インストールすることから始めます Alachisoft.NCache.SignalR パッケージマネージャーコンソールで次のコマンドを実行して、アプリケーションにNuGetパッケージを追加します。
```
Install-Package Alachisoft.NCache.SignalR
```
名前空間を含める
あなたの中で スタートアップ.cs ファイルには、以下に説明するように、これらXNUMXつの名前空間を含めます。
- Alachisoft.NCache.SignalR
- Microsoft.AspNet.SignalR

Web.configを変更する

Web.configファイルで、cacheNameとイベントキーセクションにタグ：

<configuration>
   <appSettings>
      <add key="cache" value="myPartitionedCache"/>
      <add key="eventKey" value="Chat"/>
   </appSettings>
</configuration>

図8：Web.configの変更

登録する NCache as SignalR Backplane あなたのアプリケーションのために

Useのインスタンスを登録しますNCache次のいずれかのオーバーロードでのアプリケーションのStartup.csの（）メソッド：

過負荷1：

public static IDependencyResolver
	UseNCache(this IDependencyResolver resolver, string cacheName, string eventKey);
public class Startup
{
 	public void Configuration(IAppBuilder app)
	{
		string cache, eventKey;
		cache = ConfigurationManager.AppSettings["cache"];
		eventKey = ConfigurationManager.AppSettings["eventKey"];
		//using NCache SignalR
		GlobalHost.DependencyResolver.UseNCache(cache, eventKey);
		app.MapSignalR();
	}
}

図9：登録 NCache SignalR Backplane （過負荷1）

過負荷2：

public static IDependencyResolver
UseNCache(this IDependencyResolver resolver, NCacheScaleoutConfiguration configuration);

public class Startup
{
	public void Configuration(IAppBuilder app)
	{
		string cache, eventKey;
		cache = ConfigurationManager.AppSettings["cache"];
		eventKey = ConfigurationManager.AppSettings["eventKey"];
		NCacheScaleoutConfiguration configuration = new NCacheScaleoutConfiguration(cache, eventKey);
		//using NCache SignalR
		GlobalHost.DependencyResolver.UseNCache(configuration);
		app.MapSignalR();
	}
 ...

図10：登録 NCache SignalR Backplane （過負荷2）

まとめ

結論として、 NCache は本質的に.NETベースのメモリ内分散キャッシュであり、すべてのリアルタイムASP.NET WebアプリケーションでSignalRのバックプレーンとして使用して、Webアプリケーションのパフォーマンスを向上させることができます。

他の利用可能なオプションとは一線を画す機能には、超高速パフォーマンス、100％の稼働時間、データの信頼性、メッセージの確実な配信、最小の遅延で最大のスループットを維持する機能などがあります。