次の方法で共有

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

  • [アーティクル]

リバース プロキシ サーバーは、Azure SignalR Service の前面で使用できます。 リバース プロキシ サーバーは、クライアントと Azure SignalR Service やその他のサービスの間に配置され、さまざまなシナリオで役立ちます。 たとえば、リバース プロキシ サーバーは、さまざまなクライアント要求を複数のバックエンド サービスに負荷分散できます。通常、さまざまなクライアント要求に対して異なるルーティング規則を構成し、さまざまなバックエンド サービスにアクセスするユーザーにシームレスなユーザー エクスペリエンスを提供できます。 また、一元的な保護コントロールを使用して、バックエンド サーバーを一般的な脆弱性の悪用から保護することもできます。 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 ホスト ヘッダーを Azure SignalR サービス URL (例: https://demo.service.signalr.net) で書き換えます。 Azure SignalR はマルチテナント サービスであり、HOST ヘッダーを利用して正しいエンドポイントに解決されます。 たとえば、Azure SignalR の Application Gateway を構成する場合は、[新しいホスト名でオーバーライドする] オプションで [はい] を選択します。

  • クライアントがリバース プロキシを経由して Azure SignalR に移動したら、リバース プロキシ URL として ClientEndpoint を設定します。 クライアントがハブ サーバーと "ネゴシエート" すると、ハブ サーバーはクライアントが接続するための ClientEndpoint で定義されている URL を返します。 詳細については、こちらを参照してください。

    ClientEndpoint を構成するには、次の 2 つの方法があります。

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

    • <reverse-proxy-URL>/client/negotiate/ への HTTP ポスト要求。これは、ネゴシエート要求と呼ばれます。
    • <reverse-proxy-URL>/client/ へのトランスポートの種類に応じた WebSocket/SSE/LongPolling 接続要求。これは、接続要求と呼ばれます。

    リバース プロキシで /client/ サブパスに対して両方のトランスポートの種類がサポートされていることを確認します。 たとえば、トランスポートの種類が WebSocket の場合は、リバース プロキシが /client/ サブパスに対して HTTP と WebSocket の両方をサポートしていることを確認します。

    リバース プロキシの背後で複数の SignalR サービスを構成している場合は、negotiate 要求と、同じ asrs_request_id クエリ パラメーターを使用した (つまり、同じ接続に対する) connect 要求が、同じ SignalR サービス インスタンスにルーティングされていることを確認します。

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

次のステップ