역방향 프록시와 Azure SignalR을 통합하는 방법

2025-05-22

역방향 프록시 서버는 Azure SignalR Service의 앞에서 사용할 수 있습니다. 역방향 프록시 서버는 클라이언트와 Azure SignalR 서비스 사이에 배치되며 다른 서비스는 다양한 시나리오에서 도움이 될 수 있습니다. 예를 들어 역방향 프록시 서버는 서로 다른 백 엔드 서비스에 대한 서로 다른 클라이언트 요청의 부하를 분산할 수 있으며, 일반적으로 다른 클라이언트 요청에 대해 서로 다른 라우팅 규칙을 구성하고 다른 백 엔드 서비스에 액세스하는 사용자에게 원활한 사용자 환경을 제공할 수 있습니다. 또한 중앙 집중식 보호 제어를 사용하여 일반적인 공격 취약성으로부터 백 엔드 서버를 보호할 수 있습니다. Azure Application Gateway, Azure API Management 또는 Akamai와 같은 서비스는 역방향 프록시 서버 역할을 할 수 있습니다.

Azure SignalR과 함께 역방향 프록시 서버를 사용하는 일반적인 아키텍처는 다음과 같습니다.

역방향 프록시 서버와 함께 Azure SignalR을 사용하는 아키텍처를 보여 주는 다이어그램.

중요

이 문서에서는 데모 목적으로만 원시 연결 문자열을 사용합니다.

연결 문자열에는 애플리케이션이 Azure SignalR Service에 액세스하는 데 필요한 권한 부여 정보가 포함되어 있습니다. 연결 문자열 내의 액세스 키는 서비스의 루트 암호와 비슷합니다. 프로덕션 환경에서는 항상 액세스 키를 보호합니다. Azure Key Vault를 사용하여 키를 안전하게 관리하고 회전하고, Microsoft Entra ID를 사용하여 연결 문자열을 보호하고 Microsoft Entra ID로 액세스를 권한 부여합니다.

액세스 키를 다른 사용자에게 배포하거나 하드 코딩하거나 다른 사용자가 액세스할 수 있는 일반 텍스트로 저장하지 않도록 합니다. 키가 손상되었다고 생각되면 키를 교체하세요.

일반 사례

SignalR Service 앞에서 역방향 프록시를 사용할 때 따라야 할 몇 가지 일반적인 방법이 있습니다.

이 문서에서는 데모 목적으로만 원시 연결 문자열을 사용합니다. 프로덕션 환경에서는 항상 액세스 키를 보호합니다. Azure Key Vault를 사용하여 키를 안전하게 관리하고 회전하고, Microsoft Entra ID를 사용하여 연결 문자열을 보호하고 Microsoft Entra ID로 액세스를 권한 부여합니다.

들어오는 HTTP HOST 헤더를 Azure SignalR 서비스 URL(예: https://demo.service.signalr.net)로 다시 작성해야 합니다. Azure SignalR은 다중 테넌트 서비스이며 HOST 헤더를 사용하여 올바른 엔드포인트로 연결합니다. 예를 들어 Azure SignalR에 대한 Application Gateway를 구성할 때 새 호스트 이름으로 재정의 옵션에 대해 예를 선택합니다.
클라이언트가 역방향 프록시를 통해 Azure SignalR로 가는 경우 ClientEndpoint를 역방향 프록시 URL로 설정합니다. 클라이언트가 허브 서버와 협상하면 허브 서버는 ClientEndpoint에 정의된 URL을 반환하여 클라이언트가 연결할 수 있도록 합니다. 자세한 내용을 보려면 여기를 클릭하세요.

ClientEndpoint를 구성하는 방법은 두 가지가 있습니다.
- ConnectionString에 ClientEndpoint 섹션을 추가합니다. Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>
- ClientEndpoint을 호출할 때 AddAzureSignalR를 구성합니다.
```
services.AddSignalR().AddAzureSignalR(o =>
{
    o.Endpoints = new Microsoft.Azure.SignalR.ServiceEndpoint[1]
    {
        new Microsoft.Azure.SignalR.ServiceEndpoint("<azure-signalr-connection-string>")
        {
            ClientEndpoint = new Uri("<reverse-proxy-URL>")
        }
    };
})
```
클라이언트가 역방향 프록시를 통해 Azure SignalR로 가는 경우 두 가지 유형의 요청이 있습니다.
- <reverse-proxy-URL>/client/negotiate/으로 호출하는 에 대한 HTTP 게시 요청
- <reverse-proxy-URL>/client/으로 호출하는 에 대한 전송 유형에 따른 WebSocket/SSE/LongPolling 연결 요청입니다.
역방향 프록시가 /client/ 하위 경로에 대한 두 전송 유형을 모두 지원하는지 확인합니다. 예를 들어 전송 유형이 WebSocket인 경우 역방향 프록시가 /client/ 하위 경로에 대해 HTTP 및 WebSocket을 모두 지 원하는지 확인합니다.

역방향 프록시 뒤에 여러 SignalR 서비스를 구성한 경우 동일한 negotiate 쿼리 매개 변수(동일한 연결에 사용됨을 의미)를 사용하여 connect 요청 및 asrs_request_id 요청이 동일한 SignalR 서비스 인스턴스로 라우팅되는지 확인합니다.
(SSE)의 경우 ServerSentEvent역방향 프록시가 응답을 버퍼링하거나 캐시하지 않는지 확인합니다. 예를 들어 API Management는 서버에서 보낸 이벤트에 대한 API를 구성할 때 여기에 체크리스트를 나열합니다.
역방향 프록시를 사용하는 경우 공용 네트워크 액세스를 사용하지 않도록 설정하고 프라이빗 엔드포인트를 사용하여 역방향 프록시에서 VNet을 통해 SignalR 서비스까지 프라이빗 액세스만 허용하여 SignalR 서비스를 더욱 안전하게 보호할 수 있습니다.

다음 단계

Application Gateway로 작업하는 방법을 알아봅니다.
API Management 작업 방법을 알아봅니다.
Azure SignalR의 내부 사항에 대해 자세히 알아봅니다.

다음을 통해 공유

역방향 프록시와 Azure SignalR을 통합하는 방법

일반 사례

다음 단계

피드백

추가 리소스