Azure Web PubSub 서비스에 대한 성능 가이드
Azure Web PubSub Service 사용의 주요 이점 중 하나는 크기 조정이 쉽다는 것입니다. 대규모 시나리오에서는 성능이 중요한 요인입니다.
이 가이드에서는 Web PubSub 서비스 성능에 영향을 미치는 요소를 소개합니다. 다양한 사용 사례 시나리오에서 일반적인 성능을 설명합니다.
메트릭을 사용한 빠른 평가
성능에 영향을 주는 요인을 진행하기 전에 먼저 서비스의 압력을 모니터링하는 쉬운 방법을 소개해 보겠습니다. 포털에는 서버 로드라는 메트릭이 있습니다.
Azure Web PubSub 서비스의 컴퓨팅 압력을 보여 줍니다. 사용자 고유의 시나리오에서 테스트하고 이 메트릭을 확인하여 스케일 업 여부를 결정할 수 있습니다. 서버 로드가 70% 미만인 경우 Azure Web PubSub 서비스 내 대기 시간은 낮게 유지됩니다.
참고 항목
50 단위 이상을 사용 중인 동시에 시나리오가 주로 소규모 그룹(그룹 크기 <20)으로 전송되는 경우 소규모 그룹으로 보내기를 참조로 확인해야 합니다. 이러한 시나리오에서는 서버 로드에 포함되지 않은 큰 라우팅 비용이 있습니다.
다음은 성능을 평가하기 위한 자세한 개념입니다.
용어 정의
인바운드: Azure Web PubSub 서비스로 들어오는 메시지입니다.
아웃바운드: Azure Web PubSub 서비스에서 내보내는 메시지입니다.
대역폭: 1초 안에 포함된 모든 메시지의 총 크기입니다.
개요
이 문서에서는 다음 질문에 대한 답변을 제공합니다.
각 단위 크기에 대한 일반적인 Azure Web PubSub 서비스 성능은 어떠한가요?
Azure Web PubSub 서비스가 내 메시지 처리량 요구 사항을 충족하나요(예: 초당 100,000개 메시지 전송)?
특정 시나리오의 경우 적절한 단위 크기를 어떻게 선택할 수 있나요?
이러한 질문에 대답하기 위해 이 가이드에서는 먼저 성능에 영향을 주는 요소를 개략적으로 설명합니다. 그런 다음 일반적인 사용 사례(Web PubSub 하위 프로토콜, 업스트리밍 및 REST API를 통해 그룹에 보내기)에 대한 최대 인바운드 및 아웃바운드 메시지를 보여 줍니다.
이 가이드에서 모든 시나리오(및 다른 사용 사례, 메시지 크기, 메시지 전송 패턴 등)를 다룰 수 없지만, 그러나 성능 제한을 이해하기 위한 몇 가지 기본 정보를 제공합니다.
성능 인사이트
이 섹션에서는 성능 평가 방법론에 대해 설명하고 성능에 영향을 주는 모든 요인을 나열합니다. 마지막에는 성능 요구 사항을 평가하는 데 도움이 되는 방법을 제공합니다.
방법
'처리량' 및 '대기 시간'은 성능 확인의 두 가지 일반적인 측면입니다. 최대 처리량(수신 및 발신 대역폭)은 메시지의 99%가 1초 미만의 대기 시간을 가질 때 달성되는 최대 처리량으로 정의됩니다. 이는 엄격한 제한이 아닙니다.
성능 요인
이론적으로 Azure Web PubSub 서비스 용량은 계산 리소스, 즉 CPU, 메모리 및 네트워크에 의해 제한됩니다. 예를 들어 Azure Web PubSub 서비스에 대한 연결이 많으면 서비스에서 더 많은 메모리를 사용하게 됩니다. 메시지 트래픽이 큰 경우(예: 모든 메시지가 2048바이트보다 큰 경우) Azure Web PubSub 서비스는 트래픽을 처리하기 위해 더 많은 CPU 주기를 소비해야 합니다.
메시지 라우팅 비용도 성능을 제한합니다. Azure Web PubSub 서비스는 클라이언트 집합 간에 메시지를 라우팅하는 메시지 브로커 역할을 합니다. 다른 시나리오 또는 API에는 다른 라우팅 정책이 필요합니다.
echo의 경우 클라이언트는 업스트리밍에 메시지를 보내고 업스트리밍은 메시지를 클라이언트에 되돌려 보냅니다. 이 패턴은 라우팅 비용이 가장 낮습니다. 그러나 브로드캐스트, 그룹으로 보내기, 연결로 보내기의 경우 Azure Web PubSub 서비스는 내부 분산 데이터 구조를 통해 대상 연결을 조회해야 합니다. 이 추가 처리에서 더 많은 CPU, 메모리 및 네트워크 대역폭을 사용합니다. 결과적으로 성능이 느려집니다.
요약하면 인바운드 및 아웃바운드 용량에 영향을 주는 요인은 다음과 같습니다.
장치 크기(CPU/메모리)
연결 수
메시지 크기
메시지 전송 속도
사용 사례 시나리오(라우팅 비용)
적절한 단위 크기 찾기
인바운드/아웃바운드 용량을 어떻게 평가하거나 특정 사용 사례에 적합한 단위 크기를 찾을 수 있나요?
각 단위 크기에는 고유한 최대 인바운드 대역폭과 아웃바운드 대역폭이 있습니다. 인바운드 또는 아웃바운드 트래픽이 임계값을 초과하는 경우에는 원활한 사용자 환경이 보장되지 않습니다.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections: 메시지를 전송하는 연결의 수입니다.
- outboundConnections: 메시지를 수신하는 연결의 수입니다.
- messageSize: 단일 메시지의 크기입니다(평균 값). 1024바이트 미만의 작은 메시지는 1024바이트 메시지와 유사한 성능 영향을 미칩니다.
- sendInterval: 메시지를 보내는 간격입니다. 예를 들어 1초는 1초에 1개의 메시지를 보내는 것을 의미합니다. 간격이 줄어들면 일정 기간 동안 더 많은 메시지를 전송하는 것을 의미합니다. 예를 들어 0.5초는 1초에 2개의 메시지를 보내는 것을 의미합니다.
- 연결: 각 단위 크기에 대해 Azure Web PubSub 서비스에 대해 약정된 최대 임계값입니다. 임계값을 초과하는 연결은 제한됩니다.
업스트리밍이 충분히 강력하고 성능 병목 현상이 아니라고 가정합니다. 그런 다음 각 단위 크기에 대한 최대 인바운드 및 아웃바운드 대역폭을 확인합니다.
사례 연구
다음 섹션에서는 Web PubSub 하위 프로토콜을 통해 그룹에 보내기, CloudEvent 트리거, REST API 호출의 세 가지 일반적인 사용 사례를 살펴봅니다. 각 시나리오에 대해, Azure Web PubSub 서비스의 현재 인바운드 및 아웃바운드 용량이 나열됩니다. 또한 성능에 영향을 주는 주요 요인에 대해 설명합니다.
모든 사용 사례에서 기본 메시지 크기는 2048바이트이고 메시지 전송 간격은 1초입니다.
Web PubSub 하위 프로토콜을 통해 그룹에 보내기
이 서비스는 클라이언트가 업스트리밍 서버로의 왕복 대신 직접 게시/구독을 수행할 수 있도록 하는 json.webpubsub.azure.v1이라는 특정 하위 프로토콜을 지원합니다. 이 시나리오는 서버가 관련되지 않고 모든 트래픽이 클라이언트-서비스 WebSocket 연결을 통과하므로 효율적입니다.
그룹 멤버 및 그룹 수는 성능에 영향을 주는 두 가지 요인입니다. 분석을 간소화하기 위해 다음과 같이 두 종류의 그룹을 정의합니다.
- 대규모 그룹: 그룹 번호는 항상 10입니다. 그룹 멤버 수는 (최대 연결 수)/10과 같습니다. 예를 들어 단위 1의 경우 연결 수가 1,000이면 모든 그룹에 멤버가 1000/10 = 100명 있습니다.
- 소규모 그룹: 모든 그룹에는 10개의 연결이 있습니다. 그룹 번호는 (최대 연결 수)/10과 같습니다. 예를 들어 단위 1의 경우 연결 수가 1,000이면 그룹이 1000/10 = 100개 있습니다.
그룹으로 보내기는 분산 데이터 구조를 통해 대상 연결을 찾아야 하므로 Azure Web PubSub 서비스에 대한 라우팅 비용이 발생합니다. 전송 연결이 늘어나면 비용이 증가합니다.
대규모 그룹
대규모 그룹으로 보내기의 경우 라우팅 비용 제한에 도달하기 전에 아웃바운드 대역폭이 병목 상태가 됩니다. 다음 표에는 최대 아웃바운드 대역폭이 나와 있습니다.
| 대규모 그룹으로 보내기 | 단위 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 | 1,000 | 5,000 | 10,000 | 5,000 | 10,000 | 20,000 |
| 그룹 수 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 초당 인바운드 메시지 수 | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| 인바운드 대역폭 | 60KBps | 60KBps | 60KBps | 60KBps | 60KBps | 60KBps | 60KBps | 60KBps |
| 초당 아웃바운드 메시지 수 | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| 아웃바운드 대역폭 | 6MBps | 12MBps | 60MBps | 300MBps | 600MBps | 1,200MBps | 3,000MBps | 6,000MBps |
소규모 그룹
라우팅 비용은 여러 소규모 그룹으로 메시지를 보낼 때 상당합니다. 현재 Azure Web PubSub 서비스 구현은 Unit50에서 라우팅 비용 제한에 도달합니다. CPU와 메모리를 더 추가하는 것은 도움이 되지 않으므로 설계상 단위 100이 더 이상 향상시킬 수 없습니다. 더 많은 인바운드 대역폭이 필요한 경우 Premium_P2(단위 >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 |
참고 항목
표에 나열된 그룹 수, 그룹 멤버 수는 하드 제한이 아닙니다. 이러한 매개 변수 값은 안정적인 벤치마크 시나리오를 설정하기 위해 선택됩니다.
클라우드 이벤트 트리거
서비스는 CloudEvents HTTP 프로토콜을 사용하여 업스트리밍 웹후크에 클라이언트 이벤트를 전달합니다.
모든 이벤트에 대해 등록된 업스트리밍에 대한 HTTP POST 요청을 공식화하고 HTTP 응답을 예상합니다.
참고 항목
Web PubSub는 업스트리밍 이벤트 전달을 위해 HTTP 2.0도 지원합니다. 아래 결과는 HTTP 1.1을 사용하여 테스트되었습니다. 앱 서버가 HTTP 2.0을 지원하면 성능이 향상됩니다.
에코
이 경우 앱 서버는 http 응답에 원래 메시지를 다시 씁니다. 에코 동작은 최대 인바운드 대역폭이 최대 아웃바운드 대역폭과 같음을 결정합니다. 자세한 내용은 다음 표를 참조하세요.
| 에코 | 단위 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 |
| 초당 인바운드/아웃바운드 메시지 수 | 500 | 1,000 | 5,000 | 25,000 | 50,000 | 100,000 | 250,000 | 500,000 |
| 인바운드/아웃바운드 대역폭 | 1MBps | 2MBps | 10MBps | 50MBps | 100MBps | 200MBps | 500MBps | 1,000MBps |
REST API
Azure Web PubSub는 클라이언트를 관리하고 실시간 메시지를 전달하기 위한 강력한 API를 제공합니다.
REST API를 통해 사용자에게 보내기
벤치마크는 Azure Web PubSub 서비스에 대한 연결을 시작하기 전에 모든 클라이언트에 사용자 이름을 할당합니다.
| 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 |
| 초당 인바운드/아웃바운드 메시지 수 | 180 | 360 | 1,800 | 9,000 | 18,000 | 36,000 | 90,000 | 180,000 |
| 인바운드/아웃바운드 대역폭 | 360KBps | 720KBps | 3.6MBps | 18MBps | 36MBps | 72MBps | 180MBps | 360MBps |
REST API를 통해 브로드캐스트
대역폭은 대규모 그룹으로 보내기의 대역폭과 동일합니다.
| 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 |
| 초당 인바운드 메시지 수 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| 초당 아웃바운드 메시지 수 | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| 인바운드 대역폭 | 6KBps | 6KBps | 6KBps | 6KBps | 6KBps | 6KBps | 6KBps | 6KBps |
| 아웃바운드 대역폭 | 6MBps | 12MBps | 60MBps | 300MBps | 600MBps | 1,200MBps | 3,000MB | 6,000MB |
다음 단계
다음 리소스를 사용하여 사용자 고유의 애플리케이션 빌드를 시작합니다.