Azure Event Hubs - geo ディザスター リカバリー

  • [アーティクル]

データ処理リソースの大きな損害をもたらす停止に対する回復力は、多くの企業にとっての要件であり、業界の規制によって要求される場合もあります。

Azure Event Hubs により、データセンター内の複数の障害ドメインにまたがるクラスター間で、個々のマシン、さらにはラック全体の致命的な障害のリスクがあらかじめ分散されます。 透過的な障害検出およびフェールオーバー メカニズムが実装されるため、通常はそのような障害が発生した場合でも顕著な中断なしに、保証されたサービスレベル内でサービスが動作し続けます。 可用性ゾーンを有効にして Event Hubs 名前空間を作成すると、停止のリスクがさらに小さい高可用性が実現します。 可用性ゾーンでは、物理的に分離された 3 つの施設間で停止リスクがさらに分散されます。また、サービスには、施設全体の致命的な損失に瞬時に対処するための十分な容量が予約されています。

可用性ゾーンをサポートするすべてアクティブな Azure Event Hubs クラスター モデルは、致命的なハードウェア障害やデータセンター機能全体の致命的な損失が発生した場合の回復性を備えています。 それでも、広範囲の物理的な破壊によって、これらの手段によっても十分に防御できない致命的な状況が生じるおそれがあります。

Event Hubs の geo ディザスター リカバリー機能は、容易にこの大きさの災害から復旧し、アプリケーションの構成を変更することなく、障害が発生した Azure リージョンを完全に破棄できるように設計されています。 Azure リージョンの破棄には、通常、いくつかのサービスが含まれます。この機能は、主に複合アプリケーション構成の整合性を維持するためのものです。

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

重要

  • この機能を使用すると、同じ構成で操作を瞬時に継続できますが、イベント データはレプリケートされません。 災害によってすべてのゾーンが失われない限り、フェールオーバー後にプライマリ イベント ハブに保持されるイベント データが復旧可能になるので、アクセスが復元されるとそこから履歴イベントを取得できるようになります。 イベント データをレプリケートし、アクティブ/アクティブ構成内の対応する名前空間を操作して停止や災害に対処するには、この geo ディザスター リカバリー機能セットを使用せずに、レプリケーションのガイダンスに従ってください。
  • プライマリ名前空間内のエンティティに対する Microsoft Entra ロールベースのアクセス制御 (RBAC) の割り当ては、セカンダリ名前空間にレプリケートされません。 セカンダリ名前空間にロールの割り当てを手動で作成して、アクセスをセキュリティで保護します。

故障と災害

"故障" と "災害" の違いに注意してください。"故障" とは、Azure Event Hubs が一時的に使用不可能になっていることです。メッセージング ストアなどサービスの一部のコンポーネントや、場合によってはデータセンター全体に影響を与えることがあります。 しかし、問題が解決されると、Event Hubs は再び使用可能になります。 通常、故障によってメッセージなどのデータが失われることはありません。 故障の例として、データセンターでの電源障害があります。 一時的な問題やネットワークの問題によって、接続が短時間失われるだけの故障もあります。

"災害" は、Event Hubs クラスター、Azure リージョン、またはデータ センターの永久または長期間損失として定義されています。 リージョンまたはデータセンターは、再び利用可能になる場合も、ならない場合もあります。また、数時間や数日間の停止になる場合もあります。 このような災害の例としては、火災、洪水、地震があります。 永続的な災害により、メッセージやイベントなどのデータが失われる可能性があります。 ただし、ほとんどの場合、データ センターがバックアップされていればデータが失われることはなく、メッセージを復元できます。

Azure Event Hubs の geo ディザスター リカバリー機能はディザスター リカバリー ソリューションです。 この記事で説明する概念とワークフローは、一時的な故障ではなく、災害のシナリオに適用されます。 Microsoft Azure でのディザスター リカバリーの詳細については、こちらの記事をご覧ください。

基本的な概念と用語

ディザスター リカバリー機能は、メタデータの災害復旧を実装しており、一次および二次障害復旧の名前空間に依存しています。

geo ディザスター リカバリー機能は、Standard SKU、Premium SKU、および専用 SKU にのみ使用できます。 別名を使用して接続を確立するので、接続文字列に変更を加える必要はありません。

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

  • エイリアス: 設定したディザスター リカバリー構成の名前です。 エイリアスは、1 つの不変の完全修飾ドメイン名 (FQDN) の接続文字列を示します。 アプリケーションでは、このエイリアスの接続文字列を使用して名前空間に接続します。

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

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

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

サポートされている名前空間のペア

プライマリ名前空間とセカンダリ名前空間の次の組み合わせがサポートされています。

プライマリ名前空間層 許可されるセカンダリ名前空間層
Standard Standard、専用
Premium Premium
専用 専用

Note

同じ専用クラスター内にある名前空間を組み合わせることはできません。 別々のクラスター内にある名前空間を組み合わせることができます。

セットアップとフェールオーバーの流れ

