Azure Event Hubsでの地理的レプリケーション

Azure Event Hubs geo レプリケーションでは、名前空間のメタデータ (エンティティ、構成、プロパティ) とイベント データのコピーが複数のAzureリージョンに保持されます。 プライマリ リージョンで障害が発生した場合は、セカンダリ リージョンを昇格して、ストリーミング アプリケーションを最小限のデータ損失で実行し続けることができます。

以降のセクションでは、geo レプリケーションのしくみ、同期レプリケーション モードと非同期レプリケーション モードの比較、セカンダリ リージョンの管理方法について説明します。

geo レプリケーションにより、名前空間のメタデータとデータがプライマリ リージョンからセカンダリ リージョンに継続的にレプリケートされます。 名前空間は複数のリージョンに拡張され、1 つのリージョンがプライマリ、もう 1 つはセカンダリと考えることができます。

セカンダリ リージョンはいつでもプライマリ リージョンに昇格できます。 セカンダリを昇格すると、選択したセカンダリ リージョンに名前空間 FQDN (完全修飾ドメイン名) が再ポイントされ、前のプライマリ リージョンがセカンダリ リージョンに降格されます。

シナリオ

Event Hubs geo レプリケーションは、複数のシナリオで使用できます。

事業継続とディザスター リカバリー

geo レプリケーションにより、名前空間上のすべてのストリーミング データに対するディザスター リカバリーとビジネス継続性が保証されます。 リージョン間でデータをレプリケートすることで、組織はデータ損失から保護し、リージョンの障害が発生した場合でもアプリケーションが動作し続けられるようにすることができます。 この機能は、高可用性と最小限のダウンタイムを必要とするミッション クリティカルなアプリケーションにとって非常に重要です。

グローバル データ分散

geo レプリケーションを使用すると、データをグローバルに分散できるため、アプリケーションは最も近いリージョンのデータにアクセスできます。 これにより、待機時間が短縮され、世界各地にあるワークロードのパフォーマンスが向上します。

データ主権とコンプライアンス

多くの場合、複数の国または地域で活動する組織は、特定の地理的境界内にデータを格納する必要があるデータ主権法に準拠する必要があります。 geo レプリケーションを使用すると、これらの組織は、ローカルの規制に準拠しているリージョンにデータをレプリケートし、統一されたデータ プラットフォームを維持しながら法的要件を満たすことができます。

移行とアップグレード

geo レプリケーションを使用して、データの移行、メンテナンス、システムのアップグレードを容易にすることもできます。 組織は、プライマリ リージョンからセカンダリ リージョンに名前空間を事前に移行して、プライマリ リージョンでのメンテナンスとアップグレードを可能にすることができます。

基本的な概念

geo レプリケーション機能では、プライマリ セカンダリ レプリケーション モデルを使用してメタデータとデータをレプリケートします。 いつでも、プロデューサーとコンシューマーの両方にサービスを提供する 1 つのプライマリ リージョンがあります。 セカンダリ リージョンはホット スタンバイ リージョンとして機能するため、セカンダリ リージョンと対話することはできません。 ただし、プライマリ リージョンと同じ構成で実行されます。つまり、昇格後にすばやくステップ インできます。

geo レプリケーション機能の主な側面は次のとおりです。

• プライマリ セカンダリ レプリケーション モデル – geo レプリケーションはプライマリ セカンダリ レプリケーション モデルに基づいて構築されます。特定の時点で、イベント プロデューサーとイベント コンシューマーにサービスを提供するプライマリ名前空間は 1 つだけです。
• Event Hubs は、構成された整合性レベルを使用して、複数のセカンダリにわたってメタデータ、イベント データ、コンシューマー オフセットのフル マネージド バイト間レプリケーションを実行します。
• 単一の名前空間ホスト名 - geo レプリケーションが有効な名前空間を正常に構成したら、クライアント アプリケーションで名前空間のホスト名を使用します。 ホスト名は、構成されたプライマリとセカンダリの Azure リージョンに依存せずに動作し、常にプライマリ Azure リージョンを指します。
• 昇格を開始すると、ホスト名は新しいプライマリ リージョンとして選択されたリージョンを指します。 古いプライマリがセカンダリ Azure リージョンになります。
• セカンダリ リージョンで読み取りまたは書き込みを行うことはできません。
• プライマリからセカンダリのリージョンへのカスタマー マネージドの昇格により、完全な所有権と、停止解決の可視性が提供されます。 メトリックを使用できます。これは、顧客側からの昇格を自動化するのに役立ちます。
• セカンダリ リージョンを追加または削除できます。
• レプリケーションの整合性 - 同期と非同期の 2 つのレプリケーション整合性設定を使用できます。

