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