Azure Web PubSub の geo レプリケーション

ミッション クリティカルなアプリでは、多くの場合、堅牢なフェールオーバー システムを用意し、ユーザーがいる場所の近くからサービスを提供する必要があります。 geo レプリケーション機能がリリースされる前は、開発者は複数の Web PubSub リソースをデプロイし、リソース間の通信を調整するためのカスタム コードを記述する必要がありました。 現在では、Azure portal で実施できる手軽な構成で、この機能を簡単に実装することができます。

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

• リージョン内の障害に対する回復性の向上: リージョン内で障害が発生した場合、クライアントは正常なレプリカに自動的にルーティングされます。
• リージョン間の通信: geo レプリケーション対応リソースの裏側には複数のリソースが存在していますが、開発者は、これら通常のものと同じように使用することができます。 レプリカ間の通信は、サービスによって処理されます。
• ネットワーク速度の向上: 地理的に遠く離れているクライアント間の通信は、最寄りのレプリカに接続して行われます。 レプリカ間の通信は Azure グローバル ネットワークのバックボーンを経由して行われ、高速性と安定性が確保されています。
• 簡単な管理: すべてのレプリカは、プライマリ Web PubSub リソースの構成を共有します。

前提条件

• Premium レベルの Web PubSub リソース。

ユース ケースの例

ソーシャル メディア企業の Contoso

Contoso は、米国とカナダの全域に広い顧客ベースを擁するソーシャル メディア企業です。 Contoso は、ユーザーが相互に接続できる機能を持つ、モバイル アプリと Web アプリをユーザーに提供しています。 Contoso アプリケーションは、米国中部にデプロイされています。 Contoso のアーキテクチャの一部として、クライアント アプリとアプリケーション サーバーの間に永続的な WebSocket 接続を確立するために Web PubSub が使用されています。 Contoso にとって、WebSocket 接続の管理を Web PubSub にオフロードできる点は好ましいですが、カナダのユーザーから届く、長い待機時間に関する報告を読むのは好ましくありません。 さらに、Contoso の開発チームは、リージョンで障害が発生した場合でも、ユーザーが中断なしでアプリにアクセスできるようにしたいと考えています。

Contoso は、カナダのユーザーに地理的に近い別の Web PubSub リソースをカナダ中部に設定することが可能です。 ただし、複数の Web PubSub リソースを管理するには、次のようないくつかの課題があります。

1. カナダと米国のユーザーが相互にやりとりできるようにする、リージョン間の通信メカニズムを実装する必要があります。
2. 開発チームは、それぞれ異なるドメインと接続文字列を持つ、2 つの Web PubSub リソースを設定して管理する必要があります。
3. リージョンで障害が発生した場合、トラフィックを利用可能なリソースに転送する必要があります。

しかし、上記のすべてが、製品イノベーションにかけたいエンジニアリング リソースを奪います。

geo レプリケーション機能を利用する

geo レプリケーション機能を利用すると、Contoso は、カナダ中部にレプリカを設置することで上記の課題を効果的に克服できます。 開発チームは、コードを変更する必要がないことに安心するでしょう。 Azure portal でいくつかのボタンをクリックするだけで、簡単に実現することができます。 開発チームはまた、Contoso がヨーロッパ市場への参入を計画している中、ヨーロッパにもう 1 つレプリカを追加するだけでこれを実現することができるということを関係者と共有できて満足しています。

Web PubSub リソースで geo レプリケーションを有効にする方法

ポータル

Azure リージョンにレプリカを作成するには、Web PubSub リソースに移動し、Azure portal 上の [レプリカ] ブレードを見つけて、[追加] をクリックしてレプリカを作成します。

ポータルで、作成したレプリカの名前をクリックすると、そのレプリカの情報確認と編集ができます。

Bicep

Visual Studio Code または使い慣れたエディターを使用して次の内容のファイルを作成し、「main.bicep」という名前を付けます。

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

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

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

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

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

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

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

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

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

Azure CLI を使用して Bicep ファイルをデプロイする

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

CLI

webpubsub 拡張機能を最新バージョンに更新してから、以下を実行します。

az webpubsub replica create --sku Premium_P1 -l eastus --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Note

• 現在、レプリカ数は、プライマリ リソースあたり最大 8 個に制限されています。

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

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

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

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

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

レプリカの削除

Web PubSub リソースのレプリカを作成した後、不要になった場合はいつでも削除できます。

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

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

Azure CLI を使用してレプリカを削除するには:

 az webpubsub replica delete --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

geo レプリケーション機能のしくみを理解する

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

Note

• プライマリ Azure Web PubSub リソースは、データ プレーン上ではそのリソースのレプリカとまったく同じように機能します。

---

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

Azure Web PubSub 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 解決に含められないため、トラフィックの転送先になりません。

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

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

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

Note

• DNS キャッシュがあるため、DNS の更新が有効になるまでに数分かかる場合があります。
• 確立済みの接続は、切断されるまで影響を受けません。

geo レプリケーション機能を有効にした後のパフォーマンスへの影響

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

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

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

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

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

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

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

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