状態	ダイアグラム
フェールオーバー前 (セカンダリの昇格)
フェールオーバー後 (セカンダリの昇格)

レプリケーション モード

同期と非同期の 2 つのレプリケーション整合性構成を使用できます。 これら 2 つの構成の違いは、アプリケーションとデータの一貫性に影響するため理解します。

非同期レプリケーション

非同期レプリケーションを使用すると、プライマリはすべての要求をコミットし、クライアントに受信確認を送信します。 セカンダリ Azure リージョンへのレプリケーションは非同期的に行われます。 最大許容ラグ タイム (プライマリ リージョンとセカンダリ リージョンの最新のアクション間のサービス側オフセット) を構成できます。 サービスはデータとメタデータを継続的にレプリケートし、ラグが可能な限り小さいままであることを確認します。 アクティブなセカンダリのラグが、ユーザーが構成したレプリケーションの最大ラグを超えると、プライマリは受信要求の調整を開始します。

同期レプリケーション

同期レプリケーションを使用すると、システムはすべての要求をセカンダリの場所に送信します。 セカンダリ ロケーションは、プライマリ ロケーションのコミット前に操作をコミットして確認します。 その結果、アプリケーションは、発行、レプリケート、確認、コミットに要する時間に応じた速度で発行されます。 このプロセスは、アプリケーションが両方のリージョンの可用性に依存しているということです。 セカンダリ リージョンが遅延または使用できない場合、プライマリ リージョンはメッセージを認識またはコミットせず、受信要求を制限します。

レプリケーションの整合性の比較

同期レプリケーション使用する場合:

• 分散コミット操作に起因して、待機時間がより長くなります。
• 可用性は、2 つのリージョンの可用性によって異なります。 1 つのリージョンがダウンすると、名前空間は利用できなくなります。

一方、同期レプリケーションは、データが安全であることを最も確実に保証します。 同期レプリケーションでは、geo レプリケーション用に構成したすべてのリージョンでデータがコミットされ、最適なデータ保証が提供されます。

非同期レプリケーションの場合:

• 待機時間の影響は最小限です。
• セカンダリ リージョンの損失は、可用性にすぐに影響を与えるわけではありません。 ただし、構成された最大レプリケーションラグに達すると、可用性が影響を受ける。

そのため、同期レプリケーションのようなコミットの前にすべてのリージョンにデータが含まれるという絶対的な保証はありません。また、データの損失や重複が発生する可能性があります。 ただし、1 つのリージョンが遅れたり使用できなくなったりしたときにすぐに影響を受けなくなったので、待機時間が短くなるだけでなく、アプリケーションの可用性が向上します。

geo レプリケーションを構成した後で、レプリケーション モードを変更できます。 同期から非同期に、または非同期から同期に切り替えることができます。 非同期から同期に切り替えると、ラグがゼロに達した後にセカンダリ リージョンが同期として構成されます。 何らかの理由で継続的なラグで実行している場合は、ラグがゼロに達するまでパブリッシャーを一時停止し、モードを同期に切り替えることができる必要がある場合があります。 非同期レプリケーションではなく同期レプリケーションを有効にする理由は、アプリケーションの可用性ではなく、データ、特定のビジネス ニーズ、またはコンプライアンス上の理由の重要性に関連しています。

副次リージョンの選択

geo レプリケーション機能を有効にするには、機能が有効になっているプライマリ リージョンとセカンダリ リージョンを使用します。 geo レプリケーション機能は、公開されたメッセージをプライマリリージョンからセカンダリ リージョンにレプリケートできるかどうかによって異なります。 セカンダリ リージョンが別の大陸にある場合、この選択はプライマリリージョンからセカンダリ リージョンへのレプリケーションラグに大きな影響を与えます。 可用性の理由から geo レプリケーションを使用している場合は、可能な限り同じ大陸のセカンダリ リージョンを選択します。 地理的な距離によって引き起こされる待機時間について理解を深めるには、Azureネットワークラウンドトリップ待機時間の統計情報を参照してください。

ジオレプリケーションの管理

geo レプリケーション機能を使用すると、メタデータとデータをレプリケートするセカンダリ リージョンを構成できます。 そのため、次の管理タスクを実行できます。

• geo レプリケーションの構成 - geo レプリケーション 機能を有効にすると、リージョン内の任意の新規または既存の名前空間でセカンダリ リージョンを構成できます。
• レプリケーションの整合性を構成する - geo レプリケーションを構成するときに同期レプリケーションと非同期レプリケーションを設定します。 この設定は後で切り替えることもできます。
• 昇格/フェイルオーバーを起動する - すべての昇格は顧客が開始します。
• セカンダリを削除する - セカンダリ リージョンを削除する場合は、削除できます。 セカンダリ リージョン内のデータが削除されます。

