Azure SignalR とリバース プロキシを統合する方法

リバース プロキシ サーバーは、Azure SignalR Service の前で使用できます。 リバース プロキシ サーバーは、クライアントと Azure SignalR サービスとその他のサービスの間に配置され、さまざまなシナリオで役立ちます。 たとえば、リバース プロキシ サーバーは、異なるバックエンド サービスに対して異なるクライアント要求を負荷分散し、通常は異なるクライアント要求に対して異なるルーティング規則を構成し、異なるバックエンド サービスにアクセスするユーザーにシームレスなユーザー エクスペリエンスを提供できます。 また、一元的な保護制御を使用して、バックエンド サーバーを一般的な悪用の脆弱性から保護することもできます。 Azure Application Gateway、Azure API Management、Akamai などのサービスは、リバース プロキシ サーバーとして機能できます。

Azure SignalR でリバース プロキシ サーバーを使用する一般的なアーキテクチャは次のとおりです。

一般的なプラクティス

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を構成するには、次の 2 つの方法があります。

  • ClientEndpoint セクションを ConnectionString に追加します。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 に接続する場合、次の 2 種類の要求があります。

  • <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 サービスインスタンスにルーティングされていることを確認してください。

• ServerSentEvent (SSE) の場合は、リバース プロキシがバッファーまたはキャッシュ応答を行っていないことを確認します。 たとえば、API Management は、サーバー送信イベントの API を構成するときに 、ここで チェック 項目を一覧表示します。

• リバース プロキシを使用する場合は、 パブリック ネットワーク アクセスを無効に し、 プライベート エンドポイント を使用して、リバース プロキシから VNet 経由で SignalR サービスへのプライベート アクセスのみを許可することで、SignalR サービスをさらにセキュリティで保護できます。

次のステップ

• Application Gateway を使用する方法について説明します。

• API Management を使用する方法について説明します。

• Azure SignalR の内部の詳細を確認します。