Azure Service Bus geo レプリケーション (プレビュー)

[アーティクル]
11/04/2024

Service Bus の geo レプリケーション機能は、障害および災害に対して Azure Service Bus アプリケーションを保護するオプションの 1 つであり、メタデータ (エンティティ、構成、プロパティ) とデータ (メッセージデータと、メッセージのプロパティ/状態の変更) の両方のレプリケーションを提供します。

Note

この機能は、Azure Service Bus の Premium レベルで使用できます。

geo レプリケーション機能を使用すると、名前空間のメタデータとデータが、プライマリ Azure リージョンから 1 つ以上のセカンダリ Azure リージョンに、継続的にレプリケートされることが保証されます。

キュー、トピック、サブスクリプション、フィルター。
エンティティ内に存在するデータ。
名前空間内のメッセージに対して実行されたすべての状態変更とプロパティ変更。
名前空間の構成。

Note

現在、サポートされているセカンダリは 1 つだけです。

この機能を使用すると、任意のセカンダリ Azure リージョンをいつでもプライマリに昇格できます。セカンダリを昇格すると、選択したセカンダリ Azure リージョンに名前空間の名前が再ポイントされ、プライマリとセカンダリの Azure リージョン間でロールが切り替わります。昇格は、開始するとほぼ瞬時に行われます。

重要

この機能は現在パブリックプレビュー段階であるため、運用環境のシナリオでは使用しないでください。
現在、パブリックプレビューでは、以下の Azure リージョンがサポートされています。

リージョン	Region	リージョン
オーストラリア中部	ドイツ北部	NorwayWest
AustraliaCentral2	GermanyWestCentral	ポーランド中部
AustraliaEast	IsraelCentral	SouthAfricaNorth
AustraliaSoutheast	ItalyNorth	SouthAfricaWest
BrazilSoutheast	JapanEast	SoutheastAsia
カナダ中部	JapanWest	SouthIndia
カナダ東部	JioIndiaCentral	SpainCentral
CentralIndia	JioIndiaWest	SwedenCentral
CentralUS	KoreaCentral	スイス北部
CentralUSEUAP	KoreaSouth	スイス西部
EastAsia	MexicoCentral	UAECentral
EastUS2	NorthCentralUS	UAENorth
FranceCentral	NorthEurope	UKSouth
FranceSouth	NorwayEast	UKWest

この機能は現在、新しい名前空間上で使用できます。名前空間でこの機能が以前に有効になっていた場合は、(セカンダリ Azure リージョンを削除することで) 無効にして、再度有効にすることができます。
現在、次の機能はサポートされていません。パブリックプレビューにさらに多くの機能を導入するために継続的に取り組んでおり、この一覧を最新の状態で更新する予定です。
- 大きいメッセージのサポート。
- VNET/高度なネットワーク機能 (プライベートエンドポイント、IP ACL、NSP、サービスエンドポイント)。
- ID (MSI、ローカル認証を無効にする)、暗号化設定 (カスタマーマネージドキー (CMK) 暗号化、または Bring Your Own Key (BYOK) 暗号化)。
- 自動スケーリング。
- パーティション分割された名前空間。
- Event Grid にイベントを送信する。
この機能は、 Azure Service Bus geo ディザスターリカバリー機能と組み合わせて使用することはできません。

シナリオ

ここで説明するように、geo レプリケーション機能を使用してさまざまなシナリオを実装できます。

障害復旧

データとメタデータは、プライマリとセカンダリの Azure リージョン間で継続的に同期されます。ある Azure リージョンでラグが発生した場合、または使用できない場合は、セカンダリ Azure リージョンをプライマリとして昇格できます。この昇格により、新しく昇格された Azure リージョン内で、中断のないワークロードの操作が可能になります。このような昇格は、ワークロード内の Service Bus またはその他のサービスの低下によって必要になる場合があります (特に、さまざまなコンポーネントを一緒に実行することを目的とする場合)。重大度と影響を受けるサービスに応じて、昇格は計画済みまたは強制のいずれかになる場合があります。計画済みの昇格の場合は、処理中のメッセージは昇格が完了する前にレプリケートされますが、強制の昇格ではこれが直ちに実行されます。

