Azure SignalR Service を Azure API Management と共に使用する方法

Azure API Management サービスは、あらゆる環境にわたる API のためのハイブリッドなマルチクラウド管理プラットフォームです。 この記事では、Azure API Management と Azure SignalR サービスを使用して、アプリケーションにリアルタイム機能を追加する方法について説明します。

重要

この記事に示す生の接続文字列は、デモンストレーションのみを目的としています。

接続文字列には、アプリケーションが Azure SignalR Service にアクセスするために必要な認可情報が含まれています。 接続文字列内のアクセス キーは、サービスのルート パスワードに似ています。 運用環境では、常にアクセス キーを保護してください。 Azure Key Vault を使用してキーの管理とローテーションを安全に行い、Microsoft Entra ID を使用して接続文字列をセキュリティで保護し、Microsoft Entra ID を使用してアクセスを認可します。

アクセス キーを他のユーザーに配布したり、ハードコーディングしたり、他のユーザーがアクセスできるプレーンテキストで保存したりしないでください。 キーが侵害された可能性があると思われる場合は、キーをローテーションしてください。

リソースを作成する

• 「クイックスタート: ARM テンプレートを使用して Azure SignalR Service をデプロイする」に従って、SignalR Service インスタンス ASRS1 を作成します

• ARM テンプレートを使用した Azure API Management のデプロイに関するクイックスタートに従って、API Management インスタンス APIM1 を作成します

API の構成

制限事項

SignalR クライアントの要求には、次の 2 種類があります。

• ネゴシエート要求: <APIM-URL>/client/negotiate/ への HTTP POST 要求
• 接続要求: <APIM-URL>/client/ への要求。SignalR クライアントのトランスポートの種類によって WebSocket、ServerSentEvent、または LongPolling になります。

接続要求の種類は、SignalR クライアントのトランスポートの種類によって異なります。 現時点では、API Management では、同じサフィックスに対してさまざまな種類の API はまだサポートされていません。 この制限により、API Management を使用した場合、SignalR クライアントでは、WebSocket トランスポート タイプから他のトランスポート タイプへのフォールバックはサポートされません。 ServerSentEvent から LongPolling へのフォールバックはサポートされます。 以下のセクションでは、さまざまな種類のトランスポートの詳細な構成について説明します。

クライアントが WebSocket トランスポートに接続するときに API を構成する

このセクションでは、SignalR クライアントが WebSocket トランスポートに接続するときに API Management を構成する手順について説明します。 SignalR クライアントが WebSocket トランスポートに接続した場合、次の 3 種類の要求が関係します。

1. ネゴシエートのための OPTIONS プリフライト HTTP 要求
2. ネゴシエートのための POST HTTP 要求
3. 接続のための WebSocket 要求

ポータルから API Management を構成してみましょう。

1. API Management インスタンス APIM1 のポータル内の [API] タブに移動し、[API を追加]、[HTTP] の順に選択し、次のパラメーターを指定して作成します。
   • 表示名: SignalR negotiate
   • Web サービスの URL: https://<your-signalr-service-url>/client/negotiate/
   • API URL サフィックス: client/negotiate/
2. 作成した SignalR negotiate API を選択し、以下を設定して保存します。
   1. [デザイン] タブで
      1. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: negotiate preflight
         • URL: OPTIONS /
      2. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: negotiate
         • URL: POST /
   2. [設定] タブに切り替え、デモ用なので、[サブスクリプションは必須です] をオフにします
3. [API を追加] を選択し、[WebSocket] を選択し、次のパラメーターを指定して作成します。
   • 表示名: SignalR connect
   • WebSocket URL: wss://<your-signalr-service-url>/client/
   • API URL サフィックス: client/
4. 作成した SignalR connect API を選択し、以下の設定で保存します。
   1. [設定] タブに切り替え、デモ用なので、[サブスクリプションは必須です] をオフにします

これで、WebSocket トランスポートを使用して SignalR クライアントをサポートするように API Management が正常に構成されました。

クライアントが ServerSentEvents または LongPolling トランスポートに接続するときに API を構成する

このセクションでは、SignalR クライアントが ServerSentEvents または LongPolling トランスポート タイプに接続するときに API Management を構成する手順について説明します。 SignalR クライアントが ServerSentEvents または LongPolling トランスポートに接続した場合、次の 5 種類の要求が関係します。

