Azure SignalR での geo レプリケーション

現地拠点を築きたい企業や、堅牢なフェールオーバー システムを必要とする企業の多くが、複数の Azure リージョンにサービスをデプロイすることを選択しています。 Azure SignalR に geo レプリケーションが統合されたことで、複数リージョン シナリオの管理は大幅に容易になりました。

geo レプリケーションを使用するメリット

• リージョン内の障害に対する回復性の向上: リージョン内で障害が発生した場合、Azure SignalR DNS は他のリージョンにある正常なレプリカに解決されます。
• リージョン間の通信: 別々のレプリカの間で、双方が同じインスタンスであるかのような相互通信ができます。
• ネットワーク速度の向上: 地理的に遠く離れているクライアント間の通信は、最寄りのレプリカに接続して行われます。 レプリカ間の通信は Azure グローバル ネットワークのバックボーンを経由して行われ、高速性と安定性が確保されています。
• 構成の共有: すべてのレプリカで、プライマリ Azure SignalR Service リソースの構成が維持されます。

前提条件

• Premium レベルの Azure SignalR Service があること。

ユース ケースの例

Contoso は、米国とカナダの全域に広い顧客ベースを擁するソーシャル メディア企業です。 顧客のニーズに応えて顧客間の通信を実現するためのサービス群を米国中部で運用しています。 Azure SignalR Service は、ユーザーの接続に対応し、ユーザー間の通信を円滑に提供するために使われています。 Contoso のエンド ユーザーの大半は、電話の利用者です。 カナダのエンド ユーザーには、地理的に遠く離れていることに起因する大きな遅延とネットワーク品質低下が発生することがあります。

geo レプリケーション機能の登場以前に Contoso が実施できた対応策としては、カナダのユーザー向けに、もう 1 つの Azure SignalR Service をカナダ中部に設置することが考えられます。 地理的に近い場所に Azure SignalR Service をセットアップすれば、エンド ユーザーのネットワーク品質向上と遅延時間の短縮を実現できます。

しかし、複数の Azure SignalR Services を運用することは以下のような困難を伴います。

1. カナダと米国のユーザー間で通話を可能にするために、異なるリージョンをまたぐ通信メカニズムが必要になります。
2. 開発チームは、異なる 2 つの Azure SignalR Services にそれぞれ異なるドメインと接続文字列を設定して管理する必要があります。
3. いずれかのリージョンに障害が発生した場合は、トラフィックを別のリージョンに切り替える必要があります。

geo レプリケーションの活用

新しい geo レプリケーション機能を利用すると、Contoso は、カナダ中部にレプリカを設置することで上記の問題を効果的に克服できます。

SignalR のレプリカを作成する

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

価格設定とリソース ユニット

各レプリカは、独自の unit と autoscale settings を持っています。

レプリカは、Azure SignalR Service の Premium レベルで使用できる機能です。 課金処理は、各レプリカのユニットごとに、それぞれの送信トラフィックに応じて別々に行われます。 また、無料メッセージ クォータも別々に計算されます。

上記の例において、Contoso はカナダ中部にレプリカを 1 つ追加しました。 カナダ中部のレプリカに関する Contoso への課金は、Premium レベルの価格設定に基づき、このレプリカのユニットとメッセージに応じて行われます。

リージョン間の送信トラフィックにはエグレス料金が発生します。 メッセージがレプリカ間で転送され、さらに転送後にクライアントまたはサーバーに正常に送信された場合は、送信メッセージとして課金されます。

レプリカの削除

Azure SignalR Service のレプリカは、作成後、不要になったときにいつでも削除できます。

Azure portal でレプリカを削除するには、次の手順に従います。

1. Azure SignalR Service に移動し、[レプリカ] ブレードを選択します。 削除するレプリカをクリックします。
2. レプリカの概要ブレードで、[削除] ボタンをクリックします。

SignalR のレプリカが機能するしくみ

SignalR のレプリカが機能するしくみの概略図を以下に示します。

1. クライアントは、アプリ サーバーとネゴシエートして Azure SignalR サービスへのリダイレクトを受け取ります。 次に、SignalR サービスの完全修飾ドメイン名 (FQDN) である contoso.service.signalr.net を解決します。 この FQDN は Traffic Manager (TM) をポイントしています。TM は、最寄りのリージョンにある SignalR インスタンスの正規名 (CNAME) を返します。
2. クライアントは、この CNAME を使用してリージョン インスタンス (レプリカ) への接続を確立します。
3. 2 つのレプリカの間では相互のデータ同期が行われます。 1 つのレプリカに送信されたメッセージは、必要に応じて他のレプリカに転送されます。
4. TM の実行する正常性チェックによってレプリカの障害が検出された場合、TM は、障害が発生したインスタンスのエンドポイントをドメイン解決プロセスから除外します。 詳細については、下の「回復性とディザスター リカバリー」を参照してください。

