스케일링 ASP.NET SignalR 최고 성능을 위한 애플리케이션

개요

ASP.NET은 개발자에게 다양한 개발 지원 기능을 제공하므로 실시간 웹 응용 프로그램 개발에 매우 널리 사용되는 플랫폼입니다. 이러한 기능 중 하나는 실시간 데이터 처리 ASP.NET 응용 프로그램을 효율적으로 개발하는 데 도움이 되는 SignalR입니다.

SignalR("R"은 실시간을 나타냄)은 ASP.NET 웹 개발자를 위한 잘 알려진 오픈 소스 라이브러리로, 정보가 제공되는 즉시 서버 측에서 연결된 모든 클라이언트로 콘텐츠를 푸시할 수 있습니다. 이는 애플리케이션에 실시간 웹 기능을 추가하는 데 필요한 개발 노력을 단순화하는 데 도움이 됩니다.

사용해야 하는 이유 ASP.NET SignalR?

SignalR은 ASP.NET 응용 프로그램 내에서 클라이언트가 새 데이터에 대해 다른 요청을 할 때까지 기다리지 않고 사용할 수 있게 되므로 서버 측 코드가 연결된 씬 클라이언트에 콘텐츠를 즉시 푸시하도록 하는 기능을 제공합니다. 클라이언트는 더 이상 일반적인 HTTP 폴링 메커니즘에 의존할 필요가 없으며 대신 SignalR은 클라이언트가 사용할 수 있는 새 콘텐츠에 푸시 메커니즘을 사용합니다. 이는 전반적인 애플리케이션 성능과 사용자 경험을 개선하는 데 도움이 됩니다.

SignalR에는 서버 측에서 직접 클라이언트 브라우저 내부의 클라이언트 측 JavaScript 함수를 호출하는 데 사용하기 매우 쉬운 매우 간단한 API가 있습니다. RPC(원격 프로시저 호출)를 사용하여 ClientServer 통신을 호출하고 클라이언트-서버 연결 관리와 관련된 완전한 .NET 코드도 제공합니다.

SignalR은 서버와 클라이언트 간의 완전한 통신 기능을 처리하므로 직접 구현할 필요가 없습니다. 초고속 메시지 교환을 위해 SignalR에 전송 계층이 내장되어 있습니다. ASP.NET 응용 프로그램에 SignalR 리소스를 도입하고 해당 메서드를 사용하기 시작하기만 하면 됩니다.

다음은 참조용 상위 수준 다이어그램입니다.

SignalR에서 메서드 호출 — 그림 1: SignalR의 메서드 호출(MSDN에서)

SignalR은 내부적으로 모든 연결을 처리하고 백엔드에서 클라이언트(HTML5 이상)에서 지원하는 경우 웹 소켓이 사용됩니다. 웹 소켓을 사용할 수 없는 경우 필요한 경우 자동으로 이전 전송 메커니즘으로 대체합니다. 이것은 개발 노력을 단순화하고 더 이상 이 통신 코드를 직접 작성하고 관리할 필요가 없습니다.

첫 번째 만들기 ASP.NET SignalR 어플리케이션

애플리케이션에서 SignalR을 사용하는 것은 생각보다 훨씬 쉽습니다. 이 경우 Chat Hub를 예로 들어 보겠습니다. SignalR을 추가하여 간단한 ASP.NET 웹 프로젝트를 만드는 것으로 시작할 수 있습니다. 이제 Chat Hub 프로그램의 경우 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: SignalR ChatHub 클래스 구현

다음 예제는 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 고객 사례

실시간 웹 기능을 사용하는 모든 ASP.NET 응용 프로그램은 아키텍처에 SignalR을 통합하기에 적합한 후보입니다. 즉, 애플리케이션이 서버에서 클라이언트로 많은 새 콘텐츠를 푸시하고 데이터가 변경됨에 따라 사용자가 이를 소비해야 하는 시나리오입니다.

마찬가지로 SignalR을 사용하여 AJAX 긴 폴링 메커니즘을 사용하여 새 데이터를 검색하는 애플리케이션의 성능을 향상시킬 수 있습니다. 따라서 ASP.NET 응용 프로그램에 데이터 업데이트가 있는 즉시 SignalR에서 클라이언트 측 JavaScript 메서드를 자동으로 호출하여 데이터를 요청합니다. 이렇게 하면 실시간 업데이트가 웹 클라이언트에 즉시 전송됩니다.

SignalR의 몇 가지 인기 있는 사용 사례가 아래에 나와 있습니다.

채팅 시스템
사물의 인터넷 IOT ()
게임 애플리케이션
항공사 예약 시스템
증권 거래소 애플리케이션
더보기.

문제: SignalR은 즉시 확장할 수 없습니다.