昇格をトリガーする条件

セカンダリからプライマリへの昇格がトリガーされる場合を次に示します。

• リージョンの停止: プライマリ リージョンに影響を与えるリージョンの停止がある場合は、ビジネス継続性を確保し、ダウンタイムを最小限に抑えるために、セカンダリ リージョンを昇格します。

• メンテナンス アクティビティ: プライマリ リージョンでの計画メンテナンス アクティビティ中に、セカンダリ リージョンを昇格すると、ミッション クリティカルなアプリケーションの高可用性を維持するのに役立ちます。

• ディザスター リカバリー: プライマリ リージョンに影響を与える障害が発生した場合、セカンダリ リージョンを昇格することで、データへのアクセスが維持され、アプリケーションが引き続き機能するようになります。

• パフォーマンスの問題: プライマリ リージョンで、Event Hubs の可用性または信頼性に影響するパフォーマンスの問題が発生している場合は、セカンダリ リージョンを昇格することで、これらの問題を軽減できます。

場合によっては、フェールオーバー メカニズムをテストして、ビジネス継続性計画が有効であり、必要に応じてアプリケーションがシームレスにセカンダリ リージョンに切り替えることができることを確認します。

データ レプリケーションの監視

レプリケーション ジョブの進行状況を監視するには、アプリケーション メトリック ログでレプリケーションのラグ メトリックを確認します。

• Monitoring Azure Event Hubs に従って Event Hubs 名前空間のアプリケーション メトリック ログを有効にする - Azure Event Hubs |Microsoft Learn。

• アプリケーション メトリック ログを有効にした後、数分間名前空間からデータを生成して使用してから、ログの表示を開始します。

• アプリケーション メトリック ログを表示するには、Event Hubs ページの [監視 ] セクションに移動し、左側のメニューで [ログ ] を選択します。 次のクエリを使用して、プライマリ名前空間とセカンダリ名前空間の間のレプリケーションのラグ (秒単位) を見つけます。

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag"
  

• count_d列には、プライマリ リージョンとセカンダリ リージョンの間のレプリケーションのラグが秒単位で表示されます。

データの発行

発行アプリケーションは、geo レプリケーションが有効な名前空間の名前空間ホスト名を使用して、geo レプリケートされた名前空間にデータを送信できます。 発行方法は、ジオレプリケーションを使用しないケースと同じです。 データ プレーン SDK やクライアント アプリケーションに変更を加える必要はありません。

イベントの発行は、以下の状況では利用できない場合があります。

• セカンダリ リージョンの昇格を要求した後、既存のプライマリ リージョンは、イベント ハブに発行された新しいイベントをすべて拒否します。
• プライマリとセカンダリ リージョン間のレプリケーション ラグが最大レプリケーション ラグの時間に達すると、パブリッシャーのイングレス ワークロードが制限される場合があります。

パブリッシャー アプリケーションは、セカンダリ リージョン内の名前空間に直接アクセスすることができません。

データの消費

データを使用するアプリケーションは、ジオレプリケーション機能が有効になっている名前空間のホスト名を使用してデータを取得できます。 コンシューマー操作は、プロモーションが開始された時点からプロモーションが完了するまでサポートされません。

チェックポイント処理とオフセット管理

イベントを消費するアプリケーションでは、geo レプリケートされていない名前空間と同じ方法でオフセット管理を維持できます。 geo レプリケーションが有効な名前空間では、オフセット管理に特別な考慮事項は必要ありません。

Kafka

コンシューマーはオフセットを Event Hubs に直接コミットし、システムはリージョン間でオフセットをレプリケートします。 そのため、コンシューマーはプライマリ リージョンで中断した場所から消費を開始できます。

サポートされている Apache Kafka クライアントの一覧を次に示します。

その他のライブラリの場合、サポートは API のバージョンによって異なります。

Event Hubs SDK と AMQP

AMQP の場合、ユーザーは、Azure BLOB ストレージやカスタム ストレージ ソリューションなどのチェックポイント ストアを使用してチェックポイントを管理します。 フェールオーバーがある場合は、クライアントがチェックポイント データを取得してメッセージの損失を回避できるように、セカンダリ リージョンにチェックポイント ストアが必要です。

Event Hubs SDK の最新バージョンには、フェールオーバーをサポートするためのチェックポイント表現の変更が含まれています。 最新バージョンの SDK を使用しますが、次の SDK の以前のバージョンもサポートされています。