Azure リージョンの移行

Service Bus のワークロードを移行して、別の Azure リージョン内で実行したい場合があります。たとえば、Azure によって、場所、ユーザー、またはその他のサービスに地理的に近い、新しい Azure リージョンが追加された場合です。または、ほとんどのワークロードが実行される Azure リージョンを変更した場合に移行することもできます。 geo レプリケーション機能は、次の場合にも優れたソリューションを提供します。この場合では、目的の新しい Azure リージョンをセカンダリ Azure リージョンとして、既存の名前空間上に geo レプリケーションを設定し、同期が完了するまで待ちます。この時点で、計画済みの昇格を開始し、処理中のメッセージをレプリケートできるようにします。この昇格が完了したら、必要に応じて古い Azure リージョン (現在はセカンダリ Azure リージョン) を削除し、目的の Azure リージョン内でワークロードを実行し続けることができます。

基本的な概念

geo レプリケーション機能は、プライマリ/セカンダリレプリケーションモデルにおいて、メタデータとデータのレプリケーションを実装します。特定の時点では、プロデューサーとコンシューマーの両方にサービスを提供する、1 つのプライマリ Azure リージョンがあります。セカンダリはホットスタンバイ Azure リージョンとして機能します。つまり、これらのセカンダリ Azure リージョンとやり取りすることはできません。ただし、プライマリ Azure リージョンと同じ構成で実行されるため、高速な昇格が可能になります。つまり、昇格が完了した直後にワークロードを実行し続けることができます。 geo レプリケーション機能は、 Premium レベルで使用できます。

geo レプリケーション機能の主な側面の一部は次のとおりです。

Service Bus サービスは、名前空間で構成されたレプリケーションの一貫性に準拠する Azure リージョン間で、メタデータ、メッセージデータ、メッセージ状態、プロパティの変更について、フルマネージドレプリケーションを実行します。
1 つの名前空間のホスト名。geo レプリケーションが有効な名前空間が正常に構成されると、ユーザーはクライアントアプリケーション内で名前空間のホスト名を使用できます。ホスト名は、構成されたプライマリとセカンダリの Azure リージョンに依存せずに動作し、常にプライマリ Azure リージョンを指します。
顧客が昇格を開始すると、ホスト名は新しいプライマリ Azure リージョンとして選択された Azure リージョンを指します。古いプライマリがセカンダリ Azure リージョンになります。
セカンダリ Azure リージョン上で読み取りまたは書き込みはできません。
同期と非同期のレプリケーションモードについては、こちらで詳しく説明されています。
プライマリからセカンダリの Azure リージョンへのカスタマーマネージドの昇格により、完全な所有権と、停止の解決の可視性を提供します。メトリックを使用できます。これは、顧客側からの昇格を自動化するのに役立ちます。
セカンダリ Azure リージョンは、顧客の裁量で追加または削除できます。

レプリケーションモード

同期と非同期の 2 つのレプリケーションモードがあります。これら 2 つのモードの違いを知ることが重要です。

非同期レプリケーション

非同期レプリケーションを使用すると、すべての要求がプライマリ上でコミットされ、その後、確認がクライアントに送信されます。セカンダリ Azure リージョンへのレプリケーションは非同期的に行われます。ユーザーは、許容される最大ラグタイム (時間差) を構成できます。ラグタイム (時間差) は、プライマリとセカンダリの Azure リージョン上の、最新のアクション間のサービス側のオフセットです。アクティブなセカンダリのラグがユーザー構成を超えて増加した場合、プライマリは受信要求の調整を開始します。

同期レプリケーション

同期レプリケーションを使用すると、すべての要求がセカンダリにレプリケートされるため、その操作をコミットして確認してからプライマリ上でコミットする必要があります。そのため、アプリケーションは、発行、レプリケート、確認、コミットにかかる速度で発行されます。さらに、これはアプリケーションが両方の Azure リージョンの可用性に関連付けられていることも意味します。セカンダリ Azure リージョンにラグが発生した場合、または使用できない場合、メッセージは確認もコミットもされず、プライマリは受信要求を調整します。

レプリケーションモードの比較

同期レプリケーション使用する場合:

分散コミット操作に起因して、待機時間がより長くなります。
可用性は、2 つの Azure リージョンの可用性に関連付けられています。

一方、同期レプリケーションは、データが安全であることを最も確実に保証します。同期レプリケーションがある場合、それをコミットすると、geo レプリケーション用に構成したすべての Azure リージョン内にコミットされ、最適なデータ保証が提供されます。

非同期レプリケーションの場合:

待機時間への影響は最小限になります。
セカンダリ Azure リージョンの損失は、可用性にすぐに影響を与えるわけではありません。ただし、構成された最大レプリケーションラグに達すると、可用性が影響を受けます。

そのため、同期レプリケーションで行われるような、コミットする前にすべての Azure リージョンにデータがあるという絶対的な保証はありません。また、データの損失や重複が発生する場合があります。ただし、1 つの Azure リージョンでラグが発生した、または使用できなくなった場合にすぐに影響を受けることがなくなるため、より低遅延になることに加えて、アプリケーションの可用性も向上します。

機能	同期レプリケーション	非同期レプリケーション
Latency	分散コミット操作に起因して、より長くなります	影響は最小限です
可用性	セカンダリ Azure リージョンの可用性に関連付けられます	セカンダリ Azure リージョンの損失がすぐに可用性に影響を与えるわけではありません
データの整合性	確認の前に、データは両方の Azure リージョン内で常にコミットされます	確認の前にプライマリでのみデータはコミットされます
RPO (復旧ポイントの目標)	RPO 0、昇格時のデータ損失はありません	RPO > 0、昇格時のデータ損失の可能性があります

レプリケーションモードは、geo レプリケーションの構成後に変更できます。同期から非同期、または非同期から同期に変更できます。非同期から同期に変更すると、ラグが 0 に達した後にセカンダリは同期として構成されます。何らかの理由で継続的なラグを伴って実行されている場合、ラグがゼロに達してモードを同期に切り替えるには、パブリッシャーを一時停止する必要がある可能性があります。非同期レプリケーションではなく、同期レプリケーションを有効にする理由は、アプリケーションの可用性ではなく、データの重要性、特定のビジネスニーズ、またはコンプライアンス上の理由に関連しています。

Note

セカンダリ Azure リージョンでラグが発生したまたは使用不能になった場合、アプリケーションはこのリージョンに対してレプリケートできなくなり、レプリケーションラグに達すると調整が開始されます。プライマリの場所内で名前空間を引き続き使用するには、問題のあるセカンダリ Azure リージョンを削除します。セカンダリ Azure リージョンがもう構成されない場合、geo レプリケーションを有効にせずに、名前空間は継続します。追加のセカンダリ Azure リージョンを追加することはいつでも可能です。

セカンダリ Azure リージョンの選択

geo レプリケーション機能を有効にするには、この機能が有効なプライマリとセカンダリの Azure リージョンを使用する必要があります。 geo レプリケーション機能は、発行されたメッセージをプライマリからセカンダリの Azure リージョンにレプリケートできるかどうかによって異なります。セカンダリ Azure リージョンが別の大陸上にある場合、プライマリからセカンダリの Azure リージョンへのレプリケーションラグに大きな影響があります。可用性の理由で geo レプリケーションを使用する場合は、可能な限りセカンダリ Azure リージョンを、少なくとも同じ大陸上に展開するのが最善です。地理的な距離によって引き起こされる待機時間について、より適切に理解するには、「Azure ネットワークラウンドトリップ待機時間統計」で詳細をご確認ください。

geo レプリケーションの管理

geo レプリケーション機能を使用すると、顧客はメタデータとデータをレプリケートするセカンダリ Azure リージョンを構成できます。そのため、顧客は次の管理タスクを実行できます。

geo レプリケーションを構成する: セカンダリ Azure リージョンは、geo レプリケーション機能が有効なリージョン内の、任意の新しいまたは既存の名前空間上で構成できます。

Note

現在、パブリックプレビュー段階では、新しい名前空間のみがサポートされています。
レプリケーションの一貫性を構成する: geo レプリケーションを構成する際に同期や非同期のレプリケーションを設定しますが、その後で切り替えることもできます。
昇格をトリガーする: すべての昇格は顧客が開始します。
セカンダリを削除する: セカンダリ Azure リージョンを削除する場合は、いつでも実行できます。その後、セカンダリ Azure リージョン内のデータは削除されます。

