SignalR のスケールアウト入門Introduction to Scaleout in SignalR

によってMike WassonPatrick Fletcherby Mike Wasson, Patrick Fletcher


このドキュメントは SignalR の最新バージョンはありません。This documentation isn't for the latest version of SignalR. 見てASP.NET Core SignalRします。Take a look at ASP.NET Core SignalR.

このトピックで使用されるソフトウェアのバージョンSoftware versions used in this topic

このトピックの以前のバージョンPrevious versions of this topic

SignalR の以前のバージョンについては、次を参照してください。以前のバージョンの SignalRします。For information about earlier versions of SignalR, see SignalR Older Versions.

意見やご質問Questions and comments

このチュートリアルの良い点に関するフィードバックや、ページ下部にあるコメントで改善できる点をお知らせください。Please leave feedback on how you liked this tutorial and what we could improve in the comments at the bottom of the page. チュートリアルに直接関係のない質問がある場合は、ASP.NET SignalR フォーラムまたはStackOverflow.comにて投稿してください。If you have questions that are not directly related to the tutorial, you can post them to the ASP.NET SignalR forum or

一般は、web アプリケーションのスケール設定の 2 つの方法があります:スケール アップスケール アウトします。In general, there are two ways to scale a web application: scale up and scale out.

  • スケール アップは、RAM、Cpu などの大規模なサーバー (またはより大きな VM) を使用することを意味します。Scale up means using a larger server (or a larger VM) with more RAM, CPUs, etc.
  • スケール アウト、負荷を処理するより多くのサーバーを追加することを意味します。Scale out means adding more servers to handle the load.

スケール アップの問題は、迅速に、マシンのサイズの上限に達したことです。The problem with scaling up is that you quickly hit a limit on the size of the machine. さらに、スケール アウトする必要があります。ただし、スケール アウトするときにクライアントを別のサーバーにルーティングを取得できます。Beyond that, you need to scale out. However, when you scale out, clients can get routed to different servers. 1 つのサーバーに接続されているクライアントは、別のサーバーから送信されたメッセージを受信しません。A client that is connected to one server will not receive messages sent from another server.

1 つのソリューションと呼ばれるコンポーネントを使用して、サーバー間でメッセージを転送するように、バック プレーンします。One solution is to forward messages between servers, using a component called a backplane. 有効になっているバック プレーン、各アプリケーション インスタンスが、バック プレーンにメッセージを送信し、バック プレーンの他のアプリケーション インスタンスに転送します。With a backplane enabled, each application instance sends messages to the backplane, and the backplane forwards them to the other application instances. (電子機器、バック プレーンです並列コネクタのグループ。(In electronics, a backplane is a group of parallel connectors. たとえて、SignalR のバック プレーン接続する複数のサーバーです。)By analogy, a SignalR backplane connects multiple servers.)

現在、SignalR は、次の 3 つのバック プレーンを提供します。SignalR currently provides three backplanes:

  • Azure Service Busします。Azure Service Bus. Service Bus は、メッセージング インフラストラクチャを使用する疎結合方式でメッセージを送信するコンポーネントです。Service Bus is a messaging infrastructure that allows components to send messages in a loosely coupled way.
  • Redisします。Redis. Redis はメモリ内のキー値ストアです。Redis is an in-memory key-value store. Redis では、メッセージを送信するため、(「パブリッシュ/サブスクライブ」) の発行/サブスクライブ パターンをサポートしています。Redis supports a publish/subscribe ("pub/sub") pattern for sending messages.
  • SQL Serverします。SQL Server. SQL Server バック プレーンでは、SQL テーブルにメッセージを書き込みます。The SQL Server backplane writes messages to SQL tables. バック プレーンでは、効率的なメッセージングを Service Broker を使用します。The backplane uses Service Broker for efficient messaging. ただし、これは Service Broker が有効になっていない場合にも機能します。However, it also works if Service Broker is not enabled.

Azure 上のアプリケーションをデプロイする場合は、Redis バック プレーンを使用して、使用することを検討してくださいAzure Redis Cacheします。If you deploy your application on Azure, consider using the Redis backplane using Azure Redis Cache. サーバー ファームに展開する場合は、SQL Server または Redis のバック プレーンを検討してください。If you are deploying to your own server farm, consider the SQL Server or Redis backplanes.

次のトピックには、各バック プレーンのステップバイ ステップ チュートリアルが含まれます。The following topics contain step-by-step tutorials for each backplane:


Signalr では、すべてのメッセージはメッセージ バスを通じて送信されます。In SignalR, every message is sent through a message bus. メッセージ バス実装、 IMessageBusインターフェイスで、パブリッシュ/サブスクライブ抽象化を提供します。A message bus implements the IMessageBus interface, which provides a publish/subscribe abstraction. 既定値を置き換えることで、バック プレーンの動作IMessageBusバス バック プレーンに対するに設計されています。The backplanes work by replacing the default IMessageBus with a bus designed for that backplane. Redis メッセージ バスは、たとえば、 RedisMessageBus、Redis を使用してパブリッシュ/サブスクライブメッセージを送受信するためのメカニズムです。For example, the message bus for Redis is RedisMessageBus, and it uses the Redis pub/sub mechanism to send and receive messages.

各サーバー インスタンスは、バスを介してバック プレーンに接続します。Each server instance connects to the backplane through the bus. メッセージが送信されると、バック プレーンに移動して、バック プレーンのすべてのサーバーに送信します。When a message is sent, it goes to the backplane, and the backplane sends it to every server. サーバーは、バック プレーンからメッセージを取得、そのローカル キャッシュ内でメッセージが保存されます。When a server gets a message from the backplane, it puts the message in its local cache. サーバーはし、そのローカル キャッシュから、クライアントにメッセージを配信します。The server then delivers messages to clients from its local cache.

各クライアント接続のため、カーソルを使用して、メッセージ ストリームを読み取り中に、クライアントの進行状況が追跡されます。For each client connection, the client's progress in reading the message stream is tracked using a cursor. (カーソルは、メッセージ ストリーム内の位置を表します)。クライアントが切断して再接続して、クライアントのカーソル値の後に到着したすべてのメッセージ バスを要求します。(A cursor represents a position in the message stream.) If a client disconnects and then reconnects, it asks the bus for any messages that arrived after the client's cursor value. 接続を使用する場合に、同じことが起こりますポーリング時間の長いします。The same thing happens when a connection uses long polling. 長いポーリング要求が完了した後、クライアントは新しい接続を開き、カーソルより後に到着したメッセージを要求します。After a long poll request completes, the client opens a new connection and asks for messages that arrived after the cursor.

カーソルのメカニズムの動作でクライアントが別のサーバーにルーティングされる場合でも再接続します。The cursor mechanism works even if a client is routed to a different server on reconnect. バック プレーンは、すべてのサーバーを認識しており、クライアントが接続する先のサーバーかは関係ありません。The backplane is aware of all the servers, and it doesn't matter which server a client connects to.


バック プレーンを使用して、メッセージの最大スループットは、クライアントは、1 台のサーバー ノードに直接話すときよりも低い。Using a backplane, the maximum message throughput is lower than it is when clients talk directly to a single server node. バック プレーンがバック プレーンがボトルネックになることができますので、すべてのノードにすべてのメッセージを転送するためです。That's because the backplane forwards every message to every node, so the backplane can become a bottleneck. この制限は、問題であるかどうかは、アプリケーションによって異なります。Whether this limitation is a problem depends on the application. たとえば、SignalR の一般的なシナリオを示します。For example, here are some typical SignalR scenarios:

  • サーバー ブロードキャスト(株価情報など)。バック プレーンがこのシナリオに動作するは、サーバー メッセージが送信される速度を制御するためです。Server broadcast (e.g., stock ticker): Backplanes work well for this scenario, because the server controls the rate at which messages are sent.
  • クライアントで(チャットなど)。このシナリオでバック プレーン場合があります、ボトルネックのメッセージの数に合わせてクライアントの数メッセージの数が増加した場合は、それに比例して増えるクライアントが参加します。Client-to-client (e.g., chat): In this scenario, the backplane might be a bottleneck if the number of messages scales with the number of clients; that is, if the rate of messages grows proportionally as more clients join.
  • 高頻度リアルタイム メッセージング(リアルタイムのゲームなど)。このシナリオでは、バック プレーンは推奨されません。High-frequency realtime (e.g., real-time games): A backplane is not recommended for this scenario.

SignalR スケール アウトのトレースを有効にします。Enabling Tracing For SignalR Scaleout

バック プレーンのトレースを有効にするには、web.config ファイルのルートの下に次のセクションを追加構成要素。To enable tracing for the backplanes, add the following sections to the web.config file, under the root configuration element:

      <source name="SignalR.SqlMessageBus">
          <add name="SignalR-Bus" />
      <source name="SignalR.ServiceBusMessageBus">
          <add name="SignalR-Bus" />
      <source name="SignalR.ScaleoutMessageBus">
          <add name="SignalR-Bus" />
      <add name="SignalRSwitch" value="Verbose" />
      <!-- Off, Critical, Error, Warning, Information, Verbose -->
      <add name="SignalR-Bus" 
          initializeData="bus.log.txt" />
    <trace autoflush="true" />
  . . .