Azure SignalR Service の回復性とディザスターリカバリー

[アーティクル]
10/17/2024

回復性とディザスターリカバリーは、各種オンラインシステムに共通の要件です。 Azure SignalR Service は既に 99.9% の可用性を提供していますが、それはあくまでリージョンごとのサービスです。リージョン全体が停止しても、サービスインスタンスは常に 1 つのリージョンで実行されているため、他のリージョンにフェールオーバーされることはありません。

リージョンのディザスターリカバリーを行う場合は、次の 2 つの方法をお勧めします。

geo レプリケーションを有効にする (簡単な方法)。この機能は、リージョンのフェールオーバーを自動的に処理します。有効にすると、Azure SignalR インスタンスは 1 つだけのままで、コードの変更は発生しません。詳細については、geo レプリケーションを確認してください。
サービス SDK で複数のエンドポイントを使用する。 Microsoft のサービス SDK は複数の SignalR サービスインスタンスをサポートしており、一部のインスタンスが使用できない場合は自動的に他のインスタンスに切り替わります。この機能を利用すれば、障害発生時に復旧できるようになりますが、適切なシステムトポロジをご自分で設定する必要があります。 このドキュメントでは、その方法について説明します。

SignalR サービスの高可用性アーキテクチャ

リージョンをまたぐ回復性を SignalR サービスに確保するには、複数のサービスインスタンスを異なるリージョンにセットアップする必要があります。そうすることで、1 つのリージョンがダウンしても、その他のリージョンをバックアップとして使用することができます。アプリサーバーが複数のサービスインスタンスに接続する際には、プライマリとセカンダリという 2 つのロールが存在します。プライマリはオンライントラフィックの受信を担当するインスタンスであり、セカンダリは完全に機能するフォールバックインスタンスとして機能します。この SDK の実装では、ネゴシエートからはプライマリエンドポイントだけが返されるため、正常時にクライアントが接続するのはプライマリエンドポイントだけです。しかし、プライマリインスタンスがダウンしているときは、クライアントが引き続き接続できるよう、ネゴシエートでセカンダリエンドポイントが返されます。プライマリインスタンスとアプリサーバーは、通常のサーバー接続を介して接続されますが、セカンダリインスタンスとアプリサーバーは、弱い接続と呼ばれる特殊な接続を介して接続されます。弱い接続の特徴の 1 つは、セカンダリインスタンスが別のリージョンにあるため、クライアント接続ルーティングを受け入れることができないことです。クライアントを別のリージョンにルーティングすることは最適な選択ではありません (待ち時間が長くなります)。

1 つのサービスインスタンスを複数のアプリサーバーに接続するとき、そのインスタンスには、複数のロールを割り当てることができます。リージョンをまたぐシナリオでは、SignalR サービスインスタンスとアプリサーバーとを 2 ペア以上用意するのが一般的な構成です。それぞれのペア内でアプリサーバーと SignalR サービスとが同じリージョン内に存在し、SignalR サービスは、プライマリロールとしてアプリサーバーに接続されます。ペアとペアの間でも、アプリサーバーと SignalR サービスとが接続されますが、SignalR は、別のリージョン内のサーバーに接続するときにはセカンダリとなります。

このトポロジであっても、すべてのアプリサーバーと SignalR サービスインスタンスが相互接続されているので、一方のサーバーからすべてのクライアントにメッセージを配信することはできます。しかしクライアントが接続されているときは、最適なネットワーク待ち時間を確保するために、そのクライアントは、同じリージョン内のアプリサーバーにルーティングされます。

次のダイアグラムは、このようなトポロジを示しています。

この図は、それぞれがアプリサーバーと SignalR サービスを持つ 2 つのリージョンを示しています。各サーバーは、プライマリとしてそのリージョンの SignalR サービスに関連付けられ、セカンダリとして他のリージョンのサービスに関連付けられています。

複数の SignalR サービスインスタンスを構成する

