다음을 통해 공유

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

  • 아티클

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

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

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

Important

원시 연결 문자열 데모용으로만 이 문서에 표시됩니다.

연결 문자열 애플리케이션이 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>

    • AddAzureSignalR을 호출할 때 ClientEndpoint를 구성합니다.

      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 서비스를 구성한 경우 동일한 asrs_request_id 쿼리 매개 변수(동일한 연결에 사용됨을 의미)를 사용하여 negotiate 요청 및 connect 요청이 동일한 SignalR 서비스 인스턴스로 라우팅되는지 확인합니다.

  • 역방향 프록시를 사용하는 경우 공용 네트워크 액세스를 사용하지 않도록 설정하고 프라이빗 엔드포인트를 사용하여 역방향 프록시에서 VNet을 통해 SignalR 서비스까지 프라이빗 액세스만 허용하여 SignalR 서비스를 더욱 안전하게 보호할 수 있습니다.

다음 단계