ASP.NET 응용 프로그램에서 SignalR 라이브러리를 구현하는 것이 현명한 선택일 수 있지만 선형으로 확장할 수 없으면 실제로 전체 목적을 무효화할 수 있습니다. 이유는 다음과 같습니다.

SignalR은 웹 소켓 기반 모델에서 작업하고 있으므로 단일 서버 배포는 모든 웹 서버에 연결된 클라이언트로 전송되는 모든 메시지와 함께 잘 작동합니다.

그러나 단일 서버는 애플리케이션 요청 로드 증가에 따라 곧 용량에 도달할 수 있습니다. 이 시점에서 웹 서버를 더 추가하고 '웹 팜'을 만들어 스케일 아웃해야 합니다. 그렇게 하는 동안 클라이언트 요청이 분산되어 다른 웹 서버로 라우팅될 수도 있습니다. 웹 소켓을 통해 한 웹 서버에 연결된 클라이언트는 다른 웹 서버에서 보낸 메시지를 받지 않습니다. 이로 인해 클라이언트가 SignalR 메시지를 수신하지 못하고 동기화되지 않은 상태로 유지되는 상황이 발생합니다.

이러한 클라이언트는 실제로 해당 기능이 자체 웹 서버에 의해 푸시될 때까지 기다리게 되어 대기 시간이 늘어납니다. 또한 다중 서버 기반 응용 프로그램에서 모든 웹 서버가 들어오는 새 데이터를 호출할 필요는 없습니다. 따라서 이 새로운 데이터가 해당 클라이언트에 전혀 푸시되지 않고 메시지가 완전히 누락될 가능성이 큽니다.

수천 개의 주식 값이 매초 변경되는 실시간 주식 시장 애플리케이션을 예로 들어 보겠습니다. 이러한 시나리오에서 최종 고객은 가격이 변경될 때마다 정확하고 절대적으로 정확한 정보가 필요합니다.

주식 시장은 엄청난 양의 높은 거래 데이터를 다루며 모든 정보를 적시에 모든 사용자에게 푸시하는 것이 매우 중요합니다. 웹 팜이 있으면 일부 사용자의 대기 시간이 증가할 수 있으며 일부 사용자는 중요한 업데이트를 완전히 놓칠 수 있습니다. 이는 사용자 경험을 저하시키고 비즈니스에 부정적인 영향을 미칩니다.

이러한 문제를 해결하기 위해 Microsoft는 일반적으로 모든 웹 서버가 동시에 연결되는 중앙 메시지 저장소로 정의될 수 있는 백플레인을 사용하는 옵션을 제공합니다.

SignalR backplane 웹 서버가 연결된 클라이언트에 보내는 대신 모든 메시지를 먼저 자신에게 연결하고 보낼 수 있습니다. 그런 다음 백플레인은 이러한 메시지를 인턴으로 보내는 모든 웹 서버에 브로드캐스트하고 이러한 메시지를 연결된 클라이언트에 전송합니다. 이렇게 하면 클라이언트가 연결되지 않은 웹 서버에서 호출한 경우에도 모든 메시지가 모든 최종 클라이언트로 전송됩니다.

SignalR backplane 디스크, 데이터베이스, 메시지 버스 또는 메모리 내 분산 캐시가 될 수 있습니다. 가장 일반적으로 사용되는 백플레인 옵션과 관련 문제에 대해 논의하겠습니다.

관계형 데이터베이스의 문제 SignalR Backplane

SignalR은 방대한 양의 데이터를 처리하는 실시간 애플리케이션에 사용됩니다. 백플레인은 극단적인 메시지 로드를 빠르고 안정적인 방식으로 관리할 수 있어야 합니다. 관계형 데이터베이스는 일반적으로 백플레인으로 사용되며 백플레인은 본질적으로 확장 가능해야 하므로 적합하지 않습니다.

웹 팜의 10개 웹 서버에 배포된 ASP.NET 전자 상거래 응용 프로그램이 있는 예를 들어 보겠습니다. 이 10개의 웹 서버에는 모두 SignalR을 통해 연결된 별도의 브라우저 기반 클라이언트가 있으며 웹 서버도 이 경우 데이터베이스인 백플레인에 연결됩니다.

웹 서버 중 하나가 각각 총 1개의 메시지를 만드는 10개의 메시지를 생성하면 이 10개의 메시지가 백플레인으로 전송되고 데이터베이스는 이 모든 메시지를 연결된 10개의 모든 웹 서버에 브로드캐스트합니다. 총 100개의 메시지가 데이터베이스에서 브로드캐스트됩니다.

이제 동일한 설정을 상상해 보십시오. 그러나 응용 프로그램이 수다스럽기로 악명이 높으며 귀하의 서버는 주어진 순간에 총 10000개의 메시지(웹 서버당 1000개의 메시지)를 생성합니다. 백플레인은 동시에 100000개의 메시지(10000 x 10)를 브로드캐스트해야 합니다. 요청 수가 증가하면 데이터베이스가 얼마나 쉽게 질식하는지 알 수 있습니다.