複数の SignalR サービスインスタンスは、アプリサーバーと Azure Functions の両方でサポートされています。

SignalR サービスとアプリサーバーまたは Azure Functions を各リージョンに作成したら、すべての SignalR サービスインスタンスに接続するようにアプリサーバーまたは Azure Functions を構成できます。

config による方法

環境変数/アプリの設定/web.cofig から Azure:SignalR:ConnectionString という名前の config エントリで SignalR サービスの接続文字列を設定する方法をご存知のはずです。複数のエンドポイントがある場合は、複数の config エントリでそれらを設定してください。それぞれ次の形式で設定します。

Azure:SignalR:ConnectionString:<name>:<role>

ConnectionString の <name> はエンドポイントの名前であり、<role> はそのロール (プライマリまたはセカンダリ) です。名前は省略可能ですが、複数のエンドポイント間でルーティングの動作をさらにカスタマイズしたい場合に役立ちます。

コードによる方法

どこか他の場所に接続文字列を保存したい場合は、コードからそれらを読み取って、AddAzureSignalR() (ASP.NET Core の場合) または MapAzureSignalR() (ASP.NET の場合) を呼び出す際にパラメーターとして使用することもできます。

コード例を次に示します。

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

複数のプライマリまたはセカンダリインスタンスを構成できます。プライマリおよび/またはセカンダリのインスタンスが複数ある場合、ネゴシエートは次の順序でエンドポイントを返します。

少なくとも 1 つのプライマリインスタンスがオンラインになっている場合は、ランダムなオンラインのプライマリインスタンスを返します。
すべてのプライマリインスタンスがダウンしている場合は、ランダムなオンラインのセカンダリインスタンスを返します。

Azure Functions SignalR のバインドの場合

複数の SignalR Service インスタンスを有効にするには、次のことを行う必要があります。

Persistent の転送の種類を使用します。

既定のトランスポートの種類は Transient モードです。次のエントリを local.settings.json ファイルまたは Azure のアプリケーション設定に追加する必要があります。
```
{
    "AzureSignalRServiceTransportType":"Persistent"
}
```
Note

Transient モードから Persistent モードに切り替えると、JSON シリアル化の動作が変わる可能性があります。これは、Transient モードでは、ハブメソッドの引数のシリアル化に Newtonsoft.Json ライブラリが使用されますが、Persistent モードでは、System.Text.Json ライブラリが既定で使用されるためです。 System.Text.Json には、Newtonsoft.Json との既定の動作にいくつかの重要な違いがあります。 Persistent モードで Newtonsoft.Json を使用する場合は、構成項目 (local.settings.json ファイルでは "Azure:SignalR:HubProtocol":"NewtonsoftJson"、または Azure portal では Azure__SignalR__HubProtocol=NewtonsoftJson) を追加できます。
構成で複数の SignalR Service エンドポイントエントリを構成します。

ServiceEndpoint オブジェクトを使用して SignalR Service インスタンスを表します。エントリキーに <EndpointName> と <EndpointType>、エントリ値に接続文字列を使用してサービスエンドポイントを定義できます。キーの形式は次のとおりです。
```
Azure:SignalR:Endpoints:<EndpointName>:<EndpointType>
```
<EndpointType> は省略可能であり、既定値は primary です。以下のサンプルを参照してください。
```
{
    "Azure:SignalR:Endpoints:EastUs":"<ConnectionString>",

    "Azure:SignalR:Endpoints:EastUs2:Secondary":"<ConnectionString>",

    "Azure:SignalR:Endpoints:WestUs:Primary":"<ConnectionString>"
}
```
Note
- Azure portal の App Service で Azure SignalR エンドポイントを構成するときは、必ずキー内の ":" を "__" (二重アンダースコア) に置き換えます。理由については、環境変数に関する記事を参照してください。
- また、キー {ConnectionStringSetting} を使用して構成された接続文字列 (既定値は "AzureSignalRConnectionString") は、名前が空のプライマリサービスエンドポイントとして認識されます。ただし、この構成スタイルは複数のエンドポイントには推奨されません。

