Azure Service Bus の geo ディザスター リカバリー

Service Bus の geo ディザスター リカバリー機能は、Azure Service Bus アプリケーションを故障や災害から保護するオプションの 1 つであり、複合アプリケーション構成の整合性を維持することを主な目的としています。

Note

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

geo ディザスター リカバリー機能を使用すると、名前空間 (エンティティ、構成、プロパティ) の構成全体が、プライマリ名前空間からペアになっているセカンダリ名前空間に継続的にレプリケートされるようになり、プライマリからセカンダリへの 1 回限りのフェールオーバーの移動をいつでも開始できます。 フェールオーバー移動を行うと、名前空間の選択したエイリアス名がセカンダリ名前空間に再指定されてから、ペアリングが解除されます。 フェールオーバーは、開始されるとほぼ瞬時に完了します。

考慮すべき重要な点

• この機能を使用すると、同じ構成の操作を瞬時に継続できますが、キューやトピック サブスクリプションまたは配信不能キューに保持されているメッセージがレプリケートされることはありません。 キュー セマンティクスを保持するには、このようなレプリケーションには、メッセージ データのレプリケーションだけでなく、geo レプリケーション機能 (パブリック プレビュー)で提供されるブローカー内のすべての状態変更が必要です。
• Microsoft Entra ロールベースのアクセス制御 (RBAC) によるプライマリ名前空間内の Service Bus エンティティへの割り当ては、セカンダリ名前空間にレプリケートされません。 セカンダリ名前空間にロールの割り当てを手動で作成して、アクセスをセキュリティで保護します。
• 次の構成はレプリケートされません。
  • 仮想ネットワークの構成
  • プライベート エンドポイント接続
  • すべてのネットワーク アクセスが有効
  • 信頼されたサービス アクセスが有効
  • パブリック ネットワーク アクセス
  • 既定のネットワーク アクション
  • ID と暗号化の設定 (カスタマー マネージド キー暗号化または Bring Your Own Key (BYOK) 暗号化)
  • 自動スケーリングの有効化
  • ローカル認証の無効化
  • Azure Event Grid のサブスクリプション
• パーティション分割された名前空間とパーティション分割されていない名前空間のペアリングはサポートされていません。
• AutoDeleteOnIdle がエンティティで有効になっている場合、フェールオーバーの発生時にセカンダリ名前空間にエンティティが存在しない可能性があります。 セカンダリがプライマリになると、メタデータの一部ではない最終アクセス状態は新しいプライマリでは使用できなくなり、AutoDeleteOnIdle のクリーンアップの一環としてエンティティは削除される可能性があります。

ヒント

キューとトピック サブスクリプションの内容をレプリケートし、アクティブ/アクティブ構成内の対応する名前空間を操作して停止や災害に対処するには、この geo ディザスター リカバリー機能セットを使用せず、geo レプリケーション機能を使用するか、レプリケーションのガイダンスに従ってください。

基本的な概念と用語

geo ディザスター リカバリー機能は、メタデータの災害復旧を実装しており、一次および二次障害復旧の名前空間に依存しています。 geo ディザスター リカバリー機能は、Premium レベルでのみ使用可能です。 別名を使用して接続を確立するので、接続文字列に変更を加える必要はありません。

この記事では、次の用語を使用します。

• エイリアス: 設定したディザスター リカバリー構成の名前です。 エイリアスは、1 つの不変の完全修飾ドメイン名 (FQDN) の接続文字列を示します。 アプリケーションでは、このエイリアスの接続文字列を使用して名前空間に接続します。 エイリアスを使用すると、フェールオーバーがトリガーされたときに接続文字列の変更が発生することはありません。

• プライマリ/セカンダリ名前空間: エイリアスに対応する名前空間です。 プライマリ名前空間は "アクティブ" になり、メッセージを受け取ります (既存の名前空間の場合もあれば、新しい名前空間の場合もあります)。 セカンダリ名前空間は "パッシブ" で、メッセージを受け取りません。 両者間のメタデータは同期しているため、どちらでもアプリケーション コードや接続文字列を変更せずにメッセージをシームレスに受信できます。 確実にアクティブな名前空間にだけメッセージを送信するためには、エイリアスを使用する必要があります。

• Metadata:名前空間に関連付けられているサービスのエンティティ (キュー、トピック、サブスクリプションなど) とそのプロパティです。 自動的にレプリケートされるのはエンティティとその設定だけです。 メッセージはレプリケートされません。

• フェールオーバー:セカンダリの名前空間をアクティブ化するプロセスです。

セットアップ

次のセクションは、名前空間同士のペアリングの設定の概要です。

まず (新規作成または既存の) プライマリ名前空間と新しいセカンダリ名前空間をペアリングします。 このペアリングによって、接続に使用できる別名が決定されます。 別名を使用するので、接続文字列を変更する必要はありません。 フェールオーバーのペアリングに追加できるのは、新しい名前空間だけです。

1. プライマリ Premium レベルの名前空間を作成します。

2. 別のリージョンに Premium レベルのセカンダリ名前空間を作成します。 この手順は省略可能です。 セカンダリ名前空間は、次の手順でペアリングを作成しているときに作成できます。

3. Azure portal で、プライマリ名前空間に移動します。

4. 左側のメニューの [geo リカバリー] を選択し、ツールバーの [ペアリングの開始] を選択します。

   

5. [ペアリングの開始] ページで、次の手順に従います。

   1. 既存のセカンダリ名前空間を選択するか、別のリージョンで新規作成します。 この例では、既存の名前空間がセカンダリ名前空間として使用されています。

   2. [エイリアス] には、geo ディザスター リカバリー ペアリングのエイリアスを入力します。

   3. そのうえで [Create](作成) を選択します。

      

6. 次の図に示すように、 [Service Bus Geo DR のエイリアス] ページが表示されます。 左側のメニューで [geo リカバリー] を選択して、[プライマリ名前空間] ページから [geo DR のエイリアス] ページに移動することもできます。

   

7. [Geo DR のエイリアス] ページの左側のメニューで [共有アクセス ポリシー] を選択して、エイリアスのプライマリ接続文字列にアクセスします。 この接続文字列は、プライマリまたはセカンダリ名前空間への接続文字列を直接使用する代わりに使用します。 最初、エイリアスは、プライマリ名前空間を指しています。

8. [概要] ページに切り替えます。 次のアクションを実行できます。

   1. プライマリ名前空間とセカンダリ名前空間の間のペアリングを解除する。 ツールバーの [ペアリングの解除] を選択します。
   2. セカンダリ名前空間に手動でフェールオーバーする。

      1. ツールバーの [フェールオーバー] を選択します。

      2. エイリアスを入力して、セカンダリ名前空間にフェールオーバーすることを確認します。

      3. [Safe Failover](安全なフェールオーバー) オプションをオンにして、セカンダリ名前空間に安全にフェールオーバーします。

         Note

         • この安全なフェールオーバーにより、セカンダリに切り替える前に、保留中の geo ディザスター リカバリー レプリケーションが確実に完了するようになります。 あるいは、強制または手動フェールオーバーで、保留中のレプリケーションの完了を待たずに、セカンダリに切り替えることができます。
         • 現在、プライマリとセカンダリ名前空間が同じ Azure サブスクリプションに存在しない場合、安全なフェールオーバーは失敗します。

      4. その後、 [フェールオーバー] を選択します。

         

         重要

         フェールオーバーによって、セカンダリ名前空間がアクティブにされ、geo ディザスター リカバリーのペアからプライマリ名前空間が削除されます。 新しい geo ディザスター リカバリーのペアを使用するには、別の名前空間を作成してください。

9. 最後に、フェールオーバーが必要であるかどうかを検出する監視機構を追加する必要があります。 ほとんどの場合、このサービスは大きなエコシステムの一部分であるため、自動フェールオーバーが実行できることはまれです。フェールオーバーは、他のサブシステムやインフラストラクチャと同期して実行しなければならないケースが多いためです。

Servce Bus Standard から Premium へ

Azure Service Bus Standard 名前空間を Azure Service Bus Premium に移行済みの場合、既存のエイリアス (つまり、Service Bus Standard 名前空間の接続文字列) を使用して、PS/CLI または REST API を介したディザスター リカバリー構成を作成する必要があります。

これは、移行中に、Azure Service Bus Standard 名前空間の接続文字列/DNS 名自体が Azure Service Bus Premium 名前空間のエイリアスになるためです。

クライアント アプリケーションでは、このエイリアス (つまり、Azure Service Bus Standard 名前空間の接続文字列) を利用して、ディザスター リカバリーのペアリングが設定されている Premium 名前空間に接続する必要があります。

Azure portal を使ってディザスター リカバリー構成を設定する場合、この注意点はポータルによって取り除かれます。

フェールオーバーの流れ

フェールオーバーはお客様によって (コマンドを使用して明示的に、またはコマンドをトリガーするビジネス ロジックを所有しているクライアントを通して) 手動でトリガーされ、Azure によってトリガーされることはありません。 これにより、Azure のバックボーン上での故障に対するソリューションの完全な所有権と可視性がお客様に付与されます。

フェールオーバーがトリガーされると:

1. "エイリアス" 接続文字列がセカンダリ Premium 名前空間を指すように更新されます。

2. クライアント (送信側と受信側) がセカンダリ名前空間に自動的に接続されます。

3. プライマリ Premium 名前空間とセカンダリ Premium 名前空間の間の既存のペアリングが解除されます。

フェールオーバーが開始されると:

1. 別の故障が発生した場合は、もう一度フェールオーバーしたいと考えます。 そのため、別のセカンダリ名前空間を設定して、ペアリングを更新します。

2. 以前のプライマリ名前空間が再び利用可能になったら、以前のプライマリ名前空間からメッセージをプルします。 以後、通常のメッセージングにその名前空間を geo ディザスター リカバリーのセットアップ外で使用するか、または、以前のプライマリ名前空間を削除します。

Note

サポートされるのは、フェール フォワードのセマンティクスだけです。 このシナリオでは、フェールオーバー後、新しい名前空間との間で再度ペアリングを行います。 フェールバックはサポートされません (SQL クラスターでの場合など)。

フェールオーバーは、監視システムを使用して自動化できるほか、独自に構築した監視ソリューションを使用して自動化することもできます。 ただしそのような自動化は、特別な計画と作業が伴い、この記事で取り上げる範囲を超えています。

管理

間違ったリージョンをペアリングしたなど、初期設定にミスがあった場合、2 つの名前空間のペアリングはいつでも解除することができます。 ペアリングした名前空間を通常の名前空間として使用する必要がある場合、エイリアスは削除してください。

既存の名前空間をエイリアスとして使用する

プロデューサーとコンシューマーの接続を変更できないシナリオでは、お使いの名前空間名をエイリアス名として再利用することができます。 こちらで GitHub のサンプル コードをご覧ください。

サンプル

GitHub のサンプルには、フェールオーバーの設定と開始の方法が紹介されています。 サンプルで紹介されている概念は次のとおりです。

• Azure Resource Manager と Service Bus を使用して geo ディザスター リカバリーを設定し、有効にするために Microsoft Entra ID で必要となる .NET のサンプルと設定。
• サンプル コードを実行するために必要な手順。
• 既存の名前空間をエイリアスとして使用する方法。
• 代替方法として PowerShell または CLI から geo ディザスター リカバリーを有効にするための手順。
• エイリアスを利用し、現在のプライマリまたはセカンダリ名前空間との間で行う送受信。

考慮事項

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

• フェールオーバー計画では、時間的要因も考慮する必要があります。 たとえば、接続の喪失時間が 15 ～ 20 分を超えた場合にフェールオーバー開始の判断を下すことが考えられます。
• レプリケートされるデータが存在しないということは、現在アクティブなセッションがレプリケートされないことを意味します。 また、重複の検出やスケジュールされたメッセージが正しく機能しない可能性があります。 新しいセッション、新しくスケジュールされたメッセージ、新しい重複については機能します。
• 複雑な分散インフラストラクチャのフェールオーバーは、少なくとも 1 回はリハーサルを行うようお勧めします。
• エンティティの同期には、ある程度時間がかかる場合があります (1 分あたり約 50 ～ 100 エンティティ)。 サブスクリプションやルールもエンティティとしてカウントされます。

プライベート エンドポイント

このセクションでは、プライベート エンドポイントを使用する名前空間で geo ディザスター リカバリーを使用する場合のその他の考慮事項について説明します。 Service Bus 全般でのプライベート エンドポイントの使用については、Azure Service Bus と Azure Private Link との統合に関する記事を参照してください。

新しいペアリング

プライベート エンドポイントがあるプライマリ名前空間と、プライベート エンドポイントがないセカンダリ名前空間とのペアリングを作成しようとすると、ペアリングは失敗します。 ペアリングは、プライマリとセカンダリの両方の名前空間にプライベート エンドポイントがある場合にのみ成功します。 プライマリおよびセカンダリ名前空間と、プライベート エンドポイントが作成される仮想ネットワークで同じ構成を使用することをお勧めします。

Note

プライベート エンドポイントがあるプライマリ名前空間と任意のセカンダリ名前空間を組み合わせようとすると、検証プロセスで、セカンダリ名前空間にプライベート エンドポイントが存在するかどうかのみが確認されます。 エンドポイントが機能しているかどうか、またはフェールオーバー後に機能するかどうかは、チェックされません。 プライベート エンドポイントがあるセカンダリ名前空間が、フェールオーバー後に想定どおりに機能することは、ユーザーが確認する必要があります。

プライベート エンドポイント構成が同じであることをテストするには、仮想ネットワークの外部からセカンダリ名前空間にキューの取得要求を送信し、サービスからエラー メッセージを受信したことを確認します。

既存のペアリング

プライマリ名前空間とセカンダリ名前空間のペアリングが既に存在する場合、プライマリ名前空間でのプライベート エンドポイントの作成は失敗します。 解決するには、まずセカンダリ名前空間にプライベート エンドポイントを作成し、次にプライマリ名前空間用に作成します。

Note

セカンダリ名前空間に対して許可されるのは読み取り専用アクセスですが、プライベート エンドポイント構成の更新は許可されます。

推奨される構成

アプリケーションと Service Bus のディザスター リカバリー構成を作成する場合は、アプリケーションのプライマリ インスタンスとセカンダリ インスタンスの両方をホストする仮想ネットワークに対して、プライマリとセカンダリの両方の Service Bus 名前空間にプライベート エンドポイントを作成する必要があります。

たとえば、2 つの仮想ネットワーク VNET-1 と VNET-2、およびプライマリとセカンダリの名前空間 ServiceBus-Namespace1-Primary と ServiceBus-Namespace2-Secondary があるとします。 次の手順を実行する必要があります。

• ServiceBus-Namespace1-Primary で、VNET-1 と VNET-2 からのサブネットを使う 2 つのプライベート エンドポイントを作成します
• ServiceBus-Namespace2-Secondary で、VNET-1 と VNET-2 からの同じサブネットを使う 2 つのプライベート エンドポイントを作成します

このアプローチの利点は、Service Bus 名前空間から独立したアプリケーション レイヤーでフェールオーバーが発生するようにできることです。 以下のようなシナリオが考えられます。

アプリケーションのみのフェールオーバー: この場合、アプリケーションは VNET-1 には存在せず、VNET 2 に移動します。 VNET-1 と VNET 2 の両方で、プライマリとセカンダリの両方の名前空間に対して両方のプライベート エンドポイントが構成されているため、アプリケーションは動作します。

Service Bus 名前空間のみのフェールオーバー: この場合も、プライマリとセカンダリの両方の名前空間に対して、両方の仮想ネットワークで両方のプライベート エンドポイントが構成されているため、アプリケーションは動作します。

Note

仮想ネットワークの geo ディザスター リカバリーに関するガイダンスについては、「Virtual Network - ビジネス継続性」を参照してください。

ロールベースのアクセス制御

Microsoft Entra ロールベースのアクセス制御 (RBAC) によるプライマリ名前空間内の Service Bus エンティティへの割り当ては、セカンダリ名前空間にレプリケートされません。 セカンダリ名前空間にロールの割り当てを手動で作成して、アクセスをセキュリティで保護します。

次のステップ

• geo ディザスター リカバリーの REST API リファレンスを確認する。
• geo ディザスター リカバリーの GitHub のサンプルを実行する。
• geo ディザスター リカバリーのエイリアスにメッセージを送信するサンプルを確認する。

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

• Service Bus のキュー、トピック、サブスクリプション
• Service Bus キューの使用
• Service Bus のトピックとサブスクリプションの使用方法
• REST API