Azure SignalR Service를 위한 성능 가이드
Azure SignalR Service를 사용하는 주요 이점 중 하나는 SignalR 애플리케이션 크기 조정이 용이하다는 것입니다. 대규모 시나리오에서는 성능이 중요한 요인입니다.
이 문서에서는 다음을 설명합니다.
- SignalR 애플리케이션 성능에 영향을 미치는 요소.
- 다양한 사용 사례 시나리오의 일반적인 성능.
- 성능 보고서를 생성하는 데 사용할 수 있는 환경 및 도구.
메트릭을 사용한 빠른 평가
Azure Portal에서 서비스를 쉽게 모니터링할 수 있습니다. SignalR 인스턴스의 메트릭 페이지에서 서버 로드 메트릭을 선택하여 서비스의 "압력"을 확인할 수 있습니다.
차트는 SignalR 서비스의 컴퓨팅 압력을 보여 줍니다. 시나리오를 테스트하고 이 메트릭을 확인하여 스케일 업 여부를 결정할 수 있습니다. 서버 로드가 70% 미만이면 SignalR 서비스 내부의 대기 시간은 낮게 유지됩니다.
참고 항목
단위 50 이상을 사용 중인 동시에 시나리오가 주로 소규모 그룹(그룹 크기 <20) 또는 단일 연결로 전송되는 경우 소규모 그룹으로 보내기 또는 연결로 보내기를 참조로 확인해야 합니다. 이러한 시나리오에서는 서버 로드에 포함되지 않은 큰 라우팅 비용이 있습니다.
용어 정의
인바운드: Azure SignalR Service로 들어오는 메시지입니다.
아웃바운드: Azure SignalR Service에서 보내는 메시지입니다.
대역폭: 1초 안에 포함된 모든 메시지의 총 크기입니다.
기본 모드: Azure SignalR Service 인스턴스를 만든 때의 기본 작업 모드입니다. Azure SignalR Service는 클라이언트 연결을 수락하기 전에 앱 서버에서 연결을 설정하는 것으로 예상합니다.
서버리스 모드: Azure SignalR Service가 클라이언트 연결만 수락하는 모드입니다. 서버 연결이 허용되지 않습니다.
개요
Azure SignalR Service는 다양한 성능 용량에 대해 7개 표준 계층을 정의합니다. 이 문서에서는 다음 질문에 대한 답변을 제공합니다.
각 계층(단위)에서 일반적인 Azure SignalR Service 성능은 무엇인가요?
Azure SignalR Service가 내 메시지 처리량 요구 사항을 충족하나요(예: 초당 100,000개 메시지 전송)?
특정 시나리오의 경우 적절한 계층을 선택하려면 어떻게 해야 하나요?
내게 적합한 앱 서버(VM 크기)의 종류는 무엇인가요? 얼마나 많이 배포해야 하나요?
이러한 질문에 대답하기 위해 이 가이드에서는 먼저 성능에 영향을 주는 요소를 개략적으로 설명합니다. 그런 다음 일반적인 사용 사례 에코, 브로드캐스트, 그룹으로 보내기 및 연결에 보내기(피어 투 피어 채팅)에서 모든 계층에 대한 최대 인바운드 및 아웃바운드 메시지를 예시합니다.
이 가이드에서 모든 시나리오(및 다른 사용 사례, 메시지 크기, 메시지 전송 패턴 등)를 다룰 수 없지만, 다음과 같이 몇 가지 유용한 방법을 소개합니다.
- 인바운드 또는 아웃바운드 메시지에 대한 대략적인 요구 사항을 평가합니다.
- 성능 테이블을 확인하여 적절한 계층을 찾습니다.
성능 인사이트
이 섹션에서는 성능 평가 방법론에 대해 설명하고 성능에 영향을 주는 모든 요인을 나열합니다. 마지막에는 성능 요구 사항을 평가하는 데 도움이 되는 방법을 제공합니다.
방법
'처리량' 및 '대기 시간'은 성능 확인의 두 가지 일반적인 측면입니다. Azure SignalR Service의 경우 각 SKU 계층에는 고유한 처리량 제한 정책이 있습니다. 이 정책은 '최대 허용 처리량(인바운드 및 아웃바운드 대역폭)'을 메시지의 99%에서 대기 시간이 1초 미만일 때 달성되는 최대 처리량으로 정의합니다.
대기 시간은 연결에서 메시지를 전송하고 Azure SignalR Service로부터 응답 메시지를 수신할 때까지의 시간 범위입니다. 에코를 예로 들어 보겠습니다. 모든 클라이언트 연결은 메시지에 타임스탬프를 추가합니다. 앱 서버의 허브가 원래 메시지를 다시 클라이언트로 보냅니다. 따라서 모든 클라이언트 연결에서 전파 지연 시간을 쉽게 계산할 수 있습니다. 타임스탬프는 브로드캐스트, 그룹으로 보내기 및 연결로 보내기의 모든 메시지에 첨부됩니다.
수천 개의 동시 클라이언트 연결을 시뮬레이션하기 위해 Azure의 가상 개인 네트워크에 여러 VM이 생성됩니다. 이러한 VM은 모두 동일한 Azure SignalR Service 인스턴스에 연결됩니다.
Azure SignalR Service의 기본 모드에서 앱 서버 VM은 클라이언트 VM과 동일한 가상 사설망에 배포됩니다. 모든 클라이언트 VM 및 앱 서버 VM은 지역 간 대기 시간을 방지하기 위해 동일한 지역의 동일한 네트워크에 배포됩니다.
성능 요인
다음 요소는 SignalR 성능에 영향을 미칩니다.
- SKU 계층(CPU/메모리)
- 연결 수
- 메시지 크기
- 메시지 전송 속도
- 전송 방식(WebSocket, 서버 전송 이벤트 또는 긴 폴링)
- 사용 사례 시나리오(라우팅 비용)
- 앱 서버 및 서비스 연결(서버 모드)
컴퓨터 리소스
이론적으로 Azure SignalR Service 용량은 컴퓨팅 리소스(CPU, 메모리 및 네트워크)에 의해 제한됩니다. 예를 들어 Azure SignalR Service에 대한 연결이 많으면 서비스에서 더 많은 메모리를 사용하게 됩니다. 메시지 트래픽이 큰 경우(예: 모든 메시지가 2048바이트보다 큰 경우) Azure SignalR Service는 트래픽을 처리하기 위해 더 많은 CPU 주기를 소비해야 합니다. 또한 Azure 네트워크 대역폭에도 최대 트래픽 제한이 적용됩니다.
전송 방식
전송 방식은 성능에 영향을 주는 또 다른 요인입니다. 세 형식은 다음과 같습니다.
- WebSocket: WebSocket은 단일 TCP 연결에 대한 양방향, 전이중 통신 프로토콜입니다.
- Server-Sent-Event: Server-Sent-Event는 서버에서 클라이언트로 메시지를 누르는 단방향 프로토콜입니다.
- 롱 폴링: 롱 폴링을 사용하려면 클라이언트가 HTTP 요청을 통해 서버에서 정보를 주기적으로 폴링해야 합니다.
동일한 조건의 동일한 API일 경우 WebSocket이 최상의 성능을 가지며 서버 전송 이벤트, 긴 폴링 순으로 속도가 느립니다. Azure SignalR Service는 기본적으로 WebSocket을 권장합니다.
메시지 라우팅 비용
메시지 라우팅 비용도 성능을 제한합니다. Azure SignalR Service는 클라이언트 또는 서버 집합에서 다른 클라이언트나 서버로 메시지를 라우팅하는 메시지 라우터의 역할을 수행합니다. 다른 시나리오 또는 API에는 다른 라우팅 정책이 필요합니다.
에코의 경우 클라이언트가 자신에게 메시지를 보내고 라우팅 대상도 자신입니다. 이 패턴은 라우팅 비용이 가장 낮습니다. 그러나 브로드캐스트, 그룹으로 보내기, 연결로 보내기의 경우 Azure SignalR Service는 내부 분산 데이터 구조를 통해 대상 연결을 조회해야 합니다. 이 추가 처리에서 더 많은 CPU, 메모리 및 네트워크 대역폭을 사용합니다. 결과적으로 성능이 느려집니다.
기본 모드에서는 앱 서버가 특정 시나리오에 대해 병목 상태가 될 수도 있습니다. Azure SignalR SDK는 허브를 호출해야 하는 반면, 하트비트 신호를 통해 모든 클라이언트와 라이브 연결을 유지합니다.
서버리스 모드에서는 클라이언트가 WebSocket만큼 효율적이지 않은 HTTP post를 통해 메시지를 보냅니다.
프로토콜
또 다른 요인은 프로토콜, 즉 JSON 및 MessagePack입니다. MessagePack은 크기가 작고 JSON보다 빠르게 전달됩니다. 그러나 MessagePack은 성능을 향상시키지 못할 수 있습니다. Azure SignalR Service는 클라이언트와 서버 간에 메시지를 전달하는 동안 메시지 페이로드를 디코딩하지 않으므로 성능이 프로토콜에 민감하지 않습니다.
적절한 SKU 찾기
인바운드/아웃바운드 용량을 평가하거나 특정 사용 사례에 적합한 계층을 찾을 수 있는 방법은 무엇인가요?
앱 서버가 강력하고 성능 병목 상태가 아닌 것으로 가정합니다. 그러면 모든 계층에 대한 최대 인바운드 및 아웃바운드 대역폭을 확인합니다.
빠른 평가
빠른 평가를 위해 다음 기본 설정을 가정합니다.
- 전송 방식은 WebSocket입니다.
- 메시지 크기는 2048바이트입니다.
- 메시지는 1초마다 전송됩니다.
- Azure SignalR Service는 기본 모드입니다.
모든 계층에는 고유한 최대 인바운드 대역폭 및 아웃바운드 대역폭이 있습니다. 인바운드 또는 아웃바운드 연결이 제한을 초과하는 경우에는 원활한 사용자 환경이 보장되지 않습니다.
에코는 라우팅 비용이 가장 낮기 때문에 최대 인바운드 대역폭을 제공합니다. 브로드캐스트는 최대 아웃바운드 메시지 대역폭을 정의합니다.
다음 두 표에 강조 표시된 값을 초과하면 안 됩니다.
| 에코 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 인바운드 대역폭 | 2MBps | 4MBps | 20MBps | 100MBps | 200MBps | 400MBps | 1,000MBps | 2,000MBps |
| 아웃바운드 대역폭 | 2MBps | 4MBps | 20Mbps | 100MBps | 200MBps | 400MBps | 1,000MBps | 2,000MBps |
| 브로드캐스트 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 인바운드 대역폭 | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps |
| 아웃바운드 대역폭 | 4MBps | 8MBps | 40MBps | 200MBps | 400MBps | 800MBps | 2,000MBps | 4,000MBps |
'인바운드 대역폭' 및 '아웃바운드 대역폭'은 초당 총 메시지 크기입니다. 다음은 해당 수식입니다.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
inboundConnections: 메시지를 전송하는 연결의 수입니다.
outboundConnections: 메시지를 수신하는 연결의 수입니다.
messageSize: 단일 메시지의 크기입니다(평균 값). 1024바이트 미만의 작은 메시지는 1024바이트 메시지와 유사한 성능 영향을 미칩니다.
sendInterval: 메시지 1개를 전송하는 시간입니다. 일반적으로 메시지당 1초입니다. 즉, 1초마다 하나의 메시지를 보냅니다. 간격이 줄어들면 일정 기간 동안 더 많은 메시지를 전송하는 것을 의미합니다. 예를 들어 메시지당 0.5초는 매초 2개의 메시지를 전송하는 것을 의미합니다.
Connections: 모든 계층에 대한 Azure SignalR Service의 커밋된 최대 임계값입니다. 연결 수를 더 늘리면 연결 제한이 발생합니다.
참고 항목
단위 크기를 100보다 크게 유지하려면 SKU Premium_P2까지 스케일 업해야 합니다.
복잡한 사용 사례에 대한 평가
더 큰 메시지 크기 또는 다른 전송 속도
실제 사용 사례는 더 복잡합니다. 2048바이트 보다 큰 메시지를 전송할 수도 있고 메시지 전송 속도가 초당 하나가 아닐 수 있습니다. 성능을 평가하는 방법을 찾기 위해 단위 100의 브로드캐스트를 예로 들어 보겠습니다.
다음 표에서는 브로드캐스트의 실제 사용 사례를 보여 줍니다. 그러나 메시지 크기, 연결 수 및 메시지 전송 속도는 이전 섹션에서 가정한 것과 다릅니다. 문제는 이러한 항목(메시지 크기, 연결 수 또는 메시지 전송 속도) 중 두 개만 알고 있는 경우 어떻게 다른 항목을 추론할 수 있는가입니다.
| 브로드캐스트 | 메시지 크기 | 동시 인바운드 메시지 | 연결 | 전송 간격 |
|---|---|---|---|---|
| 1 | 20KB | 1 | 100,000 | 5초 |
| 2 | 256 KB | 1 | 8,000 | 5초 |
다음 수식은 이전 수식을 기반으로 쉽게 유추할 수 있습니다.
outboundConnections = outboundBandwidth * sendInterval / messageSize
단위 100의 경우 최대 아웃바운드 대역폭은 이전 표의 400MB입니다. 20KB 메시지 크기의 경우 최대 아웃바운드 연결은 400MB * 5 / 20KB = 100,000으로, 실제 값과 일치합니다.
혼합 사용 사례
실제 사용 사례에서는 일반적으로 네 가지 기본 사용 사례, 즉 에코, 브로드캐스트, 그룹에 보내기, 연결에 보내기가 혼합됩니다. 용량을 평가하는 데 사용하는 방법은 다음과 같습니다.
- 혼합 사용 사례를 네 가지 기본 사용 사례로 분리합니다.
- 위의 수식을 따로 사용하여 최대 인바운드 및 아웃바운드 메시지 대역폭을 계산합니다.
- 총 인바운드/아웃바운드 대역폭을 확보하기 위해 대역폭 계산 결과를 더합니다.
그런 다음 최대 인바운드/아웃바운드 대역폭 표에서 적절한 계층을 선택합니다.
참고 항목
수백 또는 수천 개의 작은 그룹으로 메시지를 전송하는 경우 또는 수천 개의 클라이언트에서 서로 메시지를 전송하는 경우 라우팅 비용이 가장 큰 부분을 차지합니다. 이 영향을 고려해야 합니다.
클라이언트에 메시지를 전송하는 사용 사례의 경우 앱 서버에 병목 상태가 발생하지 않도록 해야 합니다. 다음 '사례 연구' 섹션에서는 필요한 앱 서버 수와 구성해야 하는 서버 연결 수에 대한 지침을 제공합니다.
사례 연구
다음 섹션에서는 WebSocket 전송에서 일반적인 몇 가지 사용 사례(에코, 브로드캐스트, 그룹에 보내기 및 연결로 보내기)에 대해 설명합니다. 각 시나리오에 대해, Azure SignalR Service의 현재 인바운드 및 아웃바운드 용량이 나열됩니다. 또한 성능에 영향을 주는 주요 요인에 대해 설명합니다.
기본 모드에서 앱 서버는 Azure SignalR Service를 사용하여 5개 서버 연결을 만듭니다. 앱 서버는 기본적으로 Azure SignalR Service SDK를 사용합니다. 다음 성능 테스트 결과에서 서버 연결은 15개로 증가합니다(대규모 그룹에 메시지를 브로드캐스트하고 전송하는 경우 더 많이 증가).
사용 사례 마다 앱 서버에 대한 요구 사항이 다릅니다. 브로드캐스트에는 적은 수의 앱 서버가 필요합니다. 에코 또는 연결로 보내기에는 많은 앱 서버가 필요합니다.
모든 사용 사례에서 기본 메시지 크기는 2048바이트이고 메시지 전송 간격은 1초입니다.
기본 모드
기본 모드에는 클라이언트, 웹앱 서버 및 Azure SignalR Service가 관련됩니다. 모든 클라이언트는 단일 연결을 나타냅니다.
에코
첫째, 웹앱이 Azure SignalR Service에 연결합니다. 둘째, 많은 클라이언트가 웹앱에 연결되고, 웹앱이 액세스 토큰 및 엔드포인트를 사용하여 클라이언트를 Azure SignalR Service로 리디렉션합니다. 그런 다음 클라이언트가 Azure SignalR Service와 WebSocket 연결을 설정합니다.
모든 클라이언트는 연결을 설정한 후 1초마다 특정 허브에 타임스탬프가 포함된 메시지를 전송하기 시작합니다. 허브는 메시지를 원래 클라이언트로 다시 에코합니다. 모든 클라이언트는 에코 메시지를 다시 수신할 때 대기 시간을 계산합니다.
다음 다이어그램에서 5 ~ 8(빨간색으로 강조 표시된 트래픽)이 단일 루프입니다. 루프는 기본 기간(5분) 동안 실행되고 모든 메시지 대기 시간에 대한 통계를 가져옵니다.
에코 동작은 최대 인바운드 대역폭이 최대 아웃바운드 대역폭과 같음을 결정합니다. 자세한 내용은 다음 표를 참조하세요.
| 에코 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 초당 인바운드/아웃바운드 메시지 수 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 인바운드/아웃바운드 대역폭 | 2MBps | 4MBps | 20Mbps | 100MBps | 200MBps | 400MBps | 1,000MBps | 2,000MBps |
이 사용 사례에서 모든 클라이언트는 앱 서버에 정의된 허브를 호출합니다. 허브는 원래 클라이언트 쪽에 정의된 메서드만 호출합니다. 이 허브는 에코를 위한 가장 경량 허브입니다.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
이 간단한 허브의 경우에도 에코 인바운드 메시지 부하가 증가하면 애플리케이션 서버에 대한 트래픽 압력이 두드러집니다. 이러한 트래픽 압력에는 대용량 SKU 계층에 많은 앱 서버가 필요합니다. 다음 표에서는 모든 계층에 대한 앱 서버 수를 나열합니다.
| 에코 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 앱 서버 수 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
참고 항목
앱 서버의 클라이언트 연결 수, 메시지 크기, 메시지 전송 속도, SKU 계층 및 CPU/메모리는 에코의 전반적인 성능에 영향을 줍니다.
브로드캐스트
브로드캐스트의 경우 웹앱은 메시지를 수신하면 모든 클라이언트로 브로드캐스트합니다. 브로드캐스트할 클라이언트가 많을수록 모든 클라이언트에 대한 추가 메시지 트래픽이 발생합니다. 다음 다이어그램을 참조하세요.
적은 수의 클라이언트가 브로드캐스트하는 중입니다. 인바운드 메시지 대역폭은 작지만 아웃바운드 대역폭은 큽니다. 클라이언트 연결 수 또는 브로드캐스트 속도가 증가하면 아웃바운드 메시지 대역폭도 증가합니다.
다음 표에는 최대 클라이언트 연결 수, 인바운드/아웃바운드 메시지 수 및 대역폭이 요약되어 있습니다.
| 브로드캐스트 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 초당 인바운드 메시지 수 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 초당 아웃바운드 메시지 수 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| 인바운드 대역폭 | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps |
| 아웃바운드 대역폭 | 4MBps | 8MBps | 40MBps | 200MBps | 400MBps | 800MBps | 2,000MBps | 4,000MBps |
메시지를 게시하는 브로드캐스팅 클라이언트는 4개 이하입니다. 인바운드 메시지 양이 적기 때문에 에코 와 비교할 때 필요한 앱 서버가 더 적습니다. 두 개의 앱 서버로도 SLA 및 성능 고려 사항에 충분합니다. 그러나 50보다 큰 단위의 경우에는 불균형을 방지하기 위해 기본 서버 연결을 늘려야 합니다.
| 브로드캐스트 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 앱 서버 수 | 1 | 1 | 6 | 2 | 2 | 4 | 10 | 20 |
참고 항목
Azure SignalR Service에 대한 서버 연결의 불균형을 방지하기 위해 모든 앱 서버에서 기본 서버 연결 수를 5에서 40으로 늘립니다.
클라이언트 연결 수, 메시지 크기, 메시지 전송 속도 및 SKU 계층은 브로드캐스트의 전반적인 성능에 영향을 줍니다.
그룹으로 보내기
그룹으로 보내기 사용 사례에는 브로드캐스트와 비슷한 트래픽 패턴이 있습니다. 차이점은 클라이언트가 Azure SignalR Service를 사용하여 WebSocket 연결을 설정한 후에 그룹을 조인해야 특정 그룹에 메시지를 보낼 수 있다는 것입니다. 아래 다이어그램은 트래픽 흐름을 보여줍니다.
그룹 멤버 및 그룹 수는 성능에 영향을 주는 두 가지 요인입니다. 분석을 간소화하기 위해 다음과 같이 두 종류의 그룹을 정의합니다.
소규모 그룹: 모든 그룹에는 10개의 연결이 있습니다. 그룹 번호는 (최대 연결 수)/10과 같습니다. 예를 들어 단위 1의 경우 연결 수가 1,000이면 그룹이 1000/10 = 100개 있습니다.
대규모 그룹: 그룹 번호는 항상 10입니다. 그룹 멤버 수는 (최대 연결 수)/10과 같습니다. 예를 들어 단위 1의 경우 연결 수가 1,000이면 모든 그룹에 멤버가 1000/10 = 100명 있습니다.
그룹으로 보내기는 분산 데이터 구조를 통해 대상 연결을 찾아야 하므로 Azure SignalR Service에 대한 라우팅 비용이 발생합니다. 전송 연결이 늘어나면 비용이 증가합니다.
소규모 그룹
라우팅 비용은 여러 소규모 그룹으로 메시지를 보낼 때 상당합니다. 현재 Azure SignalR Service 구현은 단위 50에서 라우팅 비용 제한에 도달합니다. CPU와 메모리를 더 추가하는 것은 도움이 되지 않으므로 설계상 단위 100이 더 이상 향상시킬 수 없습니다. 더 많은 인바운드 대역폭이 필요하면 고객 지원팀에 문의하세요.
| 소규모 그룹으로 보내기 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 그룹 멤버 수 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 그룹 수 | 100 | 200 | 1,000 | 5,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| 초당 인바운드 메시지 수 | 200 | 400 | 2,000 | 10,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| 인바운드 대역폭 | 400KBps | 800KBps | 4MBps | 20Mbps | 20Mbps | 40MBps | 100MBps | 200MBps |
| 초당 아웃바운드 메시지 수 | 2,000 | 4,000 | 20,000 | 100,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 아웃바운드 대역폭 | 4MBps | 8MBps | 40MBps | 200MBps | 200MBps | 400MBps | 1,000MBps | 2,000MBps |
많은 클라이언트 연결에서 허브를 호출하므로 앱 서버 수도 성능에 매우 중요합니다. 다음 표에는 제안된 앱 서버 수가 나와 있습니다.
| 소규모 그룹으로 보내기 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 앱 서버 수 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
참고 항목
앱 서버의 클라이언트 연결 수, 메시지 크기, 메시지 전송 속도, 라우팅 비용, SKU 계층 및 CPU/메모리는 소규모 그룹으로 보내기의 전반적인 성능에 영향을 줍니다.
표에 나열된 그룹 수, 그룹 멤버 수는 하드 제한이 아닙니다. 이러한 매개 변수 값은 안정적인 벤치마크 시나리오를 설정하기 위해 선택됩니다. 예를 들어 각 연결을 고유 그룹에 할당해도 됩니다. 이 구성에서 성능은 연결로 보내기의 경우와 가깝습니다.
대규모 그룹
대규모 그룹으로 보내기의 경우 라우팅 비용 제한에 도달하기 전에 아웃바운드 대역폭이 병목 상태가 됩니다. 다음 표에서는 브로드캐스트와 거의 동일한 최대 아웃바운드 대역폭을 나열합니다.
| 대규모 그룹으로 보내기 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 그룹 멤버 수 | 100 | 200 | 500 | 1,000 | 2,000 | 5,000 | 10,000 | 20,000 |
| 그룹 수 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 초당 인바운드 메시지 수 | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| 인바운드 대역폭 | 40KBps | 40KBps | 40KBps | 40KBps | 40KBps | 40KBps | 40KBps | 40KBps |
| 초당 아웃바운드 메시지 수 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| 아웃바운드 대역폭 | 4MBps | 8MBps | 40MBps | 200MBps | 400MBps | 800MBps | 2,000MBps | 4,000MBps |
전송 연결 수가 40을 초과하지 않습니다. 앱 서버의 부담이 작으므로 적은 수의 웹앱이 제안됩니다.
| 대규모 그룹으로 보내기 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 앱 서버 수 | 1 | 6 | 2 | 2 | 2 | 4 | 10 | 20 |
참고 항목
Azure SignalR Service에 대한 서버 연결의 불균형을 방지하기 위해 모든 앱 서버에서 기본 서버 연결 수를 5에서 40으로 늘립니다.
클라이언트 연결 수, 메시지 크기, 메시지 전송 속도, 라우팅 비용 및 SKU 계층은 대규모 그룹으로 보내기의 전반적인 성능에 영향을 줍니다.
연결로 보내기
연결로 보내기 사용 사례에서는 클라이언트가 Azure SignalR Service에 대한 연결을 설정할 때 모든 클라이언트가 특별한 허브를 호출하여 고유한 연결 ID를 가져옵니다. 성능 벤치마크는 모든 연결 ID를 수집하고 뒤섞은 다음 전송 대상으로 모든 클라이언트에 다시 할당합니다. 클라이언트는 성능 테스트가 완료될 때까지 대상 연결에 계속 메시지를 전송합니다.
연결로 보내기에 대한 라우팅 비용은 소규모 그룹으로 보내기의 비용과 비슷합니다.
연결 수가 늘어나면 라우팅 비용은 전반적인 성능을 제한하는 중요한 요소가 됩니다. 특히 단위 20은 서비스에서 라우팅 병목 현상이 발생하는 임계값을 표시합니다. 단위 수가 좀 더 증가해도 라우팅 기능을 향상시키는 Premium_P2(단위 >=100)로 전환하지 않으면 성능이 향상되지 않습니다.
다음 표는 연결로 보내기 벤치마크를 여러 번 실행한 통계의 요약입니다.
| 연결로 보내기 | 단위 1 | 단위 2 | 단위 20 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 20,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 초당 인바운드/아웃바운드 메시지 수 | 1,000 | 2,000 | 20,000 | 20,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| 인바운드/아웃바운드 대역폭 | 2MBps | 4MBps | 40MBps | 40MBps | 40MBps | 80MBps | 200MBps | 400MBps |
참고 항목
단위 20 이후 초당 인바운드/아웃바운드 메시지가 정체되더라도 더 많은 연결에 대한 용량은 계속 증가합니다. 실제 비즈니스 시나리오에서는 병목 상태를 야기하는 요인이 동시 메시지 전송 활동이 아니라 연결 수인 경우가 많습니다. 모든 연결이 벤치마크 테스트와 같이 높은 빈도로 메시지를 적극적으로 보내는 것은 드문 일입니다.
이 사용 사례에는 앱 서버 쪽에 높은 부하가 필요합니다. 다음 표에서 제안된 앱 서버 수를 참조하세요.
| 연결로 보내기 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 앱 서버 수 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
참고 항목
앱 서버의 클라이언트 연결 수, 메시지 크기, 메시지 전송 속도, 라우팅 비용, SKU 계층 및 CPU/메모리는 연결로 보내기의 전반적인 성능에 영향을 줍니다.
ASP.NET SignalR
Azure SignalR Service는 ASP.NET SignalR에 대해 동일한 성능 용량을 제공합니다.
서버리스 모드
서버리스 모드에는 클라이언트와 Azure SignalR Service가 관련됩니다. 모든 클라이언트는 단일 연결을 나타냅니다. 클라이언트는 REST API를 통해 메시지를 다른 클라이언트에 전송하거나 모든 클라이언트에 브로드캐스트합니다.
REST API를 통해 고밀도 메시지를 보내는 것은 WebSocket을 사용하는 것만큼 효율적이지 않습니다. 이렇게 하려면 매번 새 HTTP 연결을 작성해야 하며, 이는 서버리스 모드에서 추가 비용입니다.
REST API를 통해 브로드캐스트
모든 클라이언트는 Azure SignalR Service와 WebSocket 연결을 설정합니다. 그런 다음 일부 클라이언트는 REST API를 통해 브로드캐스팅을 시작합니다. 메시지 전송(인바운드)은 모두 HTTP Post를 통하지만, WebSocket에 비해 효율적이지 않습니다.
| REST API를 통해 브로드캐스트 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 초당 인바운드 메시지 수 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 초당 아웃바운드 메시지 수 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| 인바운드 대역폭 | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps | 4KBps |
| 아웃바운드 대역폭 | 4MBps | 8MBps | 40MBps | 200MBps | 400MBps | 800MBps | 2,000MBps | 4,000MBps |
REST API를 통해 사용자에게 보내기
벤치마크는 Azure SignalR Service에 대한 연결을 시작하기 전에 모든 클라이언트에 사용자 이름을 할당합니다. 클라이언트는 Azure SignalR Service와 WebSocket 연결을 설정하면 HTTP Post를 통해 다른 사용자에게 메시지를 보내기 시작합니다.
| REST API를 통해 사용자에게 보내기 | 단위 1 | 단위 2 | 단위 10 | 단위 50 | 단위 100 | 단위 200 | 단위 500 | 단위 1000 |
|---|---|---|---|---|---|---|---|---|
| 연결 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 초당 인바운드/아웃바운드 메시지 수 | 200 | 400 | 2,000 | 10,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| 인바운드/아웃바운드 대역폭 | 400KBps | 800KBps | 4MBps | 20Mbps | 40MBps | 80MBps | 200MBps | 400MBps |
성능 테스트 환경
위에서 나열한 모든 사용 사례에 대해 Azure 환경에서 성능 테스트를 수행했습니다. 최대 200개 클라이언트 VM 및 100개 앱 서버 VM이 사용되었습니다. 다음은 몇 가지 세부 정보입니다.
클라이언트 VM 크기: StandardDS2V2(2개 vCPU, 7G 메모리)
앱 서버 VM 크기: StandardF4sV2(4개 vCPU, 8G 메모리)
Azure SignalR SDK 서버 연결 수: 15
성능 도구
Azure SignalR Service용 성능 도구는 GitHub에서 찾을 수 있습니다.
다음 단계
이 문서에서는 일반적인 사용 사례 시나리오에서 Azure SignalR Service 성능을 개략적으로 파악했습니다.
서비스 내부 구조 및 확장성에 대한 자세한 내용은 다음 가이드를 참조하세요.