Management SDK の場合

構成から複数のエンドポイントを追加する

SignalR Service 接続文字列のキー Azure:SignalR:Endpoints を使用して構成します。キーの形式は Azure:SignalR:Endpoints:{Name}:{EndpointType} にする必要があります。この Name と EndpointType は ServiceEndpoint オブジェクトのプロパティであり、コードからアクセスできます。

次の dotnet コマンドを使用して、複数のインスタンス接続文字列を追加できます。

dotnet user-secrets set Azure:SignalR:Endpoints:east-region-a <ConnectionString1>
dotnet user-secrets set Azure:SignalR:Endpoints:east-region-b:primary <ConnectionString2>
dotnet user-secrets set Azure:SignalR:Endpoints:backup:secondary <ConnectionString3>

コードから複数のエンドポイントを追加する

ServiceEndpoint クラスには、Azure SignalR Service エンドポイントのプロパティが示されています。次のように、Azure SignalR Management SDK を使用して複数のインスタンスエンドポイントを構成できます。

var serviceManager = new ServiceManagerBuilder()
                    .WithOptions(option =>
                    {
                        options.Endpoints = new ServiceEndpoint[]
                        {
                            // Note: this is just a demonstration of how to set options.Endpoints
                            // Having ConnectionStrings explicitly set inside the code is not encouraged
                            // You can fetch it from a safe place such as Azure KeyVault
                            new ServiceEndpoint("<ConnectionString0>"),
                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
                        };
                    })
                    .BuildServiceManager();

フェールオーバーのシーケンスとベストプラクティス

以上で、適切なシステムトポロジのセットアップが完了しました。一方の SignalR Service インスタンスがダウンすると、オンライントラフィックが別のインスタンスにルーティングされます。プライマリインスタンスがダウン (およびその後しばらくしてから復旧) したときに発生する状況を以下に示します。

プライマリサービスインスタンスがダウンすると、このインスタンスにおけるすべてのサーバー接続が切断されます。
このインスタンスは、そこに接続されているすべてのサーバーによってオフラインとしてマークされます。また、ネゴシエートでこのエンドポイントは返されなくなり、セカンダリのエンドポイントが返されるようになります。
また、このインスタンスに対するクライアント接続もすべて閉じられ、クライアントの再接続が行われます。以後アプリサーバーからはセカンダリエンドポイントが返されるので、クライアントはセカンダリインスタンスに接続されます。
これですべてのオンライントラフィックがセカンダリインスタンスに向かうようになりました。セカンダリはすべてのアプリサーバーに接続されているため、サーバーからクライアントへのメッセージは依然としてすべて配信されます。しかし、クライアントからサーバーへのメッセージのルーティング先は、同じリージョン内のアプリサーバーに限られます。
プライマリインスタンスが復旧してオンラインに戻った後、アプリサーバーはプライマリインスタンスへの接続を再度確立し、それをオンラインとしてマークします。ネゴシエートでは再びプライマリエンドポイントが返されるようになるので、新しいクライアントは元どおりプライマリに接続されます。ただし、既存のクライアントは切断されず、自ら切断するまでそのままセカンダリにルーティングされます。

以下の図は、SignalR サービスにおけるフェールオーバーの動作を示したものです。

図.1 フェールオーバー前

図.2 フェールオーバー後

図.3 プライマリの復旧後間もなく

正常時には、オンライントラフィック (青色) がプライマリのアプリサーバーと SignalR サービスにのみ向かうことがわかります。フェールオーバー後は、セカンダリのアプリサーバーと SignalR サービスもアクティブになります。プライマリの SignalR サービスがオンラインに戻った後、新しいクライアントはプライマリの SignalR に接続されます。一方、既存のクライアントはそのままセカンダリに接続された状態になるので、両方のインスタンスにトラフィックが向かうことになります。既存のクライアントがすべて切断されると、システムが正常な状態に戻ります (図 1)。

