Azure SignalR Service가 프로덕션에 사용할 준비가 되었나요?
예, ASP.NET Core SignalR 및 ASP.NET SignalR에 대한 지원은 모두 일반 공급됩니다.
애플리케이션 서버가 여러 개 있으면 클라이언트 메시지가 모든 서버에 전송되나요? 아니면 그 중 하나에만 전송되나요?
클라이언트와 애플리케이션 서버 간의 일대일 매핑이 있습니다. 한 클라이언트에서 보낸 메시지는 항상 동일한 애플리케이션 서버로 전송됩니다.
매핑은 클라이언트나 애플리케이션 서버 연결이 끊어질 때까지 유지됩니다.
애플리케이션 서버 중 하나가 다운되는 경우, 어떤 서버인지 어떻게 알아내고 알림을 받을 수 있나요?
Azure SignalR Service는 애플리케이션 서버의 하트비트를 모니터링합니다. 지정된 기간 동안 하트비트를 수신하지 못하면 해당 애플리케이션 서버는 오프라인으로 간주됩니다. 이 애플리케이션 서버에 매핑된 모든 클라이언트 연결이 끊어집니다.
ASP.NET Core SignalR SDK에서 Azure SignalR Service SDK로 전환할 때 내 사용자 지정 `IUserIdProvider`에서 예외가 발생하는 이유는 무엇인가요?
IUserIdProvider가 호출되는 경우 ASP.NET Core SignalR SDK와 Azure SignalR Service SDK의 매개 변수 HubConnectionContext context가 다릅니다.
ASP.NET Core SignalR에서 HubConnectionContext context는 모든 속성에 대해 유효한 값이 있는 실제 클라이언트 연결의 컨텍스트입니다.
Azure SignalR Service SDK에서 HubConnectionContext context는 논리적 클라이언트 연결의 컨텍스트입니다. 실제 클라이언트는 Azure SignalR Service 인스턴스에 연결되기 때문에 제한된 수의 속성만 제공됩니다.
지금은 HubConnectionContext.GetHttpContext()와 HubConnectionContext.User만 액세스에 사용할 수 있습니다.
소스 코드를 확인할 수 있습니다.
Azure SignalR Service에서 사용할 수 있는 전송을 ASP.NET Core SignalR로 서버 쪽에서 구성할 수 있나요? 예를 들어 WebSocket 전송을 사용하지 않도록 설정할 수 있나요?
예. 구성 방법은 전송 구성을 참조하세요.
또한 ASP.NET Core SignalR 구성에 설명된 대로 클라이언트 쪽 전송을 구성할 수 있습니다.
Azure Portal에 표시된 메시지 수 또는 연결 수와 같은 메트릭의 의미는 무엇인가요? 어떤 종류의 집계 유형을 선택해야 하나요?
Azure SignalR Service의 메시지 및 연결에서 이러한 메트릭 계산에 대한 세부 정보를 찾을 수 있습니다.
Azure SignalR Service 리소스의 개요 창에서 적절한 집계 유형을 이미 선택했습니다. Azure Monitor에서 지원되는 메트릭을 참조로 사용할 수 있습니다.
'기본', '서버리스' 및 '클래식' 서비스 모드의 의미는 무엇인가요? 어떻게 선택할 수 있나요?
새 애플리케이션의 경우에는 기본 및 서버리스 모드만 사용해야 합니다. 주요 차이점은 서비스에 대한 서버 연결을 설정하는 애플리케이션 서버가 있는지 여부(예: AddAzureSignalR()을 사용하여 서비스에 연결)를 사용하는 것입니다. 예인 경우 기본 모드를 사용하고 그렇지 않으면 서버리스 모드를 사용합니다.
클래식 모드는 기존 애플리케이션에 대해 이전 버전과의 호환성을 위해 설계되었으므로 새 애플리케이션에 사용하면 안 됩니다.
서비스 모드에 대한 자세한 내용은 Azure SignalR Service의 서비스 모드를 참조하세요.
서버리스 모드로 클라이언트에서 메시지를 보낼 수 있나요?
SignalR 인스턴스에서 업스트림 엔드포인트를 구성하는 경우 클라이언트에서 메시지를 보낼 수 있습니다. 업스트림 엔드포인트는 SignalR 서비스에서 메시지 및 연결 이벤트를 받을 수 있는 엔드포인트 세트입니다. 업스트림 엔드포인트가 구성되지 않은 경우 클라이언트의 메시지가 무시됩니다.
자세한 내용은 업스트림 엔드포인트를 참조하세요.
업스트림 엔드포인트 기능은 현재 퍼블릭 미리 보기로 제공됩니다.
ASP.NET SignalR과 함께 Azure SignalR Service를 사용하는 경우 기능 차이점이 있나요?
Azure SignalR Service를 사용하는 경우 ASP.NET SignalR의 일부 API 및 기능이 지원되지 않습니다.
- 클라이언트와 허브 간의 임의 상태를 전달하는 기능(종종
HubState라고 함)은 지원되지 않습니다. PersistentConnection클래스는 지원되지 않습니다.- Forever Frame 전송은 지원되지 않습니다.
- 클라이언트가 오프라인인 경우 Azure SignalR Service가 클라이언트로 전송된 메시지를 더 이상 재생하지 않습니다.
- Azure SignalR Service를 사용하는 경우 한 클라이언트 연결에 대한 트래픽은 항상 연결 기간 동안 하나의 앱 서버 인스턴스로 라우팅됩니다(고정이라고도 함).
ASP.NET SignalR에 대한 지원은 호환성에 중점을 두므로 ASP.NET Core SignalR의 모든 새로운 기능이 지원되지 않습니다. 예를 들어 MessagePack 및 Streaming은 ASP.NET Core SignalR 애플리케이션에만 사용할 수 있습니다.
서로 다른 서비스 모드(Classic, Default 및 Serverless)에 대해 Azure SignalR Service를 구성할 수 있습니다. ASP.NET에는 Serverless 모드가 지원되지 않습니다. 데이터 평면 REST API도 지원되지 않습니다.
데이터가 어디에 상주하나요?
Azure SignalR Service는 고객 데이터를 저장하지 않습니다. Azure SignalR Service를 진단용 Azure Storage와 같은 다른 Azure 서비스와 함께 사용하는 경우 Azure 지역에서 데이터 보존을 유지하는 방법에 대한 지침은 Azure 개인 정보 보호 개요(백서)를 참조하세요.
Azure SignalR Service와 Azure Web PubSub 서비스 중에서 선택하려면 어떻게 해야 하나요?
Azure SignalR Service 및 Azure Web PubSub 서비스는 고객이 대규모 및 고가용성으로 실시간 웹 애플리케이션을 쉽게 빌드하고, 메시징 인프라를 관리하는 대신 비즈니스 논리에 집중할 수 있도록 도와줍니다. 일반적으로 SignalR 라이브러리를 사용하여 실시간 애플리케이션을 빌드하는 경우 Azure SignalR Service를 선택할 수 있습니다. 대신 WebSocket 및 게시-구독 패턴을 기준으로 실시간 애플리케이션을 빌드하는 일반 솔루션을 찾는 경우 Azure Web PubSub 서비스를 선택할 수 있습니다. Azure Web PubSub 서비스는 Azure SignalR Service를 바꾸지 않으며 그 반대도 마찬가지입니다. 다른 시나리오를 대상으로 합니다. 다음 지침은 시나리오에 사용할 서비스를 결정하는 데 도움이 됩니다.
다음과 같은 경우 Azure SignalR Service가 더 적합합니다.
- 이미 ASP.NET 또는 ASP.NET Core SignalR을 사용하고 있으며, 주로 .NET을 사용하거나 .NET 에코시스템(예: Blazor)과 통합해야 합니다.
- 플랫폼에 사용할 수 있는 SignalR 클라이언트가 있습니다.
- 다음과 같은 다양한 항목을 지원하는 프로토콜이 필요합니다.
- 호출 패턴(RPC 및 스트리밍)
- 전송(WebSocket, 서버 전송 이벤트, 긴 폴링)
- 사용자를 대신하여 연결 수명을 관리하는 클라이언트가 필요합니다.
다음과 같은 상황에서는 Azure Web PubSub 서비스가 더 적합합니다.
- WebSocket 기술을 기준으로 실시간 애플리케이션을 빌드하거나 WebSocket을 통해 게시-구독해야 합니다.
- 사용자 고유의 하위 프로토콜을 빌드하거나 WebSocket을 통해 기존 고급 프로토콜(예: MQTT, WebSocket을 통한 AMQP)을 사용하려고 합니다.
- 예를 들어, 구성된 백 엔드를 거치지 않고 클라이언트에 메시지를 보내는 경량 서버를 찾고 있습니다.