回復性とディザスター リカバリー

Azure SignalR Service では、Traffic Manager (TM) を使用してレプリカの正常性チェックと DNS 解決が行われます。 平常時、すべてのレプリカが正常に機能している間には、クライアントは最寄りのレプリカに転送されます。 次に例を示します。

• eastus に近いクライアントは eastus 内にあるレプリカに転送されます。
• 同様に、westus に近いクライアントは westus 内にあるレプリカに転送されます。

eastus で リージョン内の障害が発生した場合 (下図)、TM の正常性チェックによってそのリージョンの障害が検出されます。 以後、障害が発生したレプリカの DNS は、TM による DNS 解決の結果から除外されます。 DNS Time-to-Live (TTL) 期間 (90 秒に設定) が経過すると、eastus 内のクライアントは、westus 内のレプリカに接続するようリダイレクトされます。

eastus 内の問題が解決されてリージョンがオンラインに戻ると、正常性チェックが成功するようになります。 以後、eastus 内のクライアントは、再びこのリージョン内のレプリカに転送されます。 この移行処理はスムーズに行われるため、接続を利用するクライアントには、確立済みの接続が閉じるまで影響はありません。

このフェールオーバーと回復のプロセスは自動的に実行され、手作業での対応は必要ありません。

サーバー接続についても、クライアント接続の場合と同じようにフェイルオーバーとリカバリーが機能します。

レプリカのエンドポイントを無効または有効にする

レプリカのセットアップ時には、そのレプリカのエンドポイントを有効にするか、無効にするかを選択できます。 無効にすると、そのレプリカはプライマリ FQDN の DNS 解決に含められないため、トラフィックの転送先になりません。

エンドポイントの有効と無効は、レプリカの作成後に切り替えることもできます。 切り替えるには、プライマリ リソースのレプリカ ブレードで、レプリカの右側にある [...] ボタンをクリックし、[エンドポイントの有効化] または [エンドポイントの無効化] を選択します。

レプリケーションを削除する場合は、その前にエンドポイントを無効にすることを検討してください。 既に確立済みの接続は、時間の経過とともに切断されていきます。 新たな接続要求が来ないようにして、レプリケーションが最終的にアイドル状態になるのを待ち、 それから削除プロセスを実行すれば、確実にシームレスな削除ができます。

この機能は、リージョン内の問題のトラブルシューティングにも役立ちます。

レプリカを追加した後のパフォーマンスへの影響

レプリカを有効にすると、クライアントは所在地に基づいて自然に分散されます。 SignalR によってレプリカ間のデータ同期が実行されますが、それによってサーバー負荷に発生するオーバーヘッドは、ほとんどの一般的なユース ケースにおいては最小限に抑えられます。

具体的には、アプリケーションの通常の使用形態が、比較的大きなグループ (10 以上のサイズ) へのブロードキャストや単一の接続である場合、同期処理がパフォーマンスに及ぼす影響は、わずかに認識できる程度になります。 一方、小規模なグループ (10 未満のサイズ) や個人ユーザーへのメッセージ送信に使用する場合は、同期のオーバーヘッドがやや意識されやすくなることがあります。

効果的なフェイルオーバー管理を確実に行えるよう、各レプリカには、すべてのトラフィックに対応できるユニット サイズを設定することをお勧めします。 または、ユニット サイズの管理に自動スケーリングを使用することもできます。

性能評価の詳細については、性能に関するページを参照してください。

継承されない構成と継承された構成

レプリカは、ほとんどの構成をプライマリ リソースから継承しますが、一部の設定はレプリカで直接構成する必要があります。 以下に、これらの構成の一覧を示します。

1. SKU: 各レプリカには独自の SKU 名とユニット サイズがあります。 レプリカの自動スケーリング ルールは、個々のメトリックに基づいて個別に構成する必要があります。
2. 共有プライベート エンドポイント: 共有プライベート エンドポイントはレプリカに自動的にレプリケートされますが、ターゲット プライベート リンク リソースでは個別の承認が必要です。 共有プライベート エンドポイントを追加または削除するには、プライマリ リソースでそれらを管理します。 共有プライベート エンドポイントが承認されるまで、レプリカを有効にしないでください。
3. ログの宛先設定。 レプリカで構成されていない場合は、プライマリ リソースのログのみが転送されます。
4. アラート。

その他のすべての構成は、プライマリ リソースから継承されます。 たとえば、アクセス キー、ID、アプリケーション ファイアウォール、カスタム ドメイン、プライベート エンドポイント、アクセス制御などです。