다음은 관계형 데이터베이스를 사용할 때의 몇 가지 문제입니다. SignalR backplane:

일반적으로 트랜잭션 로드는 매우 높으며 대기 시간 요소를 배제하려면 더 빠른 전달이 필요합니다. 관계형 데이터베이스는 느리고 최대 실시간 데이터 처리 부하에서 질식할 수도 있습니다.
디스크를 기반으로 하는 관계형 데이터베이스는 높은 부하에서 원하는 처리량을 달성할 만큼 충분히 빠르게 작동할 수 없습니다.
가장 중요한 것은 관계형 데이터베이스에는 더 많은 부하를 처리하기 위해 더 많은 서버를 추가할 수 없는 선형 확장 기능이 분명히 부족하다는 것입니다.

문제 Redis as SignalR Backplane

두 번째 옵션은 Redis 너처럼 SignalR backplane 이는 관계형 데이터베이스와 관련된 성능 및 확장성 관련 문제를 해결하지만 적절한 선택이 아닙니다. 다음은 이와 관련된 몇 가지 이유입니다.

Redis Linux 기반 분산 캐시이며 기본 .NET 옵션이 아닙니다. Linux 기반 시스템을 사용하여 ASP.NET SignalR Windows와 함께 Linux 스택이 있어야 하고 이 설정을 관리하고 모니터링하기 위해 별도의 전문 지식이 필요한 곳에서는 의미가 없습니다.
.NET 개발자는 실시간 웹 애플리케이션을 개발하는 동안 항상 100% 기본 .Net 스택을 갈망합니다. 네이티브가 아닌 .NET 솔루션을 관리하는 것은 직관적이지 않습니다. SignalR backplane 다른 모든 애플리케이션 모듈은 100% 기본 .NET입니다.
의 또 다른 한계 Redis Microsoft Azure 플랫폼의 .NET Windows 이식 버전은 사용자 리뷰에 따라 버그로 가득 차 있기 때문에 자제합니다. Redis Azure에서 자체 .NET Windows 이식 버전을 사용하지 않도록 합니다.

이 만든다 Redis, 호환성 관점에서 볼 때 .NET 개발자 사이의 양면적인 선택입니다.

솔루션: 사용 NCache as SignalR Backplane

NCache 에서 개발한 인메모리 분산 캐싱 시스템입니다. Alachisoft 백플레인으로 사용하기에 가장 적합한 옵션입니다. NCache 확장 가능한 메모리와 CPU 용량을 제공하기 위해 함께 풀링되는 저렴한 캐시 서버의 클러스터입니다. 본질적으로 여러 서버의 논리적 용량으로 모든 기능을 제공합니다. SignalR backplane.

사용에 대한 가장 좋은 부분 NCache 너처럼 SignalR backplane XNUMX% 기본 .NET이고 ASP.NET 응용 프로그램에서 주요 코드를 변경할 필요가 없다는 것입니다. 이것은 백플레인 메시지를 관리할 수 있는 기능을 제공할 뿐만 아니라 다음을 사용하여 이러한 메시지를 모니터링할 수 있는 플러그 앤 플레이 옵션과 같습니다. NCache 성능 모니터링 도구.

NCache ASP.NET 응용 프로그램에서 백플레인으로 사용할 SignalR 확장을 제공합니다.

웹 팜의 모든 웹 서버는 다음으로 등록됩니다. NCache 사용 NCache Pub/Sub 메시징 플랫폼. 웹 서버는 SignalR 메시지에 대한 특정 주제를 등록하고 NCache 그런 다음 이러한 메시지를 모든 웹 서버에 브로드캐스트합니다. 기본적으로 게시자가 구독자가 될 수 있고 그 반대의 경우도 마찬가지인 양방향 메시지 전송 구조입니다.

플러그인에 NCache SignalR 기반 애플리케이션의 백플레인으로 단계별 구현 가이드에 언급된 한 줄의 코드만 도입하면 됩니다.

NCache 백플레인이 SQL Server보다 낫습니까?

ASP.NET 응용 프로그램에서 최상의 사용자 경험을 얻으려면 NCache 엄청난 양의 알림을 처리하기 위해 매우 빠르고 안정적이며 확장 가능한 백플레인 역할을 합니다. 아래에 언급된 몇 가지 주요 이점은 NCache 백플레인으로 RDBM 대신.

NCache 선형 확장 가능(높은 처리량 및 낮은 대기 시간)
의 가장 중요한 특징은 NCache 백플레인은 최대 처리량 및 최소 지연 시간을 제공한다는 것입니다. 모든 메시지 처리를 메모리 내로 유지하여 대기 시간 증가 가능성을 배제함으로써 대량의 데이터를 빠르고 원활하게 처리합니다.

