다음을 통해 공유


Azure SignalR Service를 사용하여 ASP.NET Core SignalR 애플리케이션 크기 조정

SignalR 앱 개발

SignalR은 현재 웹 애플리케이션에서 사용할 수 있는 두 가지 버전으로 제공됩니다.

  • ASP.NET SignalR
  • 새 ASP.NET Core SignalR

ASP.NET Core SignalR은 이전 버전을 다시 생성한 것입니다. 결과적으로 ASP.NET Core SignalR은 이전 버전의 SignalR과 호환되지 않습니다. API와 동작이 서로 다릅니다. Azure SignalR Service는 두 버전을 모두 지원합니다.

Azure SignalR Service를 사용하면 여러 플랫폼(Windows, Linux 및 macOS)의 Azure App Service, IIS, Nginx, Apache, Docker에서 실제 웹 애플리케이션을 호스트할 수 있습니다. 사용자 자신의 프로세스에 자체 호스팅을 사용할 수도 있습니다.

애플리케이션의 목표에 다음이 포함된 경우 Azure SignalR Service를 선택하는 것이 가장 좋습니다.

  • 실시간 콘텐츠 업데이트로 웹 클라이언트를 업데이트하기 위한 최신 기능 지원
  • 여러 플랫폼(Azure, Windows, Linux 및 macOS)에서 실행
  • 다양한 환경에서 호스팅

SignalR을 직접 배포하지 않는 이유는?

SignalR을 백 엔드 구성 요소로 지원하는 자신만의 Azure 웹 애플리케이션을 전체 웹 애플리케이션에 배포하는 방법은 여전히 유효합니다.

Azure SignalR Service를 사용하는 주요 이유 중 하나는 단순성입니다. Azure SignalR Service를 사용하면 성능, 확장성, 가용성과 같은 문제를 처리할 필요가 없습니다. 이러한 문제는 99.9% 서비스 수준 계약으로 처리됩니다.

또한 WebSocket은 일반적으로 실시간 콘텐츠 업데이트를 지원하는 데 선호되는 기술입니다. 그러나 많은 수의 WebSocket 영구 연결을 부하 분산하는 것은 크기 조정 시 해결해야 하는 복잡한 문제가 됩니다. 일반적인 해결 방법으로 DNS 부하 분산, 하드웨어 부하 분산 장치 및 소프트웨어 부하 분산을 사용합니다. Azure SignalR Service는 이 문제를 처리합니다.

ASP.NET Core SignalR의 경우 또 다른 이유로, 실제로 웹 애플리케이션을 호스팅할 필요가 없습니다. 웹 애플리케이션의 논리에서는 서버리스 컴퓨팅을 사용할 수 있습니다. 예를 들어 코드는 Azure Functions 트리거를 통해 호스팅되고 요청 시에만 실행될 것입니다. 코드가 요청 시에만 실행되고 클라이언트와의 긴 연결을 유지하지 않기 때문에 이 시나리오는 까다로울 수 있습니다. Azure SignalR Service는 이미 사용자를 위해 연결을 관리하므로 이러한 상황을 처리할 수 있습니다. 자세한 내용은 Azure Functions와 함께 SignalR Service를 사용하는 방법에 대한 개요를 참조하세요. ASP.NET SignalR은 다른 프로토콜을 사용하므로 이러한 서버리스 모드는 ASP.NET SignalR에 대해 지원되지 않습니다.

크기 조정은 어떻게 합니까?

일반적으로 SQL Server, Azure Service Bus 또는 Azure Cache for Redis를 사용하여 SignalR을 스케일링합니다. Azure SignalR Service는 크기 조정 방식을 처리합니다. 성능과 비용은 이러한 다른 서비스를 복잡하게 처리할 필요 없이 이러한 방식과 비슷합니다. 서비스에 대한 단위 수를 업데이트하면 됩니다. 각 장치마다 최대 1000개의 클라이언트 연결을 지원합니다.

다음 단계