다음을 통해 공유


Azure SignalR Service의 메시지 및 연결

Azure SignalR Service의 청구 모델은 연결 수와 서비스의 아웃바운드 메시지 수를 기반으로 합니다. 이 문서에서는 요금을 청구하기 위해 메시지 및 연결을 정의하고 계산하는 방식을 설명합니다.

메시지 형식

Azure SignalR Service는 ASP.NET Core SignalR과 동일하게 JSONMessagePack 형식을 지원합니다.

메시지 크기

Azure SignalR Service 메시지에는 다음 제한이 적용됩니다.

  • 클라이언트 메시지:
    • 긴 폴링 또는 서버 쪽 이벤트의 경우 클라이언트는 1MB보다 큰 메시지를 보낼 수 없습니다.
    • 서비스에 대한 Websocket의 크기 제한은 없습니다.
    • 앱 서버는 클라이언트 메시지 크기에 대한 제한을 설정할 수 있습니다. 기본값은 32KB입니다. 자세한 내용은 ASP.NET Core SignalR의 보안 고려 사항을 참조하세요.
    • 서버리스의 경우 메시지 크기는 업스트림 구현에 의해 제한되지만 1MB 미만이 권장됩니다.
  • 서버 메시지:
    • 서버 메시지 크기에는 제한이 없지만 16MB 미만이 권장됩니다.
    • 앱 서버는 클라이언트 메시지 크기에 대한 제한을 설정할 수 있습니다. 기본값은 32KB입니다. 자세한 내용은 ASP.NET Core SignalR의 보안 고려 사항을 참조하세요.
    • 서버리스:
      • Rest API: 메시지 본문의 경우 1MB, 헤더의 경우 16KB입니다.
      • Websocket, 관리 SDK 영구 모드에는 제한이 없지만 16MB 미만이 권장됩니다.

Websocket 클라이언트의 경우 큰 메시지는 2KB 이하의 작은 메시지로 분할되어 별도로 전송됩니다. SDK는 메시지 분할 및 어셈블리를 처리합니다. 개발자의 수고가 필요하지 않습니다.

큰 메시지는 메시지 성능에 부정적인 영향을 줍니다. 되도록이면 작은 메시지를 사용하고, 테스트를 통해 각 사용 사례 시나리오에 맞는 최적의 메시지 크기를 확인하세요.

요금을 청구할 메시지를 계산하는 방법

서비스로 전송되는 메시지는 인바운드 메시지이며 서비스에서 보낸 메시지는 아웃바운드 메시지입니다. Azure SignalR Service에서 나가는 아웃바운드 메시지만 청구 대상에 포함됩니다. 클라이언트와 서버 간의 ping 메시지는 무시됩니다.

2KB를 초과하는 메시지는 2KB 크기의 메시지 여러 개로 계산됩니다. Azure Portal의 메시지 수 차트는 허브당 메시지 100개마다 업데이트됩니다.

예를 들어 하나의 애플리케이션 서버와 세 개의 클라이언트가 있다고 가정해 봅시다.

  • 애플리케이션 서버에서 연결된 모든 클라이언트에 1KB 메시지를 브로드캐스트하는 경우 애플리케이션 서버에서 서비스로 보내는 메시지는 무료 인바운드 메시지로 간주됩니다. 서비스에서 각 클라이언트로 보내는 세 개의 메시지가 아웃바운드 메시지이며 비용이 청구됩니다.

  • 클라이언트 A가 앱 서버를 거치지 않고 클라이언트 B에 1KB 인바운드 메시지를 보내는 경우 이 메시지는 무료 인바운드 메시지입니다. 서비스에서 클라이언트 B로 라우트된 메시지는 아웃바운드 메시지로 청구됩니다.

  • 한 클라이언트가 모든 클라이언트에 서버 브로드캐스트에 대한 4KB 메시지를 보낼 때 클라이언트 3개와 애플리케이션 서버 1개가 있는 경우 청구되는 메시지 수는 8개입니다.

    • 서비스에서 애플리케이션 서버로 메시지 1개
    • 서비스에서 클라이언트로 메시지 3개 각 메시지는 2KB 메시지 2개로 계산됩니다.

연결 수를 계산하는 방법

Azure SignalR Service는 애플리케이션 서버 및 클라이언트 연결을 만듭니다. 기본적으로 각 애플리케이션 서버는 허브당 5개의 초기 연결로 시작하고 각 클라이언트에는 하나의 클라이언트 연결이 있습니다.

예를 들어 고객에게 2개의 애플리케이션 서버가 있고 코드로 허브 5개를 정의한다고 가정해 봅시다. 서버 연결 수는 50개(앱 서버 2개 * 허브 5개 * 허브당 연결 5개)입니다.

Azure Portal에 표시되는 연결 수에는 서버, 클라이언트, 진단, 라이브 추적 연결이 포함됩니다. 연결 형식은 아래 목록에 정의되어 있습니다.

  • 서버 연결: Azure SignalR Service와 앱 서버를 연결합니다.
  • 클라이언트 연결: Azure SignalR Service와 클라이언트 앱을 연결합니다.
  • 진단 연결: 더 자세한 로그를 생성할 수 있는 특별한 유형의 클라이언트 연결로, 성능에 영향을 줄 수 있습니다. 해당 유형의 클라이언트는 문제 해결을 위해 설계되었습니다.
  • 라이브 추적 연결: 라이브 추적 엔드포인트에 연결하고 Azure SignalR Service의 라이브 추적을 수신합니다.

라이브 추적 연결은 클라이언트 연결이나 서버 연결로 계산되지 않습니다.

ASP.NET SignalR은 다른 방법으로 서버 연결 수를 계산합니다. 고객이 정의하는 허브 외에도 기본 허브 하나가 포함됩니다. 기본적으로 각 애플리케이션 서버에는 초기 서버 연결 5개가 더 필요합니다. 기본 허브의 초기 연결 수는 다른 허브와 동일하게 유지됩니다.

서비스와 애플리케이션 서버는 연결 상태를 계속 동기화하고 서버 연결을 조정하여 더 나은 성능 및 서비스 안정성을 확보합니다. 따라서 실행 중인 서비스의 서버 연결 수가 변경되는 것을 볼 수 있습니다.