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あたりで計算されます。

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

価格メーター

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

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

このセクションでは、プライベート エンドポイントを使用する名前空間で geo レプリケーションを使用する場合の追加の考慮事項について説明します。 Event Hubs でのプライベート エンドポイントの使用に関する一般的な情報については、「Azure Private Linkとの統合によるAzure Event Hubsの利用」を参照してください。

プライベート エンドポイントを使用する Event Hubs 名前空間の geo レプリケーションを実装する場合は、プライマリ リージョンとセカンダリ リージョンの両方にプライベート エンドポイントを作成します。 アプリケーションのプライマリ インスタンスとセカンダリ インスタンスの両方をホストする仮想ネットワークに対して、これらのエンドポイントを構成します。 たとえば、VNET-1 と VNET-2 の 2 つの仮想ネットワークがある場合は、それぞれ VNET-1 と VNET-2 のサブネットを使用して、Event Hubs 名前空間に 2 つのプライベート エンドポイントを作成する必要があります。 クライアントがいずれかのプライベート エンドポイントと通信できるように、 リージョン間ピアリングを使用して仮想ネットワークを設定します。 最後に、 すべての クライアントが名前空間エンドポイント (namespacename.servicebus.windows.net) を現在のプライマリ リージョンのプライベート エンドポイントの IP アドレスを指す DNS 情報を取得するように DNS を管理します。

この方法は、フェールオーバーがアプリケーション レイヤーまたは Event Hubs 名前空間で個別に発生する利点を提供します。

• アプリケーションのみのフェールオーバー: このシナリオでは、アプリケーションは VNET-1 から VNET-2 に移行します。 プライベート エンドポイントはプライマリ名前空間とセカンダリ名前空間の両方に対して VNET-1 と VNET-2 の両方で構成されるため、アプリケーションは引き続きシームレスに機能します。
• Event Hubs 名前空間のみのフェールオーバー: フェールオーバーが Event Hubs 名前空間レベルでのみ発生する場合、プライベート エンドポイントは両方の仮想ネットワークで構成されているため、アプリケーションは引き続き動作します。

これらのガイドラインに従うことで、プライベート エンドポイントを使用する Event Hubs 名前空間の堅牢で信頼性の高いフェールオーバー メカニズムを確保できます。

関連するコンテンツ

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