1. ネゴシエートのための OPTIONS プリフライト HTTP 要求
2. ネゴシエートのための POST HTTP 要求
3. 接続のための OPTIONS プリフライト HTTP 要求
4. 接続のための POST HTTP 要求
5. 接続のための GET HTTP 要求

では、ポータルから API Management を構成してみましょう。

1. API Management インスタンス APIM1 のポータル内の [API] タブに移動し、[API を追加]、[HTTP] の順に選択し、次のパラメーターを指定して作成します。
   • 表示名: SignalR
   • Web サービスの URL: https://<your-signalr-service-url>/client/
   • API URL サフィックス: client/
2. 作成した SignalR API を選択し、以下を設定して保存します。
   1. [デザイン] タブで
      1. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: negotiate preflight
         • URL: OPTIONS /negotiate
      2. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: negotiate
         • URL: POST /negotiate
      3. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: connect preflight
         • URL: OPTIONS /
      4. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: connect
         • URL: POST /
      5. [操作の追加] を選択し、次のパラメーターを指定して保存します。
         • 表示名: connect get
         • URL: GET /
      6. 新しく追加した connect get 操作を選択し、バックエンド ポリシーを編集して ServerSentEvents のバッファリングを無効にします。詳細については、こちらを確認してください。

         <backend>
             <forward-request buffer-response="false" />
         </backend>
         

   2. [設定] タブに切り替え、デモ用なので、[サブスクリプションは必須です] をオフにします

これで、ServerSentEvents または LongPolling トランスポートを使用して SignalR クライアントをサポートするように API Management が正常に構成されました。

チャットを実行する

これで、トラフィックは API Management を介して SignalR Service に到達できるようになりました。 例としてこのチャット アプリケーションを使用してみましょう。 まず、ローカルで実行してみましょう。

この記事では、デモ目的でのみ生の接続文字列が表示されます。 運用環境では、常にアクセス キーを保護してください。 Azure Key Vault を使用してキーの管理とローテーションを安全に行い、Microsoft Entra ID を使用して接続文字列をセキュリティで保護し、Microsoft Entra ID を使用してアクセスを認可します。

• 最初に、ASRS1 の接続文字列を取得しましょう。

  • ASRS1 の [接続文字列] タブで
    • クライアント エンドポイント: https://apim1.azure-api.netなど、APIM1 のゲートウェイ URL を使用して URL を入力します。 これは、リバース プロキシを使用する際の接続文字列ジェネレーターであり、次回このタブに戻ったときにはこの値は保持されません。値が入力されると、接続文字列に ClientEndpoint セクションが追加されます。
    • 接続文字列をコピーします。

• GitHub リポジトリ https://github.com/aspnet/AzureSignalR-samples をクローンします。

• samples/Chatroom フォルダーに移動します。

• コピーした接続文字列を設定し、アプリケーションをローカルで実行すると、ConnectionString に ClientEndpoint セクションがあることを確認できます。

  cd samples/Chatroom
  dotnet restore
  dotnet user-secrets set Azure:SignalR:ConnectionString "<copied-connection-string-with-client-endpoint>"
  dotnet run
  

• クライアントのトランスポート タイプを構成する

  フォルダー wwwroot の下にある index.html を開き、connection の作成時にコードを見つけ、トランスポートの種類を指定するように更新します。

  たとえば、サーバー送信イベントまたは長いポーリングを使用する接続を指定するには、コードを次のように更新します。

  const connection = new signalR.HubConnectionBuilder()
    .withUrl(
      "/chat",
      signalR.HttpTransportType.ServerSentEvents |
        signalR.HttpTransportType.LongPolling
    )
    .build();
  

  WebSocket を使用する接続を指定するには、コードを次のように更新します。

  const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chat", signalR.HttpTransportType.WebSockets)
    .build();
  

• ブラウザーから http://localhost:5000 を開き、F12 を使用してネットワーク トレースを表示すると、APIM1 を介して接続が確立されていることを確認できます。

次のステップ

これで、Azure SignalR を使用して API Management にリアルタイム機能が正常に追加されました。 SignalR Service の詳細情報を確認します。