次のセクションでは、フェールオーバー プロセスの概要を示したうえで、最初のフェールオーバーを設定する方法について説明します。

Image showing the overview of failover process

設定

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

  1. プライマリ名前空間を作成します。

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

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

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

    Initiate pairing from the primary namespace

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

    1. 既存のセカンダリ名前空間を選択するか、別のリージョンで新規作成します。 この例では、既存の名前空間が選択されています。
    2. [エイリアス] には、Geo DR のペアリングのエイリアスを入力します。
    3. そのうえで [Create](作成) を選択します。

    Select the secondary namespace

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

    Geo-DR alias page

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

  8. この [概要] ページでは、次のアクションを実行できます。

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

    2. セカンダリ名前空間に手動でフェールオーバーする。 ツールバーの [フェールオーバー] を選択します。

      警告

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

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

例

このシナリオの一例として、メッセージまたはイベントを出力する販売時点管理 (POS) ソリューションを考えてみましょう。 Event Hubs は、何らかのマッピング (または再フォーマット) ソリューションにそれらのイベントを渡します。マッピングされたデータは、後続の処理のために、そこから別のシステムに転送されます。 このとき、これらすべてのシステムが、同じ Azure リージョン内でホストされている可能性があります。 いつ、どの部分をフェールオーバーするかの判断は、実際のインフラストラクチャにおけるデータのフローによって異なります。

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

フェールオーバーの流れ

フェールオーバーを開始する場合、次の 2 つのステップが必要となります。

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

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

Note

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

Image showing the failover flow

手動フェールオーバー

このセクションでは、Azure portal、CLI、PowerShell、C# などを使用して手動でフェールオーバーする方法について説明します。

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

  2. 左側のメニューで [geo リカバリー] を選択します。

  3. セカンダリ名前空間に手動でフェールオーバーする。 ツールバーの [フェールオーバー] を選択します。

    警告

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

管理

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

考慮事項

次の考慮事項にご注意ください。

  1. 設計上、Event Hubs の geo ディザスター リカバリーではデータがレプリケートされないため、セカンダリ イベント ハブでプライマリ イベント ハブの古いオフセット値を再利用することはできません。 次のいずれかの方法を使用して、イベント レシーバーを再起動することをお勧めします。

    • EventPosition.FromStart() - セカンダリ イベント ハブのすべてのデータを読み取る場合。
    • EventPosition.FromEnd() - セカンダリ イベント ハブに接続してからのすべての新しいデータを読み取る場合。
    • EventPosition.FromEnqueuedTime(dateTime) - 指定した日付と時刻以降にセカンダリ イベント ハブで受信したすべてのデータを読み取る場合。

  2. フェールオーバー計画では、時間的要因も考慮する必要があります。 たとえば、接続の喪失時間が 15 ～ 20 分を超えた場合にフェールオーバー開始の判断を下すことが考えられます。

  3. レプリケートされるデータが存在しないということは、現在のアクティブなセッションがレプリケートされないことを意味します。 また、重複の検出やスケジュールされたメッセージが正しく機能しない可能性があります。 新しいセッションやスケジュールされたメッセージ、新しい重複については正しく機能します。

  4. 複雑な分散インフラストラクチャのフェールオーバーは、少なくとも 1 回はリハーサルを行うようお勧めします。

  5. エンティティの同期には、ある程度時間がかかる場合があります (1 分あたり約 50 ～ 100 エンティティ)。

  6. geo リカバリーのペアリングがアクティブな間、セカンダリ名前空間の管理プレーンの一部は読み取り専用になります。

  7. geo リカバリーのペアリングがアクティブな間、セカンダリ名前空間のデータ プレーンは読み取り専用になります。 セカンダリ名前空間のデータ プレーンは、クライアント接続とアクセス制御の検証を有効にする GET 要求を受け入れます。

可用性ゾーン

Event Hubs では、Azure リージョン内に障害から分離された場所を提供する Availability Zones がサポートされています。 Availability Zones サポートは、可用性ゾーンがある Azure リージョンでのみ使用できます。 メタデータとデータ (イベント) の両方が、可用性ゾーン内のデータ センターとの間でレプリケートされます。

名前空間を作成するときに、可用性ゾーンを持つリージョンを選択すると、次の強調表示されたメッセージが表示されます。

Image showing the Create Namespace page with region that has availability zones

Note

Azure portal を使用すると、可用性ゾーンのサポートによるゾーン冗長が自動的に有効になります。 ポータルで無効にすることはできません。 --zone-redundant=false で Azure CLI コマンド az eventhubs namespace を使用するか、-ZoneRedundant=false で PowerShell コマンド New-AzEventHubNamespace を使用して、ゾーン冗長を無効にした名前空間を作成できます。

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

このセクションでは、プライベート エンドポイントを使用する名前空間で 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 つのプライベート エンドポイントを作成します。

Private endpoints and virtual networks

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

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

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

Note

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

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

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

次のステップ

次のサンプルまたはリファレンス ドキュメントを確認してください。