모든 메시지를 제 시간에 전달하려면 NCache 캐시 클러스터에서 사용 가능한 모든 서버에 로드를 분산하여 전송 중 최대 처리량을 제공할 뿐만 아니라 런타임에 더 많은 서버를 추가할 수 있습니다.

다음은 참조용으로 몇 가지 성능 벤치마크 수치입니다.

그림 6: 성능 수치 NCache

이는 애플리케이션 아키텍처 내에서 전반적인 선형 확장성을 제공하며 특히 극심한 부하에서 애플리케이션 성능이 저하되는 것에 대해 걱정할 필요가 없습니다.
NCache 매우 신뢰할 수 있습니다
의 두 번째 특징 NCache 백플레인은 최고의 신뢰성입니다. 특히 미션 크리티컬 애플리케이션의 경우 메시지 전달을 보장하려면 NCache 백플레인으로 사용할 수 있으므로 서버가 다운되거나 유지 관리를 위해 다운되어 메시지가 손실되는 것에 대해 걱정할 필요가 없습니다. 클러스터에서 사용하는 각 Cache 서버에 대한 백업을 유지합니다. SignalR backplane 서버가 다운되는 경우 자동으로 사용할 수 있게 됩니다.

극도의 신뢰성 NCache 백플레인에 연결된 모든 웹 서버에 모든 메시지를 브로드캐스트하는 특성에 기인합니다. 다른 서버에 데이터를 백업하면 미션 크리티컬 애플리케이션이 무거운 페이로드를 전송하는 동안 데이터 손실 가능성이 없습니다.
NCache 고가용성
또 다른 중요한 특징은 NCache 백플레인은 고가용성입니다. 와 함께 NCache 당신으로 설치 SignalR backplane, 메시지가 항상 활성 캐시 클러스터를 통해 전송되기 때문에 시스템의 가용성이 높아집니다.

NCache 아키텍처는 다양한 캐싱 토폴로지 중 하나를 기반으로 할 수 있는 '항상 활성 캐시 클러스터'를 통해 고가용성 기능을 보장합니다. 예를 들어 '파티션 복제' 토폴로지는 모든 서버에서 활성 파티션을 제공하며 각 서버에는 백업이 있습니다. 따라서 서버가 다운되면 클라이언트는 이를 자동으로 감지하고 남아 있는 다른 노드에 대한 연결을 장애 조치합니다.

캐시 클러스터 NCache 1대의 서버만 가동되어 작동하는 경우에도 작동할 수 있으며 이는 최소한 XNUMX% 가동 시간 시나리오에 필요한 것입니다. 이 기능은 자연 재해로 인해 서버가 타격을 받거나 유지 관리를 위해 의도적으로 서버를 중단한 경우에 유용합니다. 간단히 말해서 실용적인 캐싱 토폴로지는 NCache SignalR 기반 애플리케이션에서 100% 가동 시간을 달성하는 데 도움이 됩니다.

그림 7: 파티션-복제본 캐싱 토폴로지

NCache 보다 더 Redis?

NCache 또한 Redis 기능의 관점에서. 개발자가 직면한 모든 단점을 배제하기 위해 Redis 분산 캐시 시스템, NCache 이 세 가지 최상의 기능을 가지고 있습니다.

기본 .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 한 줄만 변경하면 아래의 단계별 자습서를 따라 응용 프로그램을 이에 맞게 설정할 수 있습니다.

NuGet 패키지 설치
를 설치하여 시작하십시오. Alachisoft.NCache.시그널R 패키지 관리자 콘솔에서 다음 명령을 실행하여 애플리케이션에 NuGet 패키지를 추가합니다.
```
Install-Package Alachisoft.NCache.SignalR
```
네임스페이스 포함
당신의 Startup.cs 파일에 아래와 같이 두 개의 네임스페이스를 포함합니다.
- Alachisoft.NCache.시그널R
- 마이크로소프트.AspNet.시그널R

Web.config 수정

Web.config 파일에서 cacheName 및 이벤트 키 FBI 증오 범죄 보고서 태그 :

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

그림 8: Web.config 변경 사항

회원가입 NCache as SignalR Backplane 귀하의 응용 프로그램에 대한

사용 인스턴스 등록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 기본적으로 모든 실시간 ASP.NET 웹 응용 프로그램에서 SignalR의 백플레인으로 사용하여 웹 응용 프로그램의 성능을 높일 수 있는 .NET 기반 메모리 내 분산 캐시입니다.

다른 사용 가능한 옵션과 차별화되는 기능에는 초고속 성능, 100% 가동 시간, 데이터 안정성, 보장된 메시지 전달 및 최소 대기 시간으로 최대 처리량을 유지하는 기능이 있습니다.