セットアップ

Azure Portal の使用

次のセクションでは、Azure portal を利用し、新しい名前空間上に geo レプリケーション機能を設定する概要について説明します。

Note

このエクスペリエンスは、パブリックプレビュー中に変更される場合があります。このドキュメントは適宜更新する予定です。

新しい Premium レベルの名前空間を作成します。
[レプリケーション (プレビュー)] セクションの下にある [geo レプリケーションを有効にする] チェックボックスをオンにします。
[セカンダリリージョンを追加する] ボタンをクリックし、Azure リージョンを選択します。
[同期レプリケーション] チェックボックスをオンにするか、[非同期レプリケーション - レプリケーションの最大時間差] の値を秒単位で指定します。

Bicep テンプレートを使用する

geo レプリケーション機能を有効にして名前空間を作成するには、geoDataReplication プロパティセクションを追加します。

param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int

resource sb 'Microsoft.ServiceBus/namespaces@2023-01-01-preview' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

管理

geo レプリケーション機能を有効にして名前空間を作成したら、[レプリケーション (プレビュー)] ブレードからこの機能を管理できます。

レプリケーションモードを切り替える

レプリケーションモードを切り替える、または最大レプリケーションラグを更新するには、[レプリケーション整合性] の下にあるリンクをクリックし、[同期レプリケーション] を有効または無効にするチェックボックスをクリックするか、[非同期レプリケーション - レプリケーションの最大時間差] テキストボックス内の値を更新して変更します。 geo レプリケーション機能の構成を更新する方法を示すスクリーンショット。

セカンダリ Azure リージョンを削除する

セカンダリ Azure リージョンを削除するには、その Azure リージョンの横にある [...] 省略記号をクリックし、[削除] をクリックします。 Azure リージョンを削除するには、ポップアップブレード内の手順に従います。セカンダリ Azure リージョンを削除する方法を示すスクリーンショット。

昇格フロー

昇格は、顧客によって手動で (コマンドを使用して明示的に、またはコマンドをトリガーする顧客所有のビジネスロジックを使用して) トリガーされます。Azure によってではありません。これにより、Azure のバックボーン上での故障に対するソリューションの完全な所有権と可視性がお客様に付与されます。 [計画済み] の昇格を選択すると、サービスはレプリケーションラグが処理されるのを待ってから昇格を開始します。一方、[強制] の昇格を選択すると、サービスはすぐに昇格を開始します。名前空間は、昇格が要求された時点から昇格が完了する時点まで、読み取り専用モードになります。計画済みの昇格が開始された後、いつでも強制の昇格を実行できます。これにより、計画フェールオーバーに必要以上に時間がかかる場合に、ユーザーは昇格の迅速化を制御できます。

重要

強制の昇格を使用すると、レプリケートされていないデータが失われる場合があります。

昇格が開始された後:

ホスト名はセカンダリ Azure リージョンを指すように更新されます。これには最大で数分かかる場合があります。

Note

ping コマンド「ping your-namespace-fully-qualified-name」を実行すると、現在のプライマリ Azure リージョンを確認できます
クライアントはセカンダリ Azure リージョンに自動的に再接続します。

昇格は、監視システムを使用して、またはカスタムビルドの監視ソリューションを使用して自動化できます。ただしそのような自動化は、特別な計画と作業が伴い、この記事で取り上げる範囲を超えています。

Azure Portal の使用

ポータル内で昇格アイコンをクリックし、ポップアップブレード内の手順に従って Azure リージョンを削除します。

Azure CLI の使用

Azure CLI コマンドを実行して昇格を開始します。 Force プロパティは省略可能で、既定値は false です。

az rest --method post --url https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.ServiceBus/namespaces/<namespaceName>/failover?api-version=2023-01-01-preview --body "{'properties': {'PrimaryLocation': '<newPrimaryocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"

データレプリケーションの監視

ユーザーは、Log Analytics 内のレプリケーションラグメトリックを監視することで、レプリケーションジョブの進行状況を監視できます。

