Azure Event Hubs - geo ディザスター リカバリー
この記事では、一般公開されている、メタデータをレプリケートする geo ディザスター リカバリー機能について説明します。 データとメタデータの両方をレプリケートするパブリック プレビューの geo レプリケーション機能については扱いません。 詳細については、 geo レプリケーションに関するページを参照してください。
可用性ゾーンのサポートを備えた、すべてアクティブな Azure Event Hubs クラスター モデルにより、ハードウェアおよびデータセンターの停止に対する回復性が提供されます。 ただし、ある Azure リージョン全体とすべてのゾーンが使用できない障害の場合は、geo ディザスター リカバリーを使用してワークロードとアプリケーション構成を復旧できます。 geo ディザスター リカバリーにより、名前空間 (Event Hubs、コンシューマー グループ、設定) の構成全体が、ペアリングされた場合に、プライマリ名前空間からセカンダリ名前空間に継続的にレプリケートされることが保証されます。
Azure Event Hubs の geo ディザスター リカバリー機能はディザスター リカバリー ソリューションです。 この記事の中で説明する概念とワークフローは、一時的な停止ではなく、障害のシナリオに適用されます。 Microsoft Azure でのディザスター リカバリーの詳細については、こちらの記事をご覧ください。 geo ディザスター リカバリーを使用すると、プライマリからセカンダリへの 1 回限りのフェールオーバー移動をいつでも開始できます。 フェールオーバー移動により、その名前空間の選択したエイリアス名がセカンダリ名前空間を指します。 移動してから、そのペアリングは削除されます。 フェールオーバーは、開始されるとほぼ瞬時に完了します。
重要
- この機能を使用すると、同じ構成で操作を瞬時に継続できますが、イベント データはレプリケートされません。 災害によってすべてのゾーンが失われない限り、フェールオーバー後にプライマリ イベント ハブに保持されるイベント データが復旧可能になるので、アクセスが復元されるとそこから履歴イベントを取得できるようになります。 イベント データをレプリケートし、アクティブ/アクティブ構成内の対応する名前空間を操作して停止や災害に対処するには、この geo ディザスター リカバリー機能セットを使用せずに、レプリケーションのガイダンスに従ってください。
- プライマリ名前空間内のエンティティに対する Microsoft Entra ロールベースのアクセス制御 (RBAC) の割り当ては、セカンダリ名前空間にレプリケートされません。 セカンダリ名前空間にロールの割り当てを手動で作成して、アクセスをセキュリティで保護します。
基本的な概念と用語
ディザスター リカバリー機能は、メタデータの災害復旧を実装しており、一次および二次障害復旧の名前空間に依存しています。 geo ディザスター リカバリー機能は、Standard、Premium、Dedicated のレベルでのみ使用可能です。 別名を使用して接続を確立するので、接続文字列に変更を加える必要はありません。
この記事では、次の用語を使用します。
- エイリアス: 設定したディザスター リカバリー構成の名前です。 エイリアスは、1 つの不変の完全修飾ドメイン名 (FQDN) の接続文字列を示します。 アプリケーションでは、このエイリアスの接続文字列を使用して名前空間に接続します。
- プライマリ/セカンダリ名前空間: エイリアスに対応する名前空間です。 プライマリ名前空間がアクティブとなり、メッセージを受け取ります (既存の名前空間の場合もあれば、新しい名前空間の場合もあります)。 セカンダリ名前空間はパッシブで、メッセージを受け取りません。 両者間のメタデータは同期しているため、どちらでもアプリケーション コードや接続文字列を変更せずにメッセージをシームレスに受信できます。 確実にアクティブな名前空間にだけメッセージを送信するためには、エイリアスを使用する必要があります。
- メタデータ: イベント ハブ、コンシューマー グループなどのエンティティと、名前空間に関連付けられているサービスのプロパティ。 自動的にレプリケートされるのはエンティティとその設定だけです。 メッセージやイベントはレプリケートされません。
- フェールオーバー:セカンダリの名前空間をアクティブ化するプロセスです。
サポートされている名前空間のペア
プライマリ名前空間とセカンダリ名前空間の次の組み合わせがサポートされています。
プライマリ名前空間層 | 許可されるセカンダリ名前空間層 |
---|---|
Standard | Standard、専用 |
Premium | Premium |
専用 | 専用 |
重要
同じ専用クラスター内にある名前空間を組み合わせることはできません。 別々のクラスター内にある名前空間を組み合わせることができます。
セットアップとフェールオーバーの流れ
次のセクションでは、フェールオーバー プロセスの概要を示したうえで、最初のフェールオーバーを設定する方法について説明します。
Note
geo ディザスター リカバリー機能では、自動フェールオーバーはサポートされていません。
セットアップ
まず (新規作成または既存の) プライマリ名前空間と新しいセカンダリ名前空間をペアリングします。 このペアリングによって、接続に使用できる別名が決定されます。 別名を使用するので、接続文字列を変更する必要はありません。 フェールオーバーのペアリングに追加できるのは、新しい名前空間だけです。
プライマリ名前空間を作成します。
別のリージョンにセカンダリ名前空間を作成します。 この手順は省略可能です。 セカンダリ名前空間は、次の手順でペアリングを作成しているときに作成できます。
Azure portal で、プライマリ名前空間に移動します。
左側のメニューの [geo リカバリー] を選択し、ツールバーの [ペアリングの開始] を選択します。
[ペアリングの開始] ページで、次の手順に従います。
- 既存のセカンダリ名前空間を選択するか、別のリージョンで新規作成します。 この例では、既存の名前空間が選択されています。
- [エイリアス] には、Geo DR のペアリングのエイリアスを入力します。
- そのうえで [Create](作成) を選択します。
[Geo DR のエイリアス] ページが表示されます。 左側のメニューで [geo リカバリー] を選択して、プライマリ名前空間からこのページに移動することもできます。
[Geo DR のエイリアス] ページの左側のメニューで [共有アクセス ポリシー] を選択して、エイリアスのプライマリ接続文字列にアクセスします。 この接続文字列は、プライマリまたはセカンダリ名前空間への接続文字列を直接使用する代わりに使用します。
この [概要] ページでは、次のアクションを実行できます。
最後に、フェールオーバーが必要であるかどうかを検出する監視機構を追加する必要があります。 ほとんどの場合、このサービスは大きなエコシステムの一部分であるため、自動フェールオーバーが実行できることはまれです。フェールオーバーは、他のサブシステムやインフラストラクチャと同期して実行しなければならないケースが多いためです。
例
このシナリオの一例として、メッセージまたはイベントを出力する販売時点管理 (POS) ソリューションを考えてみましょう。 Event Hubs は、何らかのマッピング (または再フォーマット) ソリューションにそれらのイベントを渡します。マッピングされたデータは、後続の処理のために、そこから別のシステムに転送されます。 このとき、これらすべてのシステムが、同じ Azure リージョン内でホストされている可能性があります。 いつ、どの部分をフェールオーバーするかの判断は、実際のインフラストラクチャにおけるデータのフローによって異なります。
フェールオーバーは、監視システムを使用して自動化できるほか、独自に構築した監視ソリューションを使用して自動化することもできます。 ただしそのような自動化は、特別な計画と作業が伴い、この記事で取り上げる範囲を超えています。
フェールオーバーの流れ
フェールオーバーを開始する場合、次の 2 つのステップが必要となります。
- 別の故障が発生した場合は、もう一度フェールオーバーしたいと考えます。 そのために、別のパッシブな名前空間を設定して、ペアリングを更新します。
- 以前のプライマリ名前空間が再び利用可能になったら、以前のプライマリ名前空間からメッセージをプルします。 以後、通常のメッセージングにその名前空間を geo リカバリーのセットアップ外で使用するか、または、以前のプライマリ名前空間を削除します。
Note
サポートされるのは、フェール フォワードのセマンティクスだけです。 このシナリオでは、フェールオーバー後、新しい名前空間との間で再度ペアリングを行います。 フェールバックはサポートされません (SQL クラスターでのフェールバックなど)。
手動フェールオーバー
このセクションでは、Azure portal、CLI、PowerShell、C# などを使用して手動でフェールオーバーする方法について説明します。
Azure portal で、プライマリ名前空間に移動します。
左側のメニューで [geo リカバリー] を選択します。
セカンダリ名前空間に手動でフェールオーバーする。 ツールバーの [フェールオーバー] を選択します。
警告
フェールオーバーによって、セカンダリ名前空間がアクティブ化され、geo ディザスター リカバリーのペアリングからプライマリ名前空間が削除されます。 新しい geo ディザスター リカバリーのペアを使用するには、別の名前空間を作成してください。
管理
間違ったリージョンをペアリングしたなど、初期設定にミスがあった場合、2 つの名前空間のペアリングはいつでも解除することができます。 ペアリングした名前空間を通常の名前空間として使用する必要がある場合、エイリアスは削除してください。
考慮事項
次の考慮事項にご注意ください。
設計上、Event Hubs の geo ディザスター リカバリーではデータがレプリケートされないため、プライマリ イベント ハブの古いオフセット値をセカンダリ イベント ハブ上で再利用することはできません。 次のいずれかの方法を使用して、イベント レシーバーを再起動することをお勧めします。
- EventPosition.FromStart() - セカンダリ イベント ハブのすべてのデータを読み取る場合。
- EventPosition.FromEnd() - セカンダリ イベント ハブに接続してからのすべての新しいデータを読み取る場合。
- EventPosition.FromEnqueuedTime(dateTime) - 指定した日付と時刻以降にセカンダリ イベント ハブで受信したすべてのデータを読み取る場合。
フェールオーバー計画では、時間的要因も考慮する必要があります。 たとえば、接続の喪失時間が 15 ~ 20 分を超えた場合にフェールオーバー開始の判断を下すことが考えられます。
レプリケートされるデータが存在しないということは、現在のアクティブなセッションがレプリケートされないことを意味します。 また、重複の検出やスケジュールされたメッセージが正しく機能しない可能性があります。 新しいセッションやスケジュールされたメッセージ、新しい重複については正しく機能します。
複雑な分散インフラストラクチャのフェールオーバーは、少なくとも 1 回はリハーサルを行うようお勧めします。
エンティティの同期には、ある程度時間がかかる場合があります (1 分あたり約 50 ~ 100 エンティティ)。
geo リカバリーのペアリングがアクティブな間、セカンダリ名前空間の管理プレーンの一部は読み取り専用になります。
geo リカバリーのペアリングがアクティブな間、セカンダリ名前空間のデータ プレーンは読み取り専用になります。 セカンダリ名前空間のデータ プレーンは、クライアント接続とアクセス制御の検証を有効にする GET 要求を受け入れます。
プライベート エンドポイント
このセクションでは、プライベート エンドポイントを使用する名前空間で geo ディザスター リカバリーを使用する場合のその他の考慮事項について説明します。 一般に Event Hubs でプライベート エンドポイントを使用する方法については、プライベート エンドポイントの構成に関するページを参照してください。
新しいペアリング
プライベート エンドポイントがあるプライマリ名前空間と、プライベート エンドポイントがないセカンダリ名前空間とのペアリングを作成しようとすると、ペアリングは失敗します。 ペアリングは、プライマリとセカンダリの両方の名前空間にプライベート エンドポイントがある場合にのみ成功します。 プライマリおよびセカンダリ名前空間と、プライベート エンドポイントが作成される仮想ネットワークで同じ構成を使用することをお勧めします。
Note
プライベート エンドポイントがあるプライマリ名前空間と任意のセカンダリ名前空間を組み合わせようとすると、検証プロセスで、セカンダリ名前空間にプライベート エンドポイントが存在するかどうかのみが確認されます。 エンドポイントが機能するかどうか、またはフェールオーバー後に機能するかどうかは確認されません。 プライベート エンドポイントがあるセカンダリ名前空間が、フェールオーバー後に予期したとおりに確実に機能することをご自身で確認する必要があります。
プライマリ名前空間とセカンダリ名前空間のプライベート エンドポイント構成が同じであることをテストするには、読み取り要求 (例: イベント ハブの取得) を仮想ネットワークの外側からセカンダリ名前空間に送信し、サービスからエラー メッセージが返されることを確認します。
既存のペアリング
プライマリ名前空間とセカンダリ名前空間のペアリングが既に存在する場合、プライマリ名前空間でのプライベート エンドポイントの作成は失敗します。 解決するには、まずセカンダリ名前空間にプライベート エンドポイントを作成し、次にプライマリ名前空間用に作成します。
Note
セカンダリ名前空間に対して許可されるのは読み取り専用アクセスですが、プライベート エンドポイント構成の更新は許可されます。
推奨構成
アプリケーションと Event Hubs 名前空間のディザスター リカバリー構成を作成する場合は、アプリケーションのプライマリ インスタンスとセカンダリ インスタンスの両方をホストする仮想ネットワークに対して、プライマリとセカンダリの両方の Event Hubs 名前空間にプライベート エンドポイントを作成する必要があります。
たとえば、2 つの仮想ネットワーク VNET-1
、VNET-2
および次のプライマリとセカンダリの名前空間 EventHubs-Namespace1-Primary
、EventHubs-Namespace2-Secondary
があるとします。 次の手順を実行する必要があります。
EventHubs-Namespace1-Primary
上で、VNET-1
とVNET-2
のサブネットを使用する 2 つのプライベート エンドポイントを作成しますEventHubs-Namespace2-Secondary
上で、VNET-1
とVNET-2
の同じサブネットを使用する 2 つのプライベート エンドポイントを作成します
このアプローチの利点は、Event Hubs 名前空間から独立したアプリケーション レイヤーでフェールオーバーが発生するようにできることです。 以下のようなシナリオが考えられます。
アプリケーションのみのフェールオーバー: ここでは、アプリケーションは VNET-1
内に存在せず、VNET-2
に移動します。 プライマリおよびセカンダリ名前空間の両方に対して、VNET-1
と VNET-2
両方の上でプライベート エンドポイントが構成されるため、このアプリケーションは正しく動作します。
Event Hubs 名前空間のみのフェールオーバー: ここでも、プライマリとセカンダリの両方の名前空間に対して、両方の仮想ネットワークで両方のプライベート エンドポイントが構成されているため、アプリケーションは動作します。
Note
仮想ネットワークの geo ディザスター リカバリーに関するガイダンスについては、「Virtual Network - ビジネス継続性」を参照してください。
ロールベースのアクセス制御
プライマリ名前空間内のエンティティに対する Microsoft Entra ロールベースのアクセス制御 (RBAC) の割り当ては、セカンダリ名前空間にレプリケートされません。 セカンダリ名前空間にロールの割り当てを手動で作成して、アクセスをセキュリティで保護します。
関連するコンテンツ
次のサンプルまたはリファレンス ドキュメントを確認してください。