リージョンをまたぐ高可用性アーキテクチャを導入する場合、主に次の 2 つのパターンがあります。

1 つ目は、アプリサーバーと SignalR サービスインスタンスから成る一方のペアですべてのオンライントラフィックを処理し、もう一方のペアはバックアップとして使用する方法です (これは "アクティブ/パッシブ" と呼ばれます。図1 を参照)。
もう 1 つは、アプリサーバーと SignalR サービスインスタンスから成るペアを 2 つ (またはそれ以上) 用意し、それぞれのペアがオンライントラフィックを分担して処理し、他のペアのバックアップとして機能する方法です (これは "アクティブ/アクティブ" と呼ばれます。図 3 と同様)。

SignalR サービスは両方のパターンに対応できます。主な違いはアプリサーバーの導入方法です。アプリサーバーがアクティブ/パッシブである場合、SignalR Service もアクティブ/パッシブになります (プライマリのアプリサーバーから返されるのはそのプライマリ SignalR Service インスタンスのみであるため)。アプリサーバーがアクティブ/アクティブである場合、SignalR Service もアクティブ/アクティブになります (すべてのアプリサーバーから、それぞれのプライマリ SignalR インスタンスが返されるので、そのすべてでトラフィックを受けることができます)。

どちらのパターンを使用するにしても、アプリサーバーには、それぞれの SignalR Service インスタンスをプライマリとして接続する必要がある点に注意してください。

また、SignalR 接続 (長時間接続) の性質上、障害とフェールオーバーが発生すると、クライアントでは接続の切断が生じます。そのようなケースはクライアント側で処理して、エンドカスタマーからは見えないようにする必要があります。たとえば、接続が閉じられた後で再接続を行うことが考えられます。

フェールオーバーをテストする方法

フェールオーバーをトリガーするには、次の手順に従います。

ポータルのプライマリリソースの [ネットワーク] タブで、パブリックネットワークアクセスを無効にします。リソースでプライベートネットワークが有効になっている場合は、"アクセス制御ルール" を使用して、すべてのトラフィックを拒否します。
プライマリリソースを再起動します。

次のステップ

この記事では、SignalR サービスに回復性を持たせるためのアプリケーションの構成方法について説明しました。 SignalR サービスにおける接続のルーティングとサーバー/クライアント接続の詳細については、SignalR サービスの内部について説明したこちらの記事を参照してください。

大量の接続を処理するために複数のインスタンスを同時に使用するスケーリングシナリオ (シャーディングなど) については、複数のインスタンスをスケーリングする方法に関するページを参照してください。

複数の SignalR サービスインスタンスで Azure Functions を構成する方法の詳細については、 Azure Functions での複数の Azure SignalR サービスインスタンスのサポートに関する記事を参照してください。

次の方法で共有

Azure SignalR Service の回復性とディザスターリカバリー

SignalR サービスの高可用性アーキテクチャ

複数の SignalR サービスインスタンスを構成する

config による方法

コードによる方法

Azure Functions SignalR のバインドの場合

Management SDK の場合

構成から複数のエンドポイントを追加する

コードから複数のエンドポイントを追加する

フェールオーバーのシーケンスとベストプラクティス

フェールオーバーをテストする方法

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure SignalR Service の回復性とディザスター リカバリー

SignalR サービスの高可用性アーキテクチャ

複数の SignalR サービス インスタンスを構成する

config による方法

コードによる方法

Azure Functions SignalR のバインドの場合

Management SDK の場合

構成から複数のエンドポイントを追加する

コードから複数のエンドポイントを追加する

フェールオーバーのシーケンスとベスト プラクティス

フェールオーバーをテストする方法

次のステップ

フィードバック

その他のリソース

Azure SignalR Service の回復性とディザスターリカバリー

複数の SignalR サービスインスタンスを構成する

フェールオーバーのシーケンスとベストプラクティス