考慮事項

次の考慮事項に留意してください。

• プロモーション計画で、時間要因を検討します。 たとえば、接続が切れて 15 から 20 分間を超えた場合は、昇格を開始する判断を下すかもしれません。
• 複雑な分散インフラストラクチャを少なくとも 1 回は昇格させるリハーサルを行う必要があります。

価格

価格は選択したレベルによって異なりますが、一般的には 2 つのパラメーターがあります。

• クラスターまたは名前空間のコンピューティング料金。
• プライマリ リージョンとセカンダリ リージョンの間でレプリケートされるデータの帯域幅料金。

専用クラスター

Event Hubs 専用クラスターで geo レプリケーションを使用する場合は、個別のリージョンに少なくとも 2 つの専用クラスターが必要です。 これらのクラスターを使用して、geo レプリケートされる名前空間以外の名前空間をホストできます。 これらの専用クラスターの料金は、それぞれに割り当てられた容量ユニット (CU) の数に基づいて個別に支払われます。

geo レプリケーションを有効にすると、プライマリからセカンダリにレプリケートされるデータの帯域幅料金のみが追加料金になります。 この料金は、プライマリ リージョンの場所によって異なります。

Premium 名前空間

Premium 名前空間の場合、geo レプリケーションを有効にすると、セカンダリ リージョン内の同じ数の処理ユニット (CU) が取得されます。 使用する RU の数 と、 プライマリ リージョンとセカンダリ リージョンの間で転送されたデータの帯域幅に対して支払います。

たとえば、4 つの PU でプロビジョニングした Premium 名前空間で geo レプリケーションを有効にした場合、次の料金が発生します。

• プライマリ リージョン内の 4 つの PU、
• セカンダリ リージョン内の 4 つの PU、
• ジオレプリケーションされたデータの料金は、GBあたりで計算されます。

プライマリ リージョンとセカンダリ リージョン間で転送されたデータに基づいて、帯域幅の料金を支払います。

価格メーター

ジオレプリケーションデータ転送の帯域幅料金メーターは、次の詳細と共に示されています。

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

プライベートエンドポイントを通じてEvent Hubsの名前空間に接続するクライアントは、フェイルオーバー後に自動的に新しいプライマリリージョンに接続します。 Event Hubsの名前空間は内部的に現在のプライマリリージョンにトラフィックをルーティングするため、クライアントはどのリージョンがプライマリかを知る必要がなく、プライベートエンドポイントも変更なく動作し続けます。 プロモーションは通常2分以内に完了し、その間にクライアントは一時的なエラーを確認して再接続することがあります。 それに応じて再試行ポリシーを設定してください。

プライベートエンドポイントは地域リソースです。 高可用性のためには、複数の地域にアプリケーションを展開し、各地域の仮想ネットワーク内にプライベートエンドポイントを作成します。

DNS

各リージョンごとに1 privatelink.servicebus.windows.net つのプライベートDNSゾーンを使い、その地域の仮想ネットワークにのみリンクしてください。 ローカルのプライベートエンドポイントのAレコードは、プライベートDNSゾーングループを接続すると自動的に追加されます。 どのリージョンがプライマリであるかに関係なく、各リージョンは名前空間名をそのリージョンのローカル エンドポイントに解決します。

両方の仮想ネットワークで単一のプライベートDNSゾーンを共有している場合、Aレコードは1つだけで、最後に接続されたエンドポイントを指しています。 その場合は、すべてのクライアントがそのエンドポイントに到達できるように、 クロスリージョン仮想ネットワークピアリング を追加してください。

オンプレミスのクライアントについては、条件付き転送または手動で管理するレコードを通じて、名前空間を最も近いリージョンのプライベート エンドポイントに解決します。 プロモーションにはオンプレミスのDNS変更は必要ありません。

フェイルオーバーシナリオ

• アプリケーションのみのフェイルオーバー。 アプリケーションは別の仮想ネットワークに移動します。 それはローカルのプライベートエンドポイントを通じて名前空間に到達します。
• 名前空間のみのフェイルオーバー。 イベントハブの主な役割は移動します。 クライアントは同じ接続文字列とローカルエンドポイントを保持し、トラフィックは自動的に新しいプライマリにルーティングされます。
• リージョンの停止。 影響を受けた地域のプライベートエンドポイントは到達できません。 正常なリージョン内にプライベート エンドポイントを持つクライアントは、存続しているリージョンで引き続き処理されます。

関連するコンテンツ

geo レプリケーション機能の使用方法については、「geo レプリケーションの使用方法」を参照してください。