「Azure Service Bus を監視する」で説明されているように、Service Bus 名前空間内のメトリックログを有効にします。
メトリックログが有効になったら、ログの表示が開始される前に数分間、名前空間でデータを作成して使用する必要があります。
メトリックログを表示するには、[Service Bus] の [監視] セクションに移動し、[ログ] ブレードをクリックします。次のクエリを使用して、プライマリとセカンダリの Azure リージョン間のレプリケーションラグ (秒単位) を確認できます。

AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

データの発行

アプリケーションを発行すると、geo レプリケーションが有効な名前空間の名前空間ホスト名を使用して、geo レプリケートされた名前空間にデータを発行できます。発行のアプローチは geo レプリケーション以外のケースと同じであり、データプレーン SDK またはクライアントアプリケーションを変更する必要はありません。次の状況では、発行を使用できない場合があります。

セカンダリ Azure リージョンの昇格を要求した後、既存のプライマリ Azure リージョンは、昇格が完了するまで Service Bus に発行された新しいメッセージを拒否します。
プライマリとセカンダリの Azure リージョン間のレプリケーションラグが最大レプリケーションラグ期間に達すると、パブリッシャーのイングレスワークロードが調整される場合があります。

パブリッシャーのアプリケーションは、セカンダリ Azure リージョン内の名前空間に直接アクセスすることはできません。

データの使用

アプリケーションを使用すると、geo レプリケーション機能が有効な名前空間の、名前空間ホスト名を使用してデータを使用できます。昇格が開始された時点から昇格が完了するまで、コンシューマーの操作はサポートされません。

考慮事項

このリリースでは次の考慮事項にご注意ください。

昇格の計画では、時間的な要因も考慮する必要があります。たとえば、接続が切れて 15 から 20 分間を超えた場合は、昇格を開始する判断を下すかもしれません。
複雑な分散インフラストラクチャの昇格は、少なくとも 1 回はリハーサルを行う必要があります。

価格

Service Bus の Premium レベルの価格は、メッセージングユニット単位です。 geo レプリケーション機能を使用すると、セカンダリ Azure リージョンはプライマリ Azure リージョンと同じ数の MU で実行され、価格は MU の合計数に対して計算されます。さらに、発行された帯域幅とセカンダリ Azure リージョンの数を掛け算した結果に基づいて料金が発生します。早期パブリックプレビュー期間中は、この請求金額は免除されます。

次のステップ

geo レプリケーションの REST API リファレンスはこちらを参照してください。
geo レプリケーションの GitHub 上のサンプルを実行してください。
geo レプリケーションのエイリアスにメッセージを送信するサンプルを参照してください。

Service Bus メッセージングの詳細については、次の記事をご覧ください。

次の方法で共有

Azure Service Bus geo レプリケーション (プレビュー)

シナリオ

障害復旧

Azure リージョンの移行

基本的な概念

レプリケーションモード

非同期レプリケーション

同期レプリケーション

レプリケーションモードの比較

セカンダリ Azure リージョンの選択

geo レプリケーションの管理

セットアップ

Azure Portal の使用

Bicep テンプレートを使用する

管理

レプリケーションモードを切り替える

セカンダリ Azure リージョンを削除する

昇格フロー

Azure Portal の使用

Azure CLI の使用

データレプリケーションの監視

データの発行

データの使用

考慮事項

価格

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Service Bus geo レプリケーション (プレビュー)

シナリオ

障害復旧

Azure リージョンの移行

基本的な概念

レプリケーション モード

非同期レプリケーション

同期レプリケーション

レプリケーション モードの比較

セカンダリ Azure リージョンの選択

geo レプリケーションの管理

セットアップ

Azure Portal の使用

Bicep テンプレートを使用する

管理

レプリケーション モードを切り替える

セカンダリ Azure リージョンを削除する

昇格フロー

Azure Portal の使用

Azure CLI の使用

データ レプリケーションの監視

データの発行

データの使用

考慮事項

価格

次のステップ

フィードバック

その他のリソース

レプリケーションモード

レプリケーションモードの比較

レプリケーションモードを切り替える

データレプリケーションの監視