Azure Service Bus は、アプリケーションとサービスを分離するための信頼性の高い非同期メッセージング機能を提供する、フル マネージドのエンタープライズ メッセージ ブローカー サービスです。 Service Bus では、ポイントツーポイント通信のキューと、パブリッシュ/サブスクライブ メッセージング パターンのサブスクリプションを含むトピックがサポートされています。 このサービスには、メッセージの持続性、少なくとも 1 回の配信保証、失敗したメッセージ処理を処理するための配信不能キューなどの組み込みの信頼性機能が用意されています。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな障害や問題に対する Service Bus の回復性を確保する方法について説明します。 また、Service Bus サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。
運用環境のデプロイに関する推奨事項
Azure Well-Architected Framework では、信頼性、パフォーマンス、セキュリティ、コスト、運用に関する推奨事項が提供されます。 これらの領域が互いに及ぼす影響を理解し、信頼性の高い App Service ソリューションに貢献するには、 Azure Well-Architected Framework での Azure Service Bus のアーキテクチャのベスト プラクティスに関するページを参照してください。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
名前空間は Service Bus の管理コンテナーとして機能し、Basic、Standard、または Premium レベルを使用するように構成できます。 名前空間レベルでサービスを構成するには、容量の割り当て、ネットワーク セキュリティの構成、Geo-Replication と Geo-Disaster Recovery の有効化を行います。
名前空間内では、異なるセマンティクスを持つメッセージング エンティティである キュー と トピックをデプロイします。 詳細については、「 Service Bus キュー、トピック、サブスクリプション」を参照してください。
必要に応じて、複数のメッセージ ブローカーとメッセージング ストアにキューとトピックを分散させる、名前空間に パーティション を構成できます。 名前空間では、複数のパーティションを使用して並列処理と水平方向のスケーリングを実行できます。 Service Bus では、1 つのパーティション内での順序付けのみが保証されます。 パーティション分割は、アプリケーションの信頼性設計において重要な役割を果たします。 アプリケーションを設計するときは、可用性と整合性を最大化する間のトレードオフを行います。 Premium レベルでは、 名前空間でパーティション分割を有効にします。 Basic レベルと Standard レベルの名前空間の場合は、エンティティにパーティションを構成し、 必要に応じてメッセージを送信するときに構成します。
Service Bus とその非同期設計アプローチを使用して、アプリケーションの可用性を高めることができます。 詳細については、「 非同期メッセージング パターンと高可用性」を参照してください。
物理アーキテクチャ
Service Bus は、基になるコンピューティング リソースとストレージ リソースを提供します。 名前空間ごとに、複数 のメッセージ ブローカーが メッセージを処理し、複数 のメッセージング ストア にメッセージが格納されます。 メッセージング ストアには、プライマリとセカンダリの 3 つのコピーがあります。 Service Bus では、データ操作および管理操作のために 3 つのコピーをすべて同期します。 プライマリ コピーがフェイルした場合には、セカンダリ コピーの 1つをプライマリに昇格させ、ダウンタイムを発生させません。
Basic レベルまたは Standard レベルを使用する名前空間の場合、Service Bus は共有マルチテナント インフラストラクチャを通じて冗長性を提供し、使用可能な場合は可用性ゾーン間でメッセージを自動的にレプリケートします。 このサービスでは、複数のメッセージング ストアが保持され、データ操作と管理操作の両方についてすべてのコピーが同期されます。
Premium レベルの名前空間の場合、Service Bus には専用のメッセージング ユニットが用意されており、それぞれに専用の CPU リソースとメモリ リソースが用意されています。 Premium レベルの名前空間は、ワークロードの需要に基づいて自動的にスケーリングできます。 詳細については、「 Azure Service Bus 名前空間のメッセージング ユニットを自動的に更新する」を参照してください。
Service Bus インフラストラクチャは、障害ドメイン間に分散された複数の物理マシンとラックにまたがるため、名前空間に影響を与える致命的な障害のリスクが軽減されます。 可用性ゾーンがあるリージョンでは、インフラストラクチャは別々の 物理データセンターにまたがっています。 このサービスは、透過的な障害検出とフェールオーバー メカニズムを実装して、保証されたサービス レベル内で動作し続け、通常はそのような障害が発生したときに顕著な中断を発生させずに動作します。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Azure Service Bus SDK には、ネットワーク タイムアウトや一時的なサービス利用不可などの一時的な状態のために失敗する操作に対する指数バックオフを含む自動再試行ロジックが含まれています。 アプリケーションで Service Bus からの一時的な切断が発生すると、SDK は構成された再試行ポリシーを使用して自動的に再接続を試みます。
アプリケーションで一時的な障害処理を最適化するには、最新の再試行ロジックと接続管理機能を含む最新の Service Bus SDK を使用します。 詳細については、「 .NET 用 Azure Service Bus クライアント ライブラリ」を参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Service Bus では、すべてのサービス レベルでゾーン冗長デプロイがサポートされています。 サポートされているリージョンに Service Bus 名前空間を作成すると、ゾーンの冗長性が追加コストなしで自動的に有効になります。 ゾーン冗長デプロイ モデルは、パーティション分割やセッションを含むすべての Service Bus 機能に適用されます。
Service Bus は、構成、メタデータ、メッセージ データをリージョン内の複数の可用性ゾーンに透過的にレプリケートします。 ゾーン冗長により、ユーザーの介入を必要とせずに自動フェールオーバーが提供されます。 コンピューティング、ネットワーク、ストレージを含むすべての Service Bus コンポーネントは、ゾーン間でレプリケートされます。 Service Bus には、ゾーンの完全な損失を即座に処理するための十分な容量予約があります。 可用性ゾーン全体が使用できなくなった場合でも、Service Bus はデータの損失やメッセージング アプリケーションの中断なしに動作し続けます。
Requirements
リージョンのサポート: ゾーン冗長 Service Bus 名前空間は、 可用性ゾーンのサポートを使用して Azure リージョンにデプロイできます。 Service Bus では、サポートされているリージョンに名前空間を作成するときに、追加の構成を必要とせず、可用性ゾーンのサポートが自動的に有効になります。
層： すべての Service Bus レベル (Basic、Standard、Premium) では、追加の要件なしで可用性ゾーンがサポートされます。
考慮事項
Service Bus 名前空間には、 zoneRedundant プロパティが含まれます。 以前は、可用性ゾーンを有効にするためにこのプロパティが必要でしたが、この動作は変更されており、 zoneRedundant プロパティは非推奨になっています。 このプロパティは、ゾーン冗長が有効になっている場合でも、 false として表示される場合があります。 可用性ゾーンを持つリージョン内のすべての名前空間はゾーン冗長です。
費用
Service Bus のゾーン冗長では、追加コストは発生しません。
可用性ゾーンのサポートを設定する
Service Bus 名前空間は、サポートされているリージョンにデプロイされると、ゾーンの冗長性 を自動的にサポートします。 それ以上の構成は必要ありません。
すべてのゾーンが正常な場合の動作
このセクションでは、Service Bus 名前空間がゾーン冗長用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング。 Service Bus はアクティブ/アクティブ モデルを使用します。このモデルでは、メッセージが複数の可用性ゾーンに分散されます。 クライアント接続はゾーン間で自動的に負荷分散され、サービスはゾーンに関係なく、使用可能なメッセージング インフラストラクチャに操作をルーティングします。
ゾーン間のデータ レプリケーション。 Service Bus では、メタデータやメッセージ データなど、可用性ゾーン間の同期レプリケーションが使用されます。 メッセージング ストアの複数のコピーは、書き込み操作が完了したと見なされる前に確認する必要があり、通常の操作中にゾーン間でデータの一貫性が確保されます。
ゾーン障害時の動作
このセクションでは、Service Bus 名前空間がゾーン冗長用に構成されていて、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
- 検出と応答: Microsoft はゾーンの障害を自動的に検出し、正常なゾーンへのフェールオーバーを開始します。 ゾーン レベルのフェールオーバーでは、顧客の操作は必要ありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: ゾーンの障害時に、Service Bus によってアクティブな要求が削除される場合があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。
予期されるデータ損失: Service Bus は受信確認の前に複数のゾーンにメッセージを同期的にレプリケートするため、ゾーン障害時にデータ損失は発生しません。
予期されるダウンタイム: ゾーンの障害により、数秒のダウンタイムが発生する可能性があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。
トラフィックの再ルーティング: Service Bus はゾーンの損失を検出し、正常な可用性ゾーンの 1 つにある別のレプリカに新しい要求を自動的にリダイレクトします。
Service Bus SDK は、通常、接続管理と再試行ロジックを透過的に処理します。
ゾーンの回復
可用性ゾーンが復旧すると、Service Bus はゾーンをアクティブなサービス トポロジに自動的に再統合します。 回復されたゾーンは、新しい接続の受け入れと、他のゾーンと共にメッセージの処理を開始します。 停止中に存続中のゾーンにレプリケートされたデータはそのまま残り、通常の同期レプリケーションはすべてのゾーンで再開されます。 ゾーンの回復と再統合に対してアクションを実行する必要はありません。
ゾーンエラーのテスト
Service Bus は、ゾーン障害のトラフィック ルーティング、フェールオーバー、ゾーン回復を管理するため、可用性ゾーンの障害プロセスを検証したり、さらに入力を提供したりする必要はありません。
リージョン全体の障害に対する回復性
Service Bus には 2 種類のマルチリージョン サポートが用意されており、どちらも Premium レベルの名前空間が必要です。
geo レプリケーション では、プライマリ リージョンとセカンダリ リージョンの間でメタデータとメッセージ データの両方のアクティブ/パッシブ レプリケーションが提供されます。 リージョンの障害に対する回復性を維持する必要があり、メッセージ データの損失に対する許容度が低いほとんどのアプリケーションには、Geo-Replication を使用します。
メタデータ Geo-Disaster Recovery では、プライマリ リージョンとセカンダリ リージョン間の構成とメタデータのアクティブ/パッシブ レプリケーションが提供されますが、メッセージ データはレプリケートされません。 独自のデータ レプリケーションを処理するアプリケーション、またはデータ レプリケーションを必要としないアプリケーションには、Geo-Disaster Recovery を使用することを検討してください。
Geo-Replication とメタデータ Geo-Disaster Recovery の両方で、セカンダリ リージョンのフェールオーバーまたは昇格を手動で開始して新しいプライマリ リージョンにする必要があります。 プライマリ リージョンがダウンしている場合でも、Microsoft はフェールオーバーや昇格を自動的に実行しません。
Basic レベルと Standard レベルの名前空間にはネイティブマルチリージョン機能は含まれませんが、リージョン間で複数の名前空間を使用してアプリケーション レベルのレプリケーション パターンを実装できます。 詳細については、以下の 「回復性のためのカスタム マルチリージョン ソリューション 」セクションを参照してください。
Geo-Replication
プレミアム層ではジオレプリケーションがサポートされます。 この機能は、名前空間のメタデータ (エンティティ、構成、プロパティなど) とデータ (キューやトピック内のメッセージ、メッセージのプロパティと状態など) の両方をレプリケートします。 名前空間の構成とデータのレプリケーション アプローチを構成します。 この機能により、メッセージは別のリージョンで使用でき、必要に応じてセカンダリ リージョンに切り替えることができます。
Geo-Replication は、リージョンの障害に対する回復性を必要とし、メッセージ データの損失に対する許容度が低いシナリオに使用します。
名前空間は基本的にリージョン間で拡張されます。 1 つのリージョンがプライマリとして機能し、もう 1 つのリージョンがセカンダリとして機能します。 Azure サブスクリプションに 1 つの名前空間が表示されます。
セカンダリ リージョンはいつでもプライマリ リージョンに 昇格 できます。 セカンダリ リージョンを昇格すると、Service Bus は、名前空間の完全修飾ドメイン名 (FQDN) を選択したセカンダリ リージョンに再ポイントし、前のプライマリ リージョンをセカンダリ リージョンに降格します。 計画的な昇格を実行するかどうかを決定します。つまり、データ レプリケーションが完了するまで待機するか、強制昇格を実行するとデータが失われる可能性があります。
注
Service Bus Geo-Replication は、昇格という用語を使用します。これは、セカンダリ リージョンをプライマリ リージョンに昇格させるプロセス（後にプライマリ リージョンをセカンダリ リージョンに降格させるプロセス）を最もよく表しているためです。 また、一般的なプロセスを説明するために使用される フェールオーバー という用語が表示される場合もあります。
このセクションでは、geo レプリケーションの重要な側面をまとめます。 完全なドキュメントを確認して、そのしくみを正確に理解してください。 詳細については、「サービス バス 地理的レプリケーション」を参照してください。
Requirements
リージョンのサポート: Service Bus をサポートする任意の Azure リージョンをプライマリ リージョンまたはセカンダリ リージョンとして選択できます。 Azure のペアになっているリージョンを使用する必要がないため、待機時間、コンプライアンス、またはデータ所在地の要件に基づいてセカンダリ リージョンを選択できます。
層： geo レプリケーションを有効にするには、名前空間で Premium レベルを使用する必要があります。
メタデータ Geo-ディザスタ リカバリ: Geo-Replication と Geo-ディザスタ リカバリ の両方を使用するように名前空間を構成することはできません。
考慮事項
機能の制限事項: geo レプリケーションを有効にすると、いくつかの制限があります。 詳細については、「サービス バス 地理的レプリケーション」を参照してください。
プライベート エンドポイント: プライベート エンドポイントを使用して名前空間に接続する場合は、プライマリ リージョンとセカンダリ リージョンでネットワークを構成する必要もあります。 詳細については、Azure Event Hubs ドキュメントの プライベート エンドポイント を参照してください。
費用
ジオレプリケーションの価格の仕組みについては、価格 を参照してください。
複数リージョンのサポートを構成する
新しい名前空間で Geo-Replication を有効にします。 作成時に名前空間で Geo-Replication を有効にするには、「 レプリケーション モードの切り替え」を参照してください。
メタデータ geo ディザスター リカバリーから geo レプリケーションに移行します。メタデータ geo ディザスター リカバリーの使用から geo レプリケーションに切り替えることができます。
レプリケーションの方法を変更します。 同期レプリケーション モードと非同期レプリケーション モードを変更するには、「 レプリケーション モードの切り替え」を参照してください。
Geoレプリケーションを無効にします。 セカンダリ リージョンへの Geo-Replication を無効にするには、「セカンダリ リージョンの 削除」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、Service Bus 名前空間が geo レプリケーション用に構成されていて、プライマリ リージョンが動作している場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: クライアント アプリケーションは、名前空間の FQDN を介して接続し、そのトラフィックがプライマリ リージョンにルーティングされます。
通常の操作中にクライアントからのメッセージをアクティブに処理するのは、プライマリ リージョンだけです。 セカンダリ リージョンはレプリケートされたメッセージを受信しますが、それ以外の場合はスタンバイ モードでパッシブのままです。
リージョン間のデータ レプリケーション: プライマリ リージョンとセカンダリ リージョン間のデータ レプリケーション動作は、同期レプリケーションと非同期レプリケーションのどちらを使用するようにレプリケーション ペアリングを構成するかによって異なります。
同期： メッセージは、書き込み操作が完了する前にセカンダリ リージョンにレプリケートされます。
このモードでは、プライマリ リージョンとセカンダリ リージョンでコミットする必要があるため、メッセージ データが安全であることを保証します。 ただし、同期レプリケーションでは、受信メッセージの書き込み待機時間が大幅に増加します。 また、セカンダリ リージョンが書き込み操作を受け入れるために使用できる必要があるため、セカンダリ リージョンで障害が発生すると、書き込み操作が失敗します。
- 非同期： メッセージはプライマリ リージョンに書き込まれ、書き込み操作が完了します。 しばらくすると、セカンダリ リージョンにメッセージがレプリケートされます。
このモードでは、書き込み操作中にリージョン間レプリケーションの待機時間がないため、同期レプリケーションよりも書き込みスループットが高くなります。 また、非同期レプリケーション モードでは、プライマリ リージョンでの書き込み操作を引き続き許可しながら、セカンダリ リージョンの損失を許容できます。 ただし、プライマリ リージョンで障害が発生した場合、セカンダリ リージョンにまだレプリケートされていないデータは使用できないか失われる可能性があります。
非同期レプリケーションを構成するときは、レプリケーションに許容される最大ラグ タイムを構成します。 Azure Monitor メトリックを使用して、いつでも現在のレプリケーションのラグを確認できます。
非同期レプリケーションのラグが指定した最大値を超えて増加した場合、プライマリ リージョンは、レプリケーションが追いつくことができるように、受信要求の調整を開始します。 このような状況を回避するには、地理的に離れていないセカンダリ リージョンを選択し、スループットに十分な容量を確保することが重要です。
一部のメタデータの種類は、非同期レプリケーション モードを選択した場合でも同期的にレプリケートされます。
詳細については、「 レプリケーション モード」を参照してください。
リージョン障害時の動作
このセクションでは、Service Bus 名前空間が Geo-Replication 用に構成されていて、プライマリ リージョンまたはセカンダリ リージョンで障害が発生した場合に想定される内容について説明します。
検出と応答: 名前空間のセカンダリ リージョンを新しいプライマリ リージョンに昇格させるタイミングを決定する必要があります。 Microsoft は、リージョンの停止が発生した場合でも、この決定を行ったり、プロセスを開始したりすることはありません。 フェールオーバーするかどうかを決定する際に考慮すべき推奨条件については、「 昇格をトリガーするための推奨シナリオ」を参照してください。
セカンダリ リージョンを新しいプライマリに昇格する方法の詳細については、「 昇格フロー」を参照してください。
セカンダリ リージョンを昇格する場合は、 計画的な昇格 と 強制昇格のどちらを実行するかを選択します。 計画された昇格は、セカンダリ リージョンが追いつくのを待ってから、新しいトラフィックを受け入れます。 この方法では、データ損失は排除されますが、ダウンタイムが発生します。
プライマリ リージョンでの停止中は、通常、強制昇格を実行する必要があります。 プライマリ リージョンが利用可能で、別の理由でプロモーションをトリガーする場合は、計画的なプロモーションを選択できます。
- 通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: 動作は、リージョンの停止がプライマリ リージョンとセカンダリ リージョンのどちらで発生するかによって異なります。
プライマリ リージョンの停止: プライマリ リージョンが使用できない場合、すべてのアクティブな要求が終了します。 クライアント アプリケーションは、昇格の完了後に操作を再試行する必要があります。
セカンダリ リージョンの停止: セカンダリ リージョンで障害が発生すると、次の状況でアクティブな要求に問題が発生する可能性があります。
同期レプリケーション モードを使用する場合、セカンダリ リージョンが使用できない場合、プライマリ リージョンは書き込み操作を完了できません。
非同期レプリケーション モードを使用する場合、レプリケーションのラグが構成した最大値に達した後、名前空間が調整され、新しいメッセージは受け入れられません。
プライマリ リージョンで名前空間を引き続き使用するには、Geo-Replication 構成からセカンダリ名前空間を削除します。
予想されるデータ損失: データ損失の量は、実行する昇格の種類 (計画または強制) とレプリケーション モード (同期または非同期) によって異なります。
計画された昇格: データ損失は予想されません。 ただし、リージョンの停止中は、すべてのプライマリ リージョンとセカンダリ リージョンを使用できるようにする必要があるため、計画的な昇格が不可能な場合があります。
強制昇格、同期レプリケーション: データ損失は予想されません。
強制昇格、非同期レプリケーション: セカンダリ リージョンにレプリケートされていない最近のメッセージや、まだレプリケートされていない状態の変更に対して、データ損失が発生する可能性があります。 この量は、レプリケーションのラグによって異なります。 現在のレプリケーションのラグを確認するには、 Azure Monitor メトリックを使用します。
強制昇格を実行した場合、プライマリ リージョンが使用可能になった後でも、失われたデータを回復することはできません。
予想されるダウンタイム: 予想されるダウンタイムの量は、計画的な昇格と強制昇格のどちらを実行するかによって異なります。
計画された昇格: 計画された昇格の最初の手順では、セカンダリ リージョンにデータがレプリケートされます。 通常、このプロセスはすぐに完了しますが、状況によっては、レプリケーションのラグの長さまでかかる場合があります。 レプリケーションが完了すると、通常、昇格プロセスには約 5 ~ 10 分かかります。 ドメイン ネーム システム (DNS) サーバーがエントリを更新し、レコードをクライアントに完全にレプリケートするのに時間がかかる場合があります。
プライマリ リージョンでは、昇格プロセス全体で書き込み操作を受け入れられません。
このオプションは、すべてのプライマリ リージョンとセカンダリ リージョンを使用できるようにする必要があるため、リージョンの停止中に使用できない場合があります。
強制昇格: 強制昇格中、Service Bus はデータ レプリケーションの完了を待機せず、昇格を直ちに開始します。 通常、昇格プロセスには約 5 ~ 10 分かかります。 DNS エントリが完全にレプリケートされ、クライアント間で更新されるまでに時間がかかる場合があります。
プライマリ リージョンでは、昇格プロセス全体で書き込み操作を受け入れられません。
トラフィックの再ルーティング: 昇格が完了すると、名前空間の FQDN は新しいプライマリ リージョンを指します。 ただし、このリダイレクトは、DNS サーバーが名前空間 DNS レコードの Time to Live (TTL) を尊重するなど、クライアントの DNS レコードが更新される速度によって異なります。
リージョンの復旧
元のプライマリ リージョンが復旧した後、名前空間を元のプライマリ リージョンに返す場合は、同じリージョンの昇格プロセスに従います。
リージョンの停止中に強制昇格を実行した場合、プライマリ リージョンが使用可能になった後でも、失われたデータを回復することはできません。
リージョン障害のテスト
geo レプリケーションをテストするには、セカンダリ リージョンを一時的にプライマリに昇格させ、クライアント アプリケーションが中断を最小限に抑えてリージョンを切り替えることができることを検証します。
昇格期間を監視し、Runbook と自動化が正しく機能することを検証します。 テスト後、元の構成にフェールバックできます。
昇格プロセス中および昇格後に発生する可能性のあるダウンタイムとデータ損失の可能性について理解します。 運用名前空間の構成を反映する非運用環境で Geo-Replication をテストします。
メタデータ 地理的災害復旧
Premium レベルでは、Geo-Disaster Recovery メタデータをサポートします。 この機能により、リージョンの致命的な損失など、ディザスター シナリオからの復旧が向上します。 Geo-Disaster Recovery では、名前空間の構成とメタデータのみがレプリケートされます。 ただし、メッセージ データはレプリケートされません。 ディザスター リカバリーをサポートするために、この機能により、別のリージョンの名前空間が事前に構成され、クライアントからのメッセージをすぐに受け入れる準備が整います。 Geo-Disaster Recovery は一方向の復旧ソリューションとして機能し、以前のプライマリ リージョンへのフェールバックをサポートしていません。
メタデータ Geo-Disaster 回復は、すべてのメッセージを厳密に維持する必要がなく、障害シナリオ中にデータ損失を許容できるアプリケーションに最適です。 メタデータのGeo-Disasterリカバリーは、データをそれ自体でレプリケートするアプリケーションや、まったくデータ レプリケーションを必要としないアプリケーションにも適している場合があります。 たとえば、後でサムネイルに変換した大きな画像をメッセージが表している場合、別のリージョンで新しいメッセージの処理をすばやく再開でき、後でメッセージを再構築して追いつくことができる場合は、障害が発生したリージョンから一部のメッセージを失う余裕があると判断できます。
Important
Geo-Disaster Recovery を使用すると、同じ構成で メッセージ データをレプリケートしない操作の継続性を実現できます。 メッセージ データをレプリケートする必要がある場合は、 geo レプリケーションの使用を検討してください。
Geo-Disaster Recovery メタデータを構成する際に、クライアント アプリケーションが接続する エイリアス を作成します。 エイリアスは、すべてのトラフィックを既定でプライマリ名前空間に転送する FQDN です。
プライマリ リージョンで障害が発生した場合、または別の種類の障害が発生した場合は、プライマリ リージョンからセカンダリ リージョンへの単一の一方向フェールオーバーの移動をいつでも手動で開始できます。 リージョンの停止中にこのオプションを使用できない場合がありますが、セカンダリに切り替える前にレプリケーションが完了するまで待機する 安全なフェールオーバーを実行することもできます。 フェールオーバーが開始されると、ほぼ瞬時に完了します。 フェールオーバー プロセス中に、Geo-Disaster Recovery エイリアスがセカンダリ名前空間に再ポイントされ、ペアリングが削除されます。
このセクションでは、Geo-Disaster Recovery の重要な側面をまとめています。 完全なドキュメントを確認して、そのしくみを正確に理解してください。 詳細については、「 Service Bus Geo-Disaster Recovery」を参照してください。
Requirements
リージョンのサポート: Service Bus をサポートする任意の Azure リージョンをプライマリ名前空間またはセカンダリ名前空間として選択できます。 Azure のペアになっているリージョンを使用する必要がないため、待機時間、コンプライアンス、またはデータ所在地の要件に基づいてセカンダリ リージョンを選択できます。
層： メタデータ Geo-Disaster Recovery を有効にするには、両方の名前空間で Premium レベルを使用する必要があります。
パーティション 分割： パーティション分割された名前空間と、分割されていない名前空間をペアにすることはできません。
メタデータ Geo-ディザスタ リカバリ: Geo-Replication と Geo-ディザスタ リカバリ の両方を使用するように名前空間を構成することはできません。
考慮事項
機能の制限事項: Geo-Disaster 回復を有効にすると、いくつかの制限があります。 詳細については、 考慮すべき重要な点 と 考慮事項を参照してください。
ロールの割り当て: プライマリ名前空間のエンティティに対する Microsoft Entra ロールベースのアクセス制御 (RBAC) の割り当ては、セカンダリ名前空間にレプリケートされません。 セカンダリ名前空間にロールの割り当てを手動で作成して、アクセスをセキュリティで保護します。
アプリケーションの設計: Geo-Disaster Recovery では、クライアント アプリケーションを設計するときに特定の考慮事項が必要です。 詳細については、「考慮事項」を参照してください。
プライベート エンドポイント: プライベート エンドポイントを使用して名前空間に接続する場合は、プライマリ リージョンとセカンダリ リージョンの両方でネットワークを構成します。 詳細については、プライベート エンドポイントに関する記事を参照してください。
Standard から Premium に移行された名前空間: 名前空間が以前に Standard レベルにあり、Premium レベルに移行した場合は、エイリアスを異なる方法で処理する必要があります。 詳細については、「 Service Bus Standard から Premium」を参照してください。
費用
メタデータ Geo-Disaster Recovery を有効にすると、プライマリ名前空間とセカンダリ名前空間の両方に対して料金が発生します。
複数リージョンのサポートを構成する
Geo-Disaster Recovery メタデータペアリングを作成します。 プライマリ名前空間とセカンダリ名前空間の間でディザスター リカバリーを構成するには、 セットアップとフェールオーバー のフローに関する記事を参照してください。
メタデータのジオディザスタリカバリーを無効化します。 名前空間間のペアリングを解除するには、 セットアップとフェールオーバー フローに関する記事を参照してください。
容量の計画と管理
複数リージョンのデプロイを計画する場合は、1 つのリージョンで障害が発生した場合に、両方のリージョンで完全な負荷を処理するための十分な容量があることを確認します。 セカンダリ リージョンは、通常の操作中はパッシブなままですが、フェールオーバー後すぐにトラフィックを処理する必要があります。 セカンダリ名前空間の容量をスケーリングして、運用トラフィックを遅延なく受信できるようにする方法を計画します。 フェールオーバー プロセス中に追加のダウンタイムを許容できる場合は、フェールオーバー中またはフェールオーバー後にセカンダリ名前空間の容量をスケーリングすることを選択できます。 ダウンタイムを減らすために、運用負荷を受け取る準備が整い続けるために、セカンダリ名前空間に容量を事前にプロビジョニングします。
すべてのリージョンが正常な場合の動作
このセクションでは、Service Bus 名前空間が Geo-Disaster Recovery 用に構成されていて、プライマリ リージョンが動作している場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: クライアント アプリケーションは、名前空間の Geo-Disaster Recovery エイリアスを介して接続し、そのトラフィックがプライマリ リージョンのプライマリ名前空間にルーティングされます。
通常の操作中にクライアントからのメッセージをアクティブに処理するのは、プライマリ名前空間だけです。 セカンダリ名前空間はスタンバイ モードでパッシブのままであり、データへのアクセス要求は失敗します。
リージョン間のデータ レプリケーション: 構成メタデータのみが名前空間間でレプリケートされます。 構成のレプリケーションは、継続的および非同期的に行われます。
すべてのメッセージ データはプライマリ名前空間にのみ残り、セカンダリ名前空間にはレプリケートされません。
リージョン障害時の動作
このセクションでは、Service Bus 名前空間が Geo-Disaster Recovery 用に構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
検出と応答: リージョンの正常性を監視し、フェールオーバーを手動で開始する必要があります。 プライマリ リージョンがダウンしている場合でも、Microsoft はフェールオーバーを実行したり、セカンダリ リージョンを自動的に昇格したりすることはありません。
フェールオーバーを開始する方法の詳細については、「フェールオーバー フロー」を参照してください。
フェールオーバーを開始するときに、 安全なフェールオーバー を実行するか、標準 (強制 フェールオーバーまたは 手動フェールオーバー) を実行するかを選択します。 安全なフェールオーバーは、フェールオーバーが開始される前に、セカンダリ リージョンへのレプリケーションが完了するまで待機します。 この方法では、メタデータの損失を減らすことができますが、ダウンタイムが発生します。 安全なフェールオーバーでは、名前空間が同じ Azure サブスクリプション内にある必要があります。
プライマリ リージョンで障害が発生した場合、通常は強制フェールオーバーを実行する必要があります。 プライマリ リージョンが使用可能で、別の理由でフェールオーバーをトリガーする場合は、計画されたフェールオーバーを選択できます。
フェールオーバーは一方向の操作であるため、後で Geo-Disaster Recovery のペアリングを再確立する必要があります。 詳細については、「 リージョンの復旧」を参照してください。
- 通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: 進行中のアクティブな要求は、フェールオーバーの開始時に終了します。 クライアント アプリケーションは、フェールオーバーの完了後に操作を再試行する必要があります。
予想されるデータ損失:
メタデータ: 通常、構成とメタデータはセカンダリ名前空間にレプリケートされます。 ただし、メタデータ レプリケーションは非同期的に行われるため、最近の変更はレプリケートされない可能性があります(特に複雑な変更)。 クライアントがアクセスする前に、セカンダリ名前空間の構成を確認します。
メッセージ データ: メッセージ データはリージョン間でレプリケートされません。 プライマリ リージョンがダウンすると、プライマリ名前空間内のメッセージは使用できなくなります。
致命的な災害によってプライマリ リージョンが完全に失われない限り、メッセージは完全に失われません。 リージョンが復旧した場合は、後でプライマリ名前空間からメッセージを取得できます。
予想されるダウンタイム: フェールオーバーは通常、5 ~ 10 分以内に発生します。 クライアントが DNS エントリを完全にレプリケートして更新するのに時間がかかる場合があります。
トラフィックの再ルーティング: Geo-Disaster Recovery エイリアスを使用して名前空間に接続するクライアントは、フェールオーバー後にセカンダリ名前空間に自動的にリダイレクトされます。 ただし、このリダイレクトは、名前空間 DNS レコードの TTL を受け取る DNS サーバーと、更新された DNS レコードを受信するクライアントに依存します。
リージョンの復旧
元のプライマリ リージョンが復旧したら、手動でペアリングを再確立し、必要に応じてフェールバックする必要があります。 復旧されたリージョンとセカンダリとして新しい Geo-Disaster Recovery ペアリングを作成し、元のリージョンに戻る場合は別のフェールオーバーを実行します。 このプロセスには、一時プライマリに送信されたメッセージのデータ損失の可能性があります。
障害によってプライマリ リージョン内のすべてのゾーンが失われると、データが回復不能になる可能性があります。 その他のシナリオでは、フェールオーバーが復旧可能になるまで、メッセージ データはプライマリ名前空間に残ります。 アクセスを復元した後、古いプライマリ名前空間から履歴メッセージを取得できます。 これらのメッセージを受信して処理するようにアプリケーションを構成する必要があります。 Microsoft では、セカンダリ リージョンに自動的に復元されることはありません。
リージョン障害のテスト
応答とディザスター リカバリープロセスをテストするには、メンテナンス期間中に計画されたフェールオーバーを実行します。 プライマリ名前空間からセカンダリ名前空間へのフェールオーバーを開始し、アプリケーションが新しいプライマリからのメッセージに接続して処理できることを確認します。
フェールオーバーの期間を監視し、Runbook と自動化が正しく動作することを検証します。 テスト後、元の構成にフェールバックできます。
フェールオーバー プロセス中およびフェールオーバープロセス後に発生する可能性のあるダウンタイムとデータ損失の可能性について理解します。 運用名前空間の構成を反映する非運用環境で、メタデータ Geo-Disaster Recovery をテストします。
回復性のためのカスタム マルチリージョン ソリューション
geo レプリケーションとメタデータの geo ディザスター リカバリーは、リージョンの停止やその他の問題に対する回復性を実現し、大半のワークロードに適しています。 ただし、次の状況ではニーズに合わない場合があります。
- カスタム レプリケーションまたは複数のアクティブなリージョンを同時に維持するための要件があります。
- これらの機能をサポートしていない Service Bus レベルを使用します。
Service Bus では、さまざまな種類のマルチリージョン サポートを実現するためのさまざまな設計パターンがあります。 多くのパターンでは、複数の名前空間をデプロイし、名前空間を適切に使用するようにアプリケーションを構成する必要があります。 詳細については、以下の記事をお読みください。
サービス メンテナンスに対する回復性
Service Bus は定期的なメンテナンスを実行します。 計画メンテナンス中に、名前空間は最新の更新プログラムを含む冗長ノードに移動されます。 この移動が行われると、クライアント SDK は名前空間で自動的に切断および再接続します。 通常、アップグレードは 30 秒以内に行われます。 メンテナンス期間中に発生する 一時的なネットワーク切断に備 えて、アプリケーションを準備することが重要です。
詳細については、 Azure Service Bus の Azure メンテナンス イベントに関するガイダンスを参照してください。
バックアップと復元
Service Bus は、データの長期的な保存場所として設計されていません。 通常、データはトピックまたはキューに短時間格納され、その後、別のデータ ストレージ システムに処理または永続化され、その時点で削除されます。 この設計により、Service Bus はメッセージ データのレプリカを自動的に維持しますが、メッセージ データのバックアップと復元の機能は提供しません。
メッセージの長期保持が必要なシナリオでは、Azure Storage またはその他の永続ストレージ サービスへのアプリケーション レベルのアーカイブの実装を検討してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
Service Bus では、すべての名前空間に対して SLA が提供されます。 名前空間が次のすべての条件を満たしている場合、可用性 SLA が高くなります。
- Premium レベルを使用します。
- 可用性ゾーンがあるリージョンにあります。
